On Wed, Nov 11, 2015 at 7:32 AM, Juergen Schoenwaelder <
j.schoenwael...@jacobs-university.de> wrote:
> 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.
>
>
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
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.
/js
>
Andy
>
> --
> 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
>
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
