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

[Martin Bjorklund <[e-mail]>]

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.

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.


/martin