On Thu, Nov 12, 2015 at 08:10:51AM +0100, Ladislav Lhotka wrote: > 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).
e) is no better than c) in terms of interoperability /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/> _______________________________________________ netmod mailing list netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod
