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

[Andy Bierman <[e-mail]>]

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

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


This seems to be a problem in every proposal.
In the RESTCONF approach, a leaf will either be a simple type
or an object.  I think the other 2 proposals alter objects
even more, but to an application, moving data at all introduces
complexity.

Your comment assumes a plain JSON parser is going to
parse this text into a plain object.  A plain XML parser
knows about attributes, but in JSON they are not handled special.
There is no way to introduce attributes into JSON in a way
that will be special handled by a plain JSON parser.


> 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.
>
>
Dump Attributes?

Cons:

Protocols are going to find a need for meta-data, like with-defaults.

A complete lack of meta-data might lead to solutions like the "enabled"
leaf in
some YANG modules -- a common property is spread across the data model
in ad-hoc fashion.  Simply adding the meta-data into the reply (but not in
the schema)
will mess up a parser not expecting the extra leafs.

Pros:

We should try to keep the work scope bounded by real requirements.
RESTCONF has no operations that use attributes.  It is only supported in
case vendors add their own meta-data somehow.  HTTP meta-data is returned
in header lines, not within the message body.

I would be OK with forbidding attributes in RESTCONF.
Not so keen about using XML for 1 set of RESTCONF features and JSON
for a different set of RESTCONF features.



Lada
>
> >
> >
> > /martin
>
>
Andy