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

[Ladislav Lhotka <[e-mail]>]

Andy Bierman <[e-mail]> writes:

...

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

I don't understand. XML schemas can define attribute values to be of other types, too, not only string.

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

This is another extension that violates the rule stated in RFC 6020, sec. 6.3.1:

   If a YANG compiler does not support a particular extension, which
   appears in a YANG module as an unknown-statement (see Section 12),
   the entire unknown-statement MAY be ignored by the compiler.

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

I'd suggest to define two generic constructs:

1. Metadata

Every JSON value (false / null / true / object / array / number / string) can be changed into a "@tagged-value" object, e.g. the number 42 can become

{
  "@tagged-value" : {
    "@owner": "admin1",
    "@value": 42
  }
}

Multiple metadata key-value pairs may be present inside the "@tagged-value" object.

2. Properties

For a property "foo", every JSON value can be changed into a "@foo" object, e.g.

{
  "@foo": 42
}

Such property objects may nest, e.g.

{
  "@bar":
  {
    "@foo": 42
  }
}
  
Both constructs work for list and leaf-list entries, and may be also combined.

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

I would prefer either to define global attributes outside YANG, or to introduce a new top-level statement for them in YANG 1.1, e.g. "global-attribute".

Lada

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