> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder
> <j.schoenwael...@jacobs-university.de> wrote:
>
> On Mon, Oct 05, 2015 at 11:48:10AM +0200, Ladislav Lhotka wrote:
>
>> 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.
>
> Good point. I think we should clarify that anyxml is excluded.
Then YANG extensions probably need to be excluded, too.
>
>> 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.
>
> 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
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
> 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/>
--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
