On Wed, Nov 11, 2015 at 08:31:14AM -0800, Andy Bierman wrote: > On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder < > [email protected]> wrote: > > > 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. > > > > > IMO the only option is (f) > > f) If the anyxml content is actually valid anydata content, encode it > using anydata rules. Content that is not valid anydata content is > either not encoded at all, or encoded in an implementation-specific > manner
This is essentially the same as d). > Nobody has answered my question about the "WEB banner" type of object. > The only reports we have ever heard on this sort of object indicate that > a leaf is used, NOT ANYXML! Nobody seems to be using anyxml to store WEB > page snippets in their configuration. Clearly a leaf is interoperable for > both XML and JSON, plus NETCONF or RESTCONF. But we keep insisting > the YANG to JSON mapping needs to support this use of anyxml. > > We use anyxml in RPC parameters in ietf-netconf, but the XML > is not expected to be mixed-mode XML. Only elements and attributes > are used. Well, there are subtle differences. For example, a leaf-list only allows unique values. So by way of example, anydata is in fact more restrictive than anyxml even if we only consider XML elements and attributes. /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
