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

[Andy Bierman <[e-mail]>]

On Sun, Mar 23, 2014 at 3:07 AM, Martin Bjorklund <[e-mail]> wrote:

> 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 agree this is getting too complicated.


> 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.
>
>
Clearly the protocol cannot rely on attributes if they are
not supported in some encoding schemes. Only schemes that can
map 100% of the protocol messages can be considered.

I am OK with leaving attributes out of RESTCONF (so they can be left
out of the YANG to JSON mapping).




> /martin
>

Andy