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