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

[Andy Bierman <[e-mail]>]

On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka <[e-mail]> wrote:

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

The attribute mapping needs to correspond to the XML attribute mapping.
Attributes have string values, so the mapping above will not work.

Attributes can be qualified or unqualified.  If qualified, then the
module-name
is used as a prefix:

  "foo" [ 1, 2, { "@foo-mod:owner":"admin1", "foo":3}, {
"@foo-mod:owner":"admin2", "foo":4},


This approach presumes the attribute has a YANG module name that defines
the attribute,
which is of course not allowed.

RFC 6241 defines XML attributes for the <get> operation, using a hack
called the  'get-filter-element-attributes' extension.
http://www.netconfcentral.org/modules/ietf-netconf/2011-06-01#get-filter-element-attributes.56

The NETCONF-EX <get2> operation has a "with-metadata" parameter that uses
identities
to map attributes to YANG.

I think a standard mechanism is needed to properly map attributes to JSON
and XML.
A robust deterministic mapping is required, ad-hoc or not. Perhaps an
identity registration
scheme is good enough, since it provides a module-name for the attribute
name.
(i.e., the tool needs to know all the identities derived-from the
'metadata' base identity)

  module foo-mod {
    ...
    import nexconf-ex { prefix nx; }

    identity owner {
       base nx:metadata;
    }
  }




Andy



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
>