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

[Andy Bierman <[e-mail]>]

On Sun, Mar 23, 2014 at 2:42 AM, Ladislav Lhotka <[e-mail]> wrote:

> 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.
>
>
I meant they are encoded in XML as quoted strings


> >
> > 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.
>
>
I don't think this works for lists and leaf-lists.
Can you expand the encoding to show a real example with
container, list, leaf, and leaf-list used?

Not only doesn't it work for siblings, but it depends on the order (@owner
followed by @value),
and JSON objects are not ordered.



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



why are properties needed?
why do we need attributes within attributes?


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