Re: [netmod] Y34: use cases for anydata

[Martin Bjorklund <[e-mail]>]

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.

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


4.  input json, output xml

  Similar problems as in 3.





/martin