On Tue, Nov 17, 2015 at 11:03 PM, Ladislav Lhotka <[email protected]> wrote:
> > > On 17 Nov 2015, at 21:18, Andy Bierman <[email protected]> wrote: > > > > > > > > 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. > > Yes, but we are talking about encoding anyxml instances as JSON strings > containing well-formed XML - this is what Martin proposed in Yokohama, if I > understood it correctly. > > This string encoding is totally useless. We will never implement it. There is no way any client code is going to double parse the string. (i.e. pass the string to an XML parser) This is useful for WEB banners where the correct modeling tool is (and always has been) a leaf. And yes, I think we are wasting time. Seeking interoperability where there > is none is useless. I propose this change to sec. 5.6 of the yang-json > document: > > OLD > An anyxml instance is encoded as a JSON name/value pair which MUST > satisfy I-JSON constraints. Otherwise it is unrestricted, i.e., the > value can be an object, array, number, string or one of the literals > "true", "false" and "null". > > NEW > An anyxml instance is encoded as a JSON name/value pair which MUST > satisfy I-JSON constraints. The value can be an object, array, number, > string or one of the literals "true", "false" and "null". > > This BTW also allows for strings containing XML. > > IMO this is a bit more clear: s/Otherwise it is/It is otherwise/ It was not clear before that otherwise is in addition to MUST. > Lada > > Andy > > > > > > > > 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 > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > > > >
_______________________________________________ netmod mailing list [email protected] https://www.ietf.org/mailman/listinfo/netmod
