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

[Ladislav Lhotka <[e-mail]>]

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. 

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