Re: [netmod] Y34: use cases for anydata

[Martin Bjorklund <[e-mail]>]

Ladislav Lhotka <[e-mail]> wrote:
> 
> > On 28 Jan 2015, at 11:10, Martin Bjorklund <[e-mail]> wrote:
> > 
> > Ladislav Lhotka <[e-mail]> wrote:
> >> 
> >>> On 28 Jan 2015, at 10:06, Martin Bjorklund <[e-mail]> wrote:
> >>> 
> >>> Ladislav Lhotka <[e-mail]> wrote:
> >>>> 
> >>>>> On 28 Jan 2015, at 09:10, Martin Bjorklund <[e-mail]> wrote:
> >>>>> 
> >>>>> Juergen Schoenwaelder <[e-mail]> wrote:
> >>>>>> I do not think we make progress this way and we probably need to find
> >>>>>> a way to do a mailing list hum to figure out where the _WG_ stands on
> >>>>>> this issue and not just the two of us.
> >>>>> 
> >>>>> At this point, I think it would be useful if you could take a step
> >>>>> back and formulate the problem.  I must I admit I got lost in the
> >>>>> discussion.  I *think* the issue now has to do with the json encoding
> >>>>> of anydata and anyxml, if we decide to introduce anydata?
> >>>> 
> >>>> Yes, the discussion sometimes wandered into areas that are unrelated
> >>>> to anyxml/anydata.
> >>>> 
> >>>> As for anydata, I’d be happy with just renaming anyxml to anydata,
> >>> 
> >>> I don't think works.  It is not backwards compatible, and it would
> >>> break the definition in 6241.
> >> 
> >> Well, yes, I mean keeping anyxml as a (deprecated) synonym.
> > 
> > Not synonym, since 'anyxml' truly is any xml, which 'anydata' is not.
> > And probably not deprecated, but rather "think twice before using”.
> 
> Do you mean that for modules containing anyxml no JSON encoding will
> be defined?

The json doc has to say *something*, and maybe the current text is
fine.  It should be pointed out that the anyxml mapping is
implementation dependent.


/martin



> 
> I’d prefer to keep the current definition in the yang-json draft even though anyxml is a misnomer. There are other formulations in 6020 that are XML- and NETCONF-specific.
> 
> > 
> >> Which 6241
> >> definition do you mean?
> > 
> > rpc edit-config etc.  Search for anyxml.
> 
> Sure, but it’s OK if anyxml continues to exist.
> 
> Lada
> 
> > 
> >> The advantage of this solution is that existing data formats (RDF
> >> comes to my mind) that have nothing in common with YANG can be
> >> potentially piggybacked in anydata. Andy will say such a use case
> >> doesn’t exist yet but I think this *might* be potentially
> >> useful. Assuming that YANG will become the universal schema language
> >> for network protocols is not realistic.
> >> 
> >>> 
> >>> My preference would be Y34-02 (keep anyxml, add anydata), with the
> >>> clarifications suggested by Juergen (discourage the usage of anyxml).
> >>> 
> >>>> I understand that Andy wants to exclude XML mixed content, so I can
> >>>> also agree with adding restrictions for anydata in the sense that the
> >>>> content can *potentially* be modelled in YANG.
> >>> 
> >>> Yes, I think we want to allow for the case where a consumer/producer
> >>> of 'anydata' does not know the YANG data model (generic logger, some
> >>> proxy, etc).  So "potentially" modelled in YANG should be fine.
> >>> 
> >>> The issue I see can be illustrated like this:
> >>> 
> >>>                      +--------+
> >>> input w/ anydata --> | server | -- output -->
> >>>                      +--------+
> >>> 
> >>> I.e., some implementation gets data w/ anydata in it, and is supposed
> >>> to send this to some client that needs to be able to interpret this
> >>> data.
> >>> 
> >>> Let's assume the data is this:
> >>> 
> >>> namespace urn:x;
> >>>  ...
> >>> container x {
> >>>   anydata y;
> >>> }
> >>> 
> >>> and one example of something we can put into this anydata is:
> >>> 
> >>> namespace urn:foo;
> >>> ...
> >>> container foo {
> >>>   leaf bar {
> >>>     type int32;
> >>>   }
> >>>   leaf if-type {
> >>>     type identityref {
> >>>       base if:interface-type;
> >>>     }
> >>>   }
> >>> }
> >>> 
> >>> module ex-ethernet {
> >>>   namespace urn:exeth;
> >>>   ...
> >>>   identity ethernet { ... }
> >>> }
> >>> 
> >>> 
> >>> 
> >>> So the input could be:
> >>> 
> >>> (A)
> >>> <x xmlns="urn:x">
> >>>   <y>
> >>>     <foo xmlns="urn:foo" xmlns:p0="urn:exeth">
> >>>       <bar>42</bar>
> >>>       <if-type>p0:ethernet</if-type>
> >>>     </foo>
> >>>   </y>
> >>> </x>
> >>> 
> >>> 
> >>> There are four cases:
> >>> 
> >>> 1.  input xml, output xml
> >>> 
> >>> The problem here has to do with namespace prefixes.
> >>> 
> >>> Suppose the input was received as:
> >>> 
> >>> (B)
> >>> <x xmlns="urn:x" xmlns:p1="urn:exeth">
> >>>   <y>
> >>>     <foo xmlns="urn:foo">
> >>>       <bar>42</bar>
> >>>       <if-type>p1:ethernet</if-type>
> >>>     </foo>
> >>>   </y>
> >>> </x>
> >>> 
> >>> The server doesn't know that if-type is of type identityref, so it
> >>> doesn't know that "eth:" is a prefix.  It just stores everything as
> >> 
> >> You probably mean “p1:” here.
> > 
> > Yes.
> > 
> >> But if the server has the data model, it
> >> should know this is an identityref and “p1:” is a prefix, right?
> > 
> > Sure.  The use case is about servers that do not know about the data
> > model.
> > 
> >>> strings.  But when it returns this node to a client, it must make
> >>> sure the prefix is declared properly.
> >>> 
> >>> We can solve this for anydata by saying that 
> >>> the anydata node must have all namespace declarations in the anydata
> >>> subtree in the XML encoding.  Thus the input (B) would be illegal,
> >>> but (A) legal.
> >>> 
> >>> 
> >>> 2.  input json, output json
> >>> 
> >>> In json, there are no namespace prefixes, so that is not an issue.
> >>> Also, if both input and output is json, the implementation can store
> >>> the data as received, and return it in the same way.
> >>> 
> >>> 
> >>> 3.  input xml, output json
> >>> 
> >>> This is tricky, since in order to produce correct json both for leaf
> >>> 'bar' and leaf 'if-type', the server needs schema knowledge; 'bar'
> >>> must be encoded as 42 rather than "42", and 'if-type' must be
> >>> encoded as "ex-ethernet:ethernet" rather than "p0:ethernet”.
> >> 
> >> It doesn’t make much sense to me that the server act as a transparent
> >> relay. I think one can assume that for every anydata node the server
> >> has a schema, although it needn’t be expressed in YANG.
> > 
> > I would stay out of "needn't be expressed in YANG".  Let's just say
> > that the server knows the schema.
> > 
> > 
> >> If there really was a use case for a schema-agnostic server, we could
> >> define a default (and lossy) XML->JSON translation.
> > 
> > 
> > 
> > /martin
> 
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
> 
> 
> 
>