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

[Andy Bierman <[e-mail]>]

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



> If so, do we have any other proposal?
>
> I am all for a simpler solution!
>
>

Putting attributes at the sibling level does not work for leaf-lists.
Even for leafs, it is difficult to parse.  JSON objects are unordered,
so the "@foo" could appear anywhere, even before "foo".  The schemes
I proposed always keeps the attributes within the node for the attributes
(just like XML).

One idea I had was to simply disallow attributes for leaf and leaf-list.
They can only go in container or list nodes.  This is restrictive but then
there
will not be any dual decoding possibilities.



> /martin
>

Andy