> On 17 Nov 2015, at 21:18, Andy Bierman <[email protected]> wrote: > > > > On Tue, Nov 17, 2015 at 12:11 PM, Ladislav Lhotka <[email protected]> wrote: > > > On 17 Nov 2015, at 21:03, Ladislav Lhotka <[email protected]> wrote: > > > >> > >> On 17 Nov 2015, at 18:08, Andy Bierman <[email protected]> wrote: > >> > >> > >> > >> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka <[email protected]> wrote: > >> > >>> On 17 Nov 2015, at 11:19, Robert Wilton <[email protected]> wrote: > >>> > >>> As a possible compromise, what about something like: > >>> > >>> The JSON encoding defines that anyxml may be encoded in whatever way the > >>> implementor finds useful, or even not at all. If a preferred custom > >>> encoding is not being used, then it is suggested that anyxml data be > >>> encoded as a string containing XML to maximize legacy interoperability. > >> > >> While this is quite complicated, I don't think it helps in any way. There > >> are no anyxml objects that need to be encoded, so what an implementor > >> finds useful is totally irrelevant. The yang-json spec should state what's > >> permitted as the content of an anyxml instance in JSON encoding, and > >> that's all. To this end, the current text is IMO sufficient, except that > >> the "otherwise" part may be misleading - but it's not necessary. > >> > >> Note that XML-in-JSON-string has its share of problems and may not be > >> interoperable either: the content of an anyxml instance in XML encoding > >> needn't be a well-formed XML document. > >> > >> > >> So now anyxml includes XML that is not even well-formed? > > > > Sure. First, in the XML encoding the anyxml chunk may inherit namespace and > > entity declarations from the outer context. This could be corrected by > > adding these declarations to the JSON string. But then also, if we have > > > > anyxml foo; > > > > then this is a valid XML encoding > > > > <foo> > > <bar/> > > <baz/> > > </foo> > > > > > (!) The internal representation of data is implementation-specific. > > > > but the JSON string value > > > > "foo": "<foo/><bar/>" > > Sorry, this was supposed to be > > "foo" : "<bar/><baz/>" > > > > If the internal server code generates complex nodes they will > be rendered correctly. > > { "foo" : { > "bar":[null], > "baz":[null] > } > } > > This is what our server will generate if the internal representation > would be rendered in XML as you describe. This encoding can be > easily converted to XML.
Yes, but we are talking about encoding anyxml instances as JSON strings containing well-formed XML - this is what Martin proposed in Yokohama, if I understood it correctly. And yes, I think we are wasting time. Seeking interoperability where there is none is useless. I propose this change to sec. 5.6 of the yang-json document: OLD An anyxml instance is encoded as a JSON name/value pair which MUST satisfy I-JSON constraints. Otherwise it is unrestricted, i.e., the value can be an object, array, number, string or one of the literals "true", "false" and "null". NEW An anyxml instance is encoded as a JSON name/value pair which MUST satisfy I-JSON constraints. The value can be an object, array, number, string or one of the literals "true", "false" and "null". This BTW also allows for strings containing XML. Lada > > > > Lada > > > Andy > > > > > > > > > is not a well-formed XML document because it doesn't have a single document > > element. > > > >> This is news to me. Maybe you mean it is a well-formed snippet > >> that may not be complete as an XML instance document. > >> > >> You cannot say "MUST do X, otherwise do Y". This is incorrect > >> use of RFC 2119 terminology. If MUST is used, that is the only option. > > > > OK, I will reformulate it. > > > >> You also need to explain exactly what interoperability is lost if the MUST > >> is not followed. (e.g., mixed mode XML will not be translated properly to > >> JSON). > > > > If the MUST isn't followed, then the interoperability problems that > > motivated I-JSON restrictions come into play. It has nothing to do with > > mixed XML content - translation between JSON and XML (and vice versa) in > > general cannot be guaranteed. > > > > Lada > > > >> > >> > >> Andy > >> > >> > >> > >> Lada > >> > >>> > >>> Rob > >>> > >>> > >>> On 16/11/2015 16:50, Andy Bierman wrote: > >>>> > >>>> > >>>> On Mon, Nov 16, 2015 at 3:55 AM, Juergen Schoenwaelder > >>>> <[email protected]> wrote: > >>>> On Sat, Nov 14, 2015 at 09:05:00AM -0800, Andy Bierman wrote: > >>>>> > >>>>> YANG 1.1 is going to take 2 more years if we slowly revisit every issue. > >>>>> I thought the whole point of the issue tracker was to prevent this sort > >>>>> of thing. The rule should be "what new details have emerged that > >>>>> should cause us to change the previous decision?" > >>>>> > >>>> > >>>> Andy, please note that this is a discussion primarily around the JSON > >>>> document and not around the YANG 1.1 document. > >>>> > >>>> > >>>> That doesn't mean we haven't discussed this issue for a long time > >>>> already. > >>>> I thought we decided anyxml is not that interoperable and so we have > >>>> anydata that is supposedly interoperable. > >>>> > >>>> So why try to constrain the JSON encoding? > >>>> For anyone sending mixed mode XML encoded as JSON, > >>>> they can get creative and do whatever they want. > >>>> > >>>> > >>>> For everybody else, anydata is simple enough to encode and decode. > >>>> > >>>> > >>>> /js > >>>> > >>>> Andy > >>>> > >>>> > >>>> -- > >>>> 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/> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> > >>>> [email protected] > >>>> https://www.ietf.org/mailman/listinfo/netmod > >>> > >> > >> -- > >> Ladislav Lhotka, CZ.NIC Labs > >> PGP Key ID: E74E8C0C > >> > >> > >> > >> > >> > > > > -- > > 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 -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
