Randy Presuhn <[email protected]> writes:
> Hi -
>
>>From: Ladislav Lhotka <[email protected]>
>>Sent: Oct 1, 2015 12:24 AM
>>To: Juergen Schoenwaelder <[email protected]>
>>Cc: Randy Presuhn <[email protected]>, [email protected]
>>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.
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 protected]
> https://www.ietf.org/mailman/listinfo/netmod
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/netmod
