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

[Andy Bierman <[e-mail]>]

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

> Andy Bierman <[e-mail]> writes:
> >
> > Try the example I did where entry1 is owned by owner admin1 and entry2
> > is owned by admin2.  I don't think this works.
>
> { "top": {
>   "A": [
>     { "@tagged-value": {
>         "@owner": "admin1",
>         "@value": {
>           "id": "entry-1",
>           "aa": [42, 19]
>         }
>       }
>     },
>     { "@tagged-value": {
>         "@owner": "admin2",
>         "@value": {
>           "id": "entry-2",
>           "aa": [99, 11]
>         }
>       }
>     }
>   ],
>   "host-name": "router"
> }
>
> >
> > This approach is way too complicated. The encoding scheme in the RESTCONF
> > draft
> > is easier to implement and it works for list and leaf-list siblings.
> >
>
> I think it is more difficult to parse. If you have a container "foo" in
> the data model, you cannot tell whether
>
> "foo": { ... }
>
> is the "native" container or the encoding of attributes, without first
> inspecting the contents of the object, i.e. looking whether any keys of its
> members start with "@".
>
> In my encoding, the two alternatives can be distinguished immediately:
>
> "foo": { ... }    (native container)
>
> versus
>
> "foo": {
>   @tagged-value { ... }
> }
>
>

To a plain JSON parser it doesn't matter (just valid JSON).
To a special parser that is looking for attributes, whatever ad-hoc
formula is used will be coded, so it doesn't matter.



> Note also that in your example
>
>    "host-name" : {
>        "@protect" : "protect",
>        "host-name" : "router"
>    }
>
> the value of the "@protect" attribute is irrelevant, and this is where my
> "property" encoding is IMO more elegant:
>
>   "host-name" : {
>     "@protect" : "router"
>   }
>
>
So if there are multiple boolean properties, the value is repeated?

  "host-name" : {
    "@protect" : "router",
    "@enabled": "router"
  }

This seems really hard to parse.

A variant that combines RESTCONF with yours:

  "host-name" : {
    "@protect" : true,
    "@enabled": true,
    "@owner": "admin1",
    "_@value":"router"
  }

A real YANG identifier could never start with "_@"
so it can be used to prevent "value" from being a reserved name.


 My impression from previous discussions was that the proposed uses of XML
> attributes ("protect", "disable" etc.) are often of this type.
>
>

There are plenty of examples like owner, etag, last-changed-time, and
with-defaults
that are not simple boolean properties.

We know the attributes can be encoded in a way that a plain JSON parser
will accept it.
The real issue is whether the client or server code that needs to interpret
the protocol
message is going to be too complicated to be workable.

HTTP header lines are for message-level meta-data.
We have data-level meta-data associated with datastore nodes.
I doubt it can be ignored. There are no issues with
adding attributes to containers or lists.  Only leaf and leaf-list
encoding needs to be impacted.




Lada
>
>
Andy