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

[Ladislav Lhotka <[e-mail]>]

Martin Bjorklund <[e-mail]> writes:

> 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.
>> 
>> >
>> > 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.
>
> This makes both client and server programming much more complex.  The
> whole point of using JSON is supposedly that it maps well to built-in
> datastructures in modern languages.  This property makes parsing
> trivial, and makes it easy to get values.  For example:
>
>   res = json_parse(...)
>   if res['ssh']['enabled']:
>      ...
>
> now, with the proposed encoding, I have to be prepared for 'ssh' being
> a '@tagged-value', and '@enabled' being a tagged-value, and
> combinations thereof:
>
>   if res['ssh']['enabled']
>      or res['@tagged-value']['ssh']['enabled']
>      or res['@tagged-value']['ssh']['@tagged-value']['enabled']
>      or ...
>
> As I write this I realize that I don't really understand your
> proposal..., so the code above is not correct - but the point is the
> same; as soon as you allow multiple encodings you make coding much
> more complex.

I don't know whether the "enabled" parameter is a node in the data model or a global attribute that can be added to any instance. Show me the intended XML encoding.

What I was trying to achieve was to be able to turn any JSON value into an object where the value is present together with any number of tags.

Please check the examples in my response to Andy (and maybe ignore the "property" thing for the time being, it is just an optimization for a special case). 

>
> Maybe the original JSON mapping idea is the only one that works; i.e.,
> map pure YANG data to JSON.  No meta data.  A protocol that needs meta
> data should not use JSON; use XML instead.

I tend to agree, and that's why I've been relucant to address attributes in the draft. For "pure" YANG-based data JSON is an excellent fit (IMO better than XML) and some applications should be just fine with it.

Lada 

>
>
> /martin

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