Re: [netmod] attributes in draft-lhotka-netmod-yang-json

[Andy Bierman <[e-mail]>]

On Wed, Mar 26, 2014 at 8:51 AM, Martin Bjorklund <[e-mail]> wrote:

> Andy Bierman <[e-mail]> wrote:
> > On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund <[e-mail]>
> wrote:
> >
> > > Ladislav Lhotka <[e-mail]> wrote:
> > > >
> > > > On 26 Mar 2014, at 15:43, Andy Bierman <[e-mail]> wrote:
> > > >
> > > > >
> > > > >
> > > > >
> > > > > On Wed, Mar 26, 2014 at 7:27 AM, Martin Bjorklund <[e-mail]>
> > > > > wrote:
> > > > > Andy Bierman <[e-mail]> wrote:
> > > > > > On Wed, Mar 26, 2014 at 7:10 AM, Ladislav Lhotka <[e-mail]>
> > > > > > wrote:
> > > > > >
> > > > > > >
> > > > > > > On 26 Mar 2014, at 14:57, Martin Bjorklund <[e-mail]>
> wrote:
> > > > > > >
> > > > > > > > Ladislav Lhotka <[e-mail]> wrote:
> > > > > > > >> Martin Bjorklund <[e-mail]> writes:
> > > > > > > >>
> > > > > > > >>> Hi,
> > > > > > > >>>
> > > > > > > >>> Here's yet another attempt to handle attributes in JSON,
> > > without
> > > > > > > >>> changing the encoding for the case that there are no
> attributes
> > > > > > > >>> present.
> > > > > > > >>>
> > > > > > > >>> In all examples, the attributes "inactive" and "etag" are
> > > present.
> > > > > > > >>>
> > > > > > > >>> Attributes are encoded differently depending on the type of
> > > object:
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> leaf
> > > > > > > >>> ----
> > > > > > > >>>
> > > > > > > >>> Encode the attributes as a sibling to the leaf.
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>  leaf foo {
> > > > > > > >>>    type string;
> > > > > > > >>>  }
> > > > > > > >>>
> > > > > > > >>>  "foo": "some value";
> > > > > > > >>>  "@foo": {
> > > > > > > >>>     "inactive": true,
> > > > > > > >>>     "etag": "...";
> > > > > > > >>>   }
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>> list instance
> > > > > > > >>> -------------
> > > > > > > >>>
> > > > > > > >>> Encode the attributes within the list instance.
> > > > > > > >>>
> > > > > > > >>>
> > > > > > > >>>  list bar {
> > > > > > > >>>    key name;
> > > > > > > >>>    leaf name {
> > > > > > > >>>      type string;
> > > > > > > >>>    }
> > > > > > > >>>    ...
> > > > > > > >>>  }
> > > > > > > >>>
> > > > > > > >>>  "bar": [
> > > > > > > >>>     {
> > > > > > > >>>        "@bar": {
> > > > > > > >>>           "inactive": true,
> > > > > > > >>>           "etag": "..."
> > > > > > > >>>         }
> > > > > > > >>>         "name": "instance name";
> > > > > > > >>>      }]
> > > > > > > >>>
> > > > > > > >>
> > > > > > > >> This could be ambiguous:
> > > > > > > >>
> > > > > > > >> list bar {
> > > > > > > >>  key name;
> > > > > > > >>  leaf name { ... }
> > > > > > > >>  leaf bar { ... }
> > > > > > > >> }
> > > > > > > >>
> > > > > > > >> Then you don't know whether the attributes belong to the
> list
> > > entry
> > > > > > > >> or to the contained leaf.
> > > > > > > >
> > > > > > > > Right. Then we use "@@bar" for the list / container
> attributes.
> > > > > > >
> > > > > > > OK, then this scheme is fine with me.
> > > > > > >
> > > > > > >
> > > > > > Looks more complicated than other solution proposals.
> > > > >
> > > > > Do we agree that we don't want different encodings for values if
> there
> > > > > are attributes or not?  I.e., if my code works when no attributes
> are
> > > > > present, it should also work if there are attributes?
> > > >
> > > > I am not sure even your encoding satisfies this requirement. At least
> > > > your code has to be instructed to ignore the attribute stuff.
> > >
> > > In general, I think robust code would ignore unknown fields.
> > >
> > > > > Not if the normal encoding is painful to use.
> > > > > The use attributes is going to be rare.
> > > > > I want the expected "plain" encoding when there are no attributes.
> > > > > Code that generates JSON and does not care about attributes
> > > > > must not be rendered useless because the JSON is specially encoded
> > > > > in RESTCONF.  We want to leverage wide knowledge of JSON,
> > > > > not invent our own incompatible version of it.
> > > >
> > > > This is my preference, too.
> > >
> > >
> > This is not a preference. It is critical that plain JSON code
> > that knows how to deal with plain data structures does not break.
> >
> > Well, of course.  But I don't think anyone has proposed something that
> > > is not valid json.
> > >
> > >
> >
> > That is not the point.  A normal JSON tool is going to generate or expect
> > "foo":"bar" for a simple leaf, or "foo":[1, 2, 3]  for a simple array,
> for
> > example.
> >
> > The encoding for the data nodes MUST be exactly
> > the same as the YANG-to-JSON draft now, if no attributes are used.
>
> This is exactly my point!
>
> > Only a client that knows about attributes will need to associate an
> > attribute
> > with its parent data node.
>
> Yes!
>
> > This must be easy to do.
>
> As easy as possible.  IMO this falls into the category of "possible to
> do".  The normal case must be easy to do.
>
> > Other clients should be able to ignore attributes.
>
> Yes!
>
> > A server must reject messages with unknown attributes.
> >
> > I agree that no proposal is satisfactory for leaf or leaf-list nodes.
>
> My proposal satifies all these properties, except "easy to do
> attributes".
>
>
Yes -- there are corner cases to detect (like array given for @foo,
but foo is a leaf).  The most annoying part is parsing @foo first,
and holding onto the data until foo is found (if it exists - another error
to detect is @foo but no foo).

I guess this is OK.
NACM does not provide any control over access to attributes,
which is good.  We cannot have NACM filter out a leaf-list value
but not filter out the attributes for the associated leaf-list instance.



>
> /martin
>

Andy