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

[Ladislav Lhotka <[e-mail]>]

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.

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

> 
>  
> If so, do we have any other proposal?

Leave it to proponents of every use case to figure out ad hoc how to encode what’s needed, or resort to XML.

Lada

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

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C