> 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