On Wed, Nov 11, 2015 at 03:14:13PM +0100, Ladislav Lhotka wrote: > > > On 11 Nov 2015, at 14:59, Juergen Schoenwaelder > > <[email protected]> wrote: > > > > On Wed, Nov 11, 2015 at 02:53:49PM +0100, Ladislav Lhotka wrote: > >> > >>> On 11 Nov 2015, at 14:44, Juergen Schoenwaelder > >>> <[email protected]> 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. /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 [email protected] https://www.ietf.org/mailman/listinfo/netmod
