> On 05 Oct 2015, at 13:44, Juergen Schoenwaelder > <[email protected]> wrote: > > On Mon, Oct 05, 2015 at 01:32:46PM +0200, Ladislav Lhotka wrote: >> >>> On 05 Oct 2015, at 11:57, Juergen Schoenwaelder >>> <[email protected]> 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. >> > > XML uses namespace URIs to identify the data model, JSON uses module
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. > 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. 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 > > /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
