> 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. 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
