> 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/>" 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
