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