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

[Ladislav Lhotka <[e-mail]>]

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

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"
  }

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

Lada

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