Subject: Re: [netmod] 6020bis - anydata

From: Randy Presuhn <[email-masked]>
Date: Thu, 1 Oct 2015 16:05:20 -0700 (GMT-07:00)

Hi -

>From: Ladislav Lhotka <[email-masked]>
>Sent: Oct 1, 2015 12:24 AM
>To: Juergen Schoenwaelder <[email-masked]>
>Cc: Randy Presuhn <[email-masked]>, [email-masked]
>Subject: Re: [netmod] 6020bis - anydata
...
>Fine by me. So here is an updated proposal:
>
>OLD
>
>   The "anydata" statement is used to represent an unknown set of nodes
>   that can be modelled with YANG.  An example of where this can be
>   useful is a list of received notifications, where the exact
>   notifications are not known as design time.
>
>NEW
>
>   The "anydata" statement is used to represent an unknown set of nodes
>   that can be modelled with YANG but for which the data model is not
>   known at module design time. It is possible, though not required, for

s/know/known/

>   the data model for "anydata" content to become known through protocol
>   signalling or other means that are outside the scope of this
>   document, as is the server and client behaviour.

I'd end the sentence at "document." The rest of the sentence doesn't
really add anything.

There's still a big lump under the carpet, but no one else appears
concerned about it, so I'll desist from further comment.

Randy

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 05 Oct 2015 11:48:10 +0200

> concerned about it, so I'll desist from further comment.

I am certainly concerned. The current definition of "anydata" ("an
unknown set of nodes that can be modelled with YANG") is IMO
insufficient because, for one, it doesn't even eliminate mixed content
in XML, which can be modelled with YANG's "anyxml" statement.

In my view, the idea behind "anydata" was that it would be possible to
build a regular data (sub)tree from schema-less data. However, this
seems to be difficult, at least on a server supporting both XML and
JSON, and so benefits of "anydata" over "anyxml" are really
questionable.

Lada

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

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

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Oct 2015 11:57:11 +0200

> in XML, which can be modelled with YANG's "anyxml" statement.

Good point. I think we should clarify that anyxml is excluded.
 
> JSON, and so benefits of "anydata" over "anyxml" are really

I do not think anydata was driven by the idea to build a regular data
(sub)tree from schema-less data.

I think anydata works fine with both JSON and XML as long as the
encoder has the data model, which seems to be a reasonable assumption
for servers and perhaps also for data-model driven clients. The
problem are any generic components in between clients and servers but
that can also be seen as a problem of the encodings and not of
anydata itself.

/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: Mon, 5 Oct 2015 13:32:46 +0200

> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Then YANG extensions probably need to be excluded, too.

> encoder has the data model, which seems to be a reasonable assumption

If it is so,  then what we really need is a standard mechanism that allows for signalling the data model at run time. Without that, as Randy pointed out, there is no way to make sure that the server and client use the same data model for a particular “anydata” node, and then the difference between “anydata” and “anyxml” is no more interesting. All external means (or descriptions) that may potentially provide “late binding” of the data model are applicable to “anyxml” as well.

Lada

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Mon, 5 Oct 2015 13:44:15 +0200

> If it is so,  then what we really need is a standard mechanism that allows for signalling the data model at run time. Without that, as Randy pointed out, there is no way to make sure that the serve…

XML uses namespace URIs to identify the data model, JSON uses module
names to identify the data model. The only discussion point here is
the level of uniqueness (and of course why we use two different data
model identifiers - but it seems nobody except me or perhaps Randy
cares).

And no, anyxml was defined to be 'any XML' and anydata has been
defined to be 'any data modeled in YANG' (without anyxml). This really
has been settled, please read the archives if you are still unsure
what the difference is.

/js

---

From: Ladislav Lhotka <[email-masked]>
Date: Mon, 5 Oct 2015 14:23:30 +0200

> On 05 Oct 2015, at 13:44, Juergen Schoenwaelder <[email-masked]> wrote:
> 

Sorry, this is not true: A data model is identified by a set of YANG modules with their exact revisions + features (+ deviations). A URI or module name by itself doesn’t help if you don’t have the rest.

> has been settled, please read the archives if you are still unsure

But the exclusion of anyxml wasn’t part of that discussion, was it? And since you didn’t answer my comment about extensions, let me put it differently: Are XML attributes allowed in XML-encoded anydata contents?

Randy talks about “a big lump under the carpet”, so maybe I am not alone in thinking that the concept of anydata needs to be clarified or reconsidered - and WGLC is the last chance to do it.

I tried to formulate a clarification but it turned out to be unacceptable, and its relaxed form useless, as you rightly pointed out. So can somebody propose a better definition of anydata?  

Lada