> 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. 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 _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
