> On 17 Nov 2015, at 21:03, Ladislav Lhotka <lho...@nic.cz> wrote: > >> >> On 17 Nov 2015, at 18:08, Andy Bierman <a...@yumaworks.com> wrote: >> >> >> >> On Tue, Nov 17, 2015 at 6:44 AM, Ladislav Lhotka <lho...@nic.cz> wrote: >> >>> On 17 Nov 2015, at 11:19, Robert Wilton <rwil...@cisco.com> 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> > > but the JSON string value > > "foo": "<foo/><bar/>"
Sorry, this was supposed to be "foo" : "<bar/><baz/>" Lada > > > 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 >>>> <j.schoenwael...@jacobs-university.de> 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 >>>> >>>> netmod@ietf.org >>>> 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 > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
