Juergen Schoenwaelder <j.schoenwael...@jacobs-university.de> writes: > On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote: >> >> > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder >> > <j.schoenwael...@jacobs-university.de> wrote: >> > >> > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote: >> >> >> >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder >> >>> <j.schoenwael...@jacobs-university.de> wrote: >> >>> >> >>> On Wed, Nov 11, 2015 at 02:24:15PM +0100, Ladislav Lhotka wrote: >> >>>> >> >>>>> >> >>>>> I wrote 'effectively deprecated' and here is the text in 6020bis. >> >>>>> >> >>>>> Since the use of anyxml limits the manipulation of the content, it is >> >>>>> RECOMMENDED that the "anyxml" statement not be used to define >> >>>>> configuration data. >> >>>>> >> >>>>> It should be noted that in YANG version 1, anyxml was the only >> >>>>> statement that could model an unknown hierarchy of data. In many >> >>>>> cases this unknown hierarchy of data is actually modelled in YANG, >> >>>>> but the exact YANG model is not known at design time. In these >> >>>>> situations, it is RECOMMENDED to use anydata (Section 7.10) instead >> >>>>> of anyxml. >> >>>> >> >>>> The first paragraph is for config data and the second for data that can >> >>>> modelled with YANG. If we want to deprecate "anyxml" for use with data >> >>>> that are neither of these, 6020bis should say so. I'd be fine with that. >> >>>> >> >>> >> >>> The guidelines will say that any usage of anyxml in the IETF will be >> >>> carefully checked by YANG doctors. See Y34 for all details. >> >>> >> >>>>> There is more text in Y34-05 that will go into the guidelines. I call >> >>>>> this "effectively deprecated", you can call it differently if you >> >>>>> want. Frankly, this thread is about how to encode anyxml in JSON not >> >>>>> about the YANG 1.1 issue Y34. You may not like Y34-05 but this is what >> >>>>> we ended up with. >> >>>> >> >>>> I am strongly against encoding serialized XML as JSON strings. It is >> >>>> IMO totally useless and the spec would have to deal with awkward >> >>>> complications because it is not true that arbitrary XML-encoded anyxml >> >>>> content can be used without changes in JSON encoding. >> >>>> >> >>>> Perhaps the best solution would be to state that JSON encoding is >> >>>> incompatible with data models that use "anyxml". >> >>>> >> >>> >> >>> Perhaps we can only settle this by doing an opinion poll since >> >>> debating this forever is not useful. So what are the options? >> >>> >> >>> a) The JSON encoding does not define anyxml is not encoded at all. If >> >>> you use anyxml in a data model, the content will not appear in JSON >> >>> encodings. >> >>> >> >>> b) The JSON encoding defines that anyxml data is encoded as a string >> >>> containing XML. >> >>> >> >>> c) The JSON encoding defines that anyxml is encoded in whatever way >> >>> the implementor finds useful. >> >>> >> >>> d) If the anyxml content is actually valid anydata content, encode it >> >>> using anydata rules. Content that is not valid anydata content is >> >>> not encoded at all. >> >>> >> >>> Any options missing? >> >> >> >> Yes, the one that's in yang-json-06: >> >> >> >> e) 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". >> >> >> >> My preference is e), and then a). >> >> >> > >> > Is e) not the same as c)? I assume that the JSON encoding will always >> > be valid JSON (or I-JSON to be precise). So it seems the only refinement >> > of e) is the toplevel. >> >> c) sounds like the same data can be encoded in different ways depending on >> what the implementor finds useful, e.g. encode all numbers as strings. >> > > But e) says the same, I fail to see the difference here.
The way how c) is formulated is rather suggestive: beware, this is non-interoperable by its very nature. I think it is as interoperable as anyxml in XML encoding. Without knowing the context, translating anyxml chunks from XML to JSON, and vice versa, is quite problematic even for b). BTW, if the ability to translate between XML and JSON encodings is so critical for interoperability, then let me note that it's in general not possible for "anydata" either. Lada > > /js > > -- > 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/> -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
