Andy Bierman <[email protected]> writes: > On Wed, Jun 10, 2015 at 6:24 AM, Ladislav Lhotka <[email protected]> wrote: > >> >> > On 10 Jun 2015, at 15:04, Martin Bjorklund <[email protected]> wrote: >> > >> > Juergen Schoenwaelder <[email protected]> wrote: >> >> On Wed, Jun 10, 2015 at 09:05:07AM +0200, Ladislav Lhotka wrote: >> >>> >> >>> It is also important for the JSON encoding - it means there won’t >> >> necessarily be a way for mapping XML-encoded instance to JSON and >> >> vice versa. >> >>> >> >> >> >> Because of two different namespace identifiers. So here we go. >> > >> > There are other reasons as well, e.g., <foo>42</foo> might be encoded >> > as: >> > >> > "foo": 42 >> > >> > or >> > >> > "foo": "42" >> > >> > or >> > >> > "foo": [42] >> > >> > or >> > >> > "foo": ["42"] >> > >> > depending on the data model. >> > >> > >> > The JSON encoding process needs the data model. >> >> >> Sure, but we just agreed the data model may not be available for anydata >> content. So anydata also doesn't guarantee a universal XML-JSON mapping. >> >> > I agree with Juergen. > YANG tools which do not know YANG or do not have the > modules that go with the YANG content are not important.
I started this thread with asking whether YANG module(s) describing anydata contents need to exist at all, and Martin replied it is not required. So what does your software do with anydata instance for which no module exists? Apparently, the notion of "an unknown set of nodes that can be modelled with YANG" permits different interpretations, which is IMO not good. Lada > But... > > This round-trip problem does not exist because the server > is required to know YANG (for RESTCONF at least). > The server will convert the XML to its proper internal format > and render it correctly in JSON (from the internal format). > > Edits in either encoding will be parsed as the expected YANG type. > RESTCONF and NETCONF edits look the same on the inside. > The "anydata" constraints allow "any-encoding" <--> YANG > conversion without content loss. (Which is why we need it.) > > So even itf an off-line tool does not know YANG > or does not have the YANG files, I think the JSON > will be correct. > > > > >> Lada >> >> > > Andy > > > >> > >> > >> > >> > /martin >> >> -- >> Ladislav Lhotka, CZ.NIC Labs >> PGP Key ID: E74E8C0C >> >> >> >> >> _______________________________________________ >> 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
