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?

Observations:

 - Except b), none of the options is interoperable. Option d) is
   interoperable for the anydata subset of anyxml.
 - It seems a) is simplest to implement, b) might be expensive to
   implement and use.
 - Some implementations use internal data stores that can only deal
   with data that can be modelled with YANG and for those implementations
   anyxml is effectively the same as anydata and d) migth be close to
   a) in terms of implementation costs.

Any other observations missing?

/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
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

Reply via email to