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

On Fri, Mar 21, 2014 at 8:37 AM, Andy Bierman <andy@yumaworks.com> wrote:

>
>
>
> On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman <andy@yumaworks.com> wrote:
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>>
>>> Dean Bogdanovic <deanb@juniper.net> wrote:
>>> > Hi,
>>> >
>>> > In draft yang leaf node is defined as name value pair in json
>>> >
>>> > If it would be represented, as an object then we can assign attributes
>>> to it.
>>> >
>>> > Example
>>> > "host-name" {
>>> >    "data" : "router",
>>> >       "attributes" : { "protect" : protect}
>>> > }
>>> >
>>> > We need attributes for several things, so lets try to figure out how
>>> to enable
>>> > them.
>>>
>>> I agree that the lack of attributes is a problem with the JSON
>>> mapping.
>>>
>>> The problem with your solution is that it adds noise to the normal
>>> case where there are no attributes.  We're using another encoding:
>>>
>>>    "host-name": "router",
>>>    "@host-name": {
>>>        "protect": "protect",
>>>        ...
>>>     }
>>>
>>> Yep, not very elegant...
>>>
>>>
>
> More importantly, it doesn't work for lists or leaf-lists.
> The attributes cannot be siblings (or ancestors) of the target data node.
>
> Consider the following YANG data-stmt, and how an attribute
> would be encoded in every data node (as a worse-case example).
>
>
> container top {
>   list A {
>     key id;
>     leaf id { type string; }
>     leaf-list aa { type int8; }
>   }
>   leaf host-name { type string; }
> }
>
> Plain JSON
>
> { "top" : {
>   "A" : [
>     { "id":"entry-1",
>       "aa": [42, 19]
>     },
>     { "id":"entry-2",
>       "aa" : [99, 11]
>     } ]
>   },
>   "host-name":"router"
>

oops -- host-name should be up 1 level, sibling of A
Same mistake below...

Andy

}
>
> Add attribute to each node:
>    leaf owner { type string; }
>
> With Owner Attribute using RESTCONF encoding:
>
> { "top" : {
>   "@owner":"system",
>   "A" : [
>     { "@owner":"admin1",
>       "id" : {
>         "@owner":"admin1",
>         "id": "entry-1"
>       },
>       "aa" : [ { "@owner":"admin1",  "aa": 42 },
>                  { "@owner":"admin1",  "aa": 19 } ]
>     },
>     { "@owner":"admin2",
>       "id" : {
>         "@owner":"admin2",
>         "id": "entry-2"
>       },
>       "aa" : [ { "@owner":"admin2",  "aa": 99 },
>                  { "@owner":"admin2",  "aa": 11 } ]
>     } ]
>   },
>   "host-name" : { "@owner":"system",
>                          "host-name":"router" }
> }
>
>
> This is not elegant either, but it works for all YANG node types.
> How would your encoding look for this example?
>
>
>
> Andy
>
>
>
>
>>
>> This is how RESTCONF encodes these attributes in a leaf:
>> (see sec. 3.4.1)
>>
>>    "host-name" : {
>>        "@protect" : "protect",
>>        "host-name" : "router"
>>    }
>>
>> Lada says that this is a YANG to JSON mapping and YANG has no attributes,
>> so the attribute encoding is in RESTCONF.  I think it would be better
>> if there was 1 mapping, instead of a different mapping in each protocol
>> that uses this JSON encoding of YANG data.
>>
>> I do not think YANG needs to model attributes!
>> The protocol may need to use them to tag data with meta-data.
>> We do not need to model some leafs as attributes and others
>> as child nodes in YANG data models.  Use RelaxNG instead
>> of YANG to do that.
>>
>>
>>
>>
>>> /martin
>>>
>>>
>> Andy
>>
>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
>