Subject: [netmod] anydata

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 09 Jun 2015 16:16:35 +0200

Hi,

RFC 6020bis says in Sec. 7.10: The "anydata" statement is used to
represent an unknown set of nodes that can be modelled with YANG." I'd
like to clarify what this means with respect to namespaces.

1. Is it allowed that the XML content (value) of an anydata node have no
   namespace? That is:

   anydata foo;

   <foo>
     <bar xmlns=""/>
   </foo>

   I assume it is not allowed.

2. For a namespace URI that's used for anydata content, is it required
   that there exist a YANG module defining this URI as its namespace?

   I assume it is not required.

Thanks, Lada

-- 
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 09 Jun 2015 22:23:47 +0200 (CEST)

>    I assume it is not allowed.

Right, b/c this cannot be encoded with the encoding rules for anydata,
which says that the element's namespace is the module's XML namespace
(and this cannot be "").

>    I assume it is not required.

Yes.

I don't see how it could be enforced?  How can you tell if a YANG
module exists?

I do want to be able to have a generic model like:

   list logged-notification {
     ...
     anydata notif;
   }

and implement this in a server that doesn't necessarily know the data
model of every possible notification.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 09:05:07 +0200

> On 09 Jun 2015, at 22:23, Martin Bjorklund <[email-masked]> wrote:
> 

For example, it could be required that the server advertises such a module so as to be known at run time. I am not proposing this, just verifying that everybody interprets “can be modelled” the same way.

It is also important for the JSON encoding - it means there won’t necessarily be a way for mapping XML-encoded instance to JSON and vice versa.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 09:22:11 +0200

> It is also important for the JSON encoding - it means there won’t necessarily be a way for mapping XML-encoded instance to JSON and vice versa.

Because of two different namespace identifiers. So here we go.

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 09:56:51 +0200

> On 10 Jun 2015, at 09:22, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Yes, three in fact. Blame XML for this.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 11:01:11 +0200

> Yes, three in fact. Blame XML for this.

No, I am not blaming XML. There are only two namespace identifiers;
XML uses a URI, you insist that JSON uses a YANG module name. The fact
that these _two_ namespace identifiers are different requires to have
YANG modules at hand in order to do a conversion between XML encoded
YANG instance data and JSON encoded YANG instance data. This is
something created by NETMOD (since JSON does not really have
namespaces), not something to blame others for.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 11:26:38 +0200

> On 10 Jun 2015, at 11:01, Juergen Schoenwaelder <[email-masked]> wrote:
> 

From JSON point of view, the module name is an ideal namespace ID because it is a YANG identifier. Putting URIs to JSON text is a non-starter, and we have already discussed this.

The use of URIs as namespace identifiers and URI-prefix duality in XML has been recognized as a design mistake by XML creators:

http://blog.jclark.com/2010/01/xml-namespaces.html

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 12:07:56 +0200

> http://blog.jclark.com/2010/01/xml-namespaces.html

There are odd things in XML, there are odd things in JSON, but this is
not our scope. We are only responsible for any odd things we create.

The decision that the JSON encoding and the XML encoding of YANG
instance data uses different namespace identifiers is the
responsibility of this WG.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 12:29:09 +0200

> On 10 Jun 2015, at 12:07, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Do you want to suggest an alternative?

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 10 Jun 2015 15:04:58 +0200 (CEST)

Juergen Schoenwaelder <[email-masked]> wrote:
> > It is also important for the JSON encoding - it means there won’t
> necessarily be a way for mapping XML-encoded instance to JSON and
> vice versa.
> >
> 

There are other reasons as well, e.g., <foo>42</foo> might be encoded
as:

  "foo": 42

or

  "foo": "42"

or

  "foo": [42]

or

  "foo": ["42"]
  
depending on the data model.

The JSON encoding process needs the data model.

/martin

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Wed, 10 Jun 2015 15:23:49 +0200

> The JSON encoding process needs the data model.

Unless the receiver can be expected to do conversion as needed. (I
know Lada does not like that, no need to tell me again.)

/js

PS: Looking at large numbers and small numbers, the receiver may have
    to be prepared to do some conversion anyway.

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 10 Jun 2015 15:24:06 +0200

> On 10 Jun 2015, at 15:04, Martin Bjorklund <[email-masked]> wrote:
> 

Sure, but we just agreed the data model may not be available for anydata content. So anydata also doesn't guarantee a universal XML-JSON mapping.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 13 Jun 2015 08:35:35 -0700

On Wed, Jun 10, 2015 at 6:24 AM, Ladislav Lhotka <[email-masked]> wrote:

> Sure, but we just agreed the data model may not be available for anydata
> content. So anydata also doesn't guarantee a universal XML-JSON mapping.
>
>
I agree with Juergen.
YANG tools which do not know YANG or do not have the
modules that go with the YANG content are not important.
But...

This round-trip problem does not exist because the server
is required to know YANG (for RESTCONF at least).
The server will convert the XML to its proper internal format
and render it correctly in JSON (from the internal format).

Edits in either encoding will be parsed as the expected YANG type.
RESTCONF and NETCONF edits look the same on the inside.
The "anydata" constraints allow "any-encoding"  <--> YANG
conversion without content loss. (Which is why we need it.)

So even itf an off-line tool does not know YANG
or does not have the YANG files, I think the JSON
will be correct.

> Lada

Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 15 Jun 2015 13:23:01 +0200

> modules that go with the YANG content are not important.

I started this thread with asking whether YANG module(s) describing anydata
contents need to exist at all, and Martin replied it is not required.

So what does your software do with anydata instance for which no module
exists?

Apparently, the notion of "an unknown set of nodes that can be modelled
with YANG" permits different interpretations, which is IMO not good.

Lada