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

[Andy Bierman <[e-mail]>]

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

> Andy Bierman <[e-mail]> writes:
>
> > 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?
>
> container
> =========
>
> "foo": { "bar": 42 }
>
> becomes
>
> "foo": {
>   "@tagged-value": {
>     "@tag1": 54,
>     "@value": { "bar": 42 },
>     "@tag2": "hi!"
>   }
> }
>
> leaf
> ====
>
> "bar": 42
>
> becomes
>
> "bar": {
>   "@tagged-value": {
>     "@tag3" = false,
>     "@value": 42
>   }
> }
>
> leaf-list
> =========
>
> "foos": [ 6, 3, 7, 8]
>
> when tagging the whole array becomes
>
> "foos": {
>   "@tagged-value": {
>     "@value": [ 6, 3, 7, 8 ]
>     "tag4": true
>
> or, when tagging only one entry, becomes
>
> "foos":
>   [ 6,
>     { @tagged-value: { "@tag5": 1, "@value": 3 } },
>     7,
>     8
>   ]
>
> list
> ====
>
> is analogical, only scalar values (numbers in the above example) will be
> replaced with objects.
>



Try the example I did where entry1 is owned by owner admin1 and entry2
is owned by admin2.  I don't think this works.

This approach is way too complicated. The encoding scheme in the RESTCONF
draft
is easier to implement and it works for list and leaf-list siblings.


Andy



> >
> > Not only doesn't it work for siblings, but it depends on the order
> (@owner
> > followed by @value),
> > and JSON objects are not ordered.
>
> No, it doesn't, as you can see in the examples the "@value" member can
> appear at any place and the order of tags is also irrelevant.
>
> The only restriction is that no tag can have the key "@value".
>
> >
> >
> >
> >> 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?
>
> They are not strictly needed, only their encoding is much nicer, and I
> assume quite often XML attributes are supposed to be used for such binary
> properties, such as "protect", "deactivate" etc.
>
> So the examples above could also be written
>
> "@tagged-value": {
>   "@value": 42,
>   "@foo": true
> }
>
> and
>
> "@tagged-value": {
>   "@value": 42,
>   "@foo": true,
>   "@bar": true
> }
>
>
> > why do we need attributes within attributes?
>
> To be able to express that a single value has multiple properties.
>
> Lada
>
> >
> >
> > 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
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>