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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

> On Thu, Mar 20, 2014 at 8:25 AM, Andy Bierman <[e-mail]> wrote:
>
>>
>>
>>
>> On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <[e-mail]> wrote:
>>
>>> Dean Bogdanovic <[e-mail]> 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.

An option for boolean-type properties is to wrap the affected object or value, e.g.

"@protect": {
    "host-name": ...
}

or

"foo" : [ 1, 2, {"@protect": 3}, 4]

Instead of defining a general JSON equivalent of XML attributes, it might actually be easier to come up with an ad hoc representation for every use case. This is the approach of some native JSON applications such as MongoDB.

So, the specification of each global property (e.g. "protected") would also define an appropriate encoding in both XML and JSON.

>
> 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"
> }
>
> 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?

"@owned-object": {
    "@owner": "system",
    "host-name": "router"
}

Lada

>
>
>
> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>
>>
> _______________________________________________
> netmod mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netmod

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