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