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

From: Dean Bogdanovic <[email-masked]>
Date: Thu, 20 Mar 2014 12:46:30 +0000

Hi, 

In draft yang leaf node is defined as name value pair in json

If it would be represented, as an object then we can assign attributes to it.

Example
"host-name" {
   "data" : "router",
	"attributes" : { "protect" : protect}
}

We need attributes for several things, so lets try to figure out how to enable them.

Dean

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Mar 2014 15:04:26 +0100 (CET)

> We need attributes for several things, so lets try to figure out how to enable

I agree that the lack of attributes is a problem with the JSON
mapping.

The problem with your solution is that it adds noise to the normal
case where there are no attributes.  We're using another encoding:

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

Yep, not very elegant...

/martin

---

From: Andy Bierman <[email-masked]>
Date: Thu, 20 Mar 2014 08:25:59 -0700

On Thu, Mar 20, 2014 at 7:04 AM, Martin Bjorklund <[email-masked]> wrote:

> > We need attributes for several things, so lets try to figure out how to
> enable
> > them.
>
This is how RESTCONF encodes these attributes in a leaf:
(see sec. 3.4.1)

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

Lada says that this is a YANG to JSON mapping and YANG has no attributes,
so the attribute encoding is in RESTCONF.  I think it would be better
if there was 1 mapping, instead of a different mapping in each protocol
that uses this JSON encoding of YANG data.

I do not think YANG needs to model attributes!
The protocol may need to use them to tag data with meta-data.
We do not need to model some leafs as attributes and others
as child nodes in YANG data models.  Use RelaxNG instead
of YANG to do that.

> /martin
Andy

> _______________________________________________
> netmod mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/netmod
>

---

From: Martin Bjorklund <[email-masked]>
Date: Thu, 20 Mar 2014 16:36:36 +0100 (CET)

> This is how RESTCONF encodes these attributes in a leaf:

So this means that RESTCONF does not follow the JSON mapping
document.

If we can avoid that it would be ... good.

> that uses this JSON encoding of YANG data.

+1  I think the JSON mapping document should define how meta data are
encoded, if the protocol supports meta data.

> I do not think YANG needs to model attributes!

+1

> The protocol may need to use them to tag data with meta-data.

Yes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Thu, 20 Mar 2014 23:31:56 +0100

> I agree that the lack of attributes is a problem with the JSON

YANG doesn’t model XML attributes, so attributes are out of scope for the mapping. I’d be happy to provide decent place for attributes, but I don’t like Dean’s proposal - it just makes JSON text terribly messy.

> Yep, not very elegant…

But still much much better. As you say, it spoils only places where attributes are really needed. I am inclined to include this kind of attribute mapping in the draft, if we can reach a rough consensus on it.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Mar 2014 08:37:45 -0700

>> case where there are no attributes.  We're using another encoding:

More importantly, it doesn't work for lists or leaf-lists.
The attributes cannot be siblings (or ancestors) of the target data node.

Consider the following YANG data-stmt, and how an attribute
would be encoded in every data node (as a worse-case example).

container top {
  list A {
    key id;
    leaf id { type string; }
    leaf-list aa { type int8; }
  }
  leaf host-name { type string; }
}

Plain JSON

{ "top" : {
  "A" : [
    { "id":"entry-1",
      "aa": [42, 19]
    },
    { "id":"entry-2",
      "aa" : [99, 11]
    } ]
  },
  "host-name":"router"
}

Add attribute to each node:
   leaf owner { type string; }

With Owner Attribute using RESTCONF encoding:

{ "top" : {
  "@owner":"system",
  "A" : [
    { "@owner":"admin1",
      "id" : {
        "@owner":"admin1",
        "id": "entry-1"
      },
      "aa" : [ { "@owner":"admin1",  "aa": 42 },
                 { "@owner":"admin1",  "aa": 19 } ]
    },
    { "@owner":"admin2",
      "id" : {
        "@owner":"admin2",
        "id": "entry-2"
      },
      "aa" : [ { "@owner":"admin2",  "aa": 99 },
                 { "@owner":"admin2",  "aa": 11 } ]
    } ]
  },
  "host-name" : { "@owner":"system",
                         "host-name":"router" }
}

This is not elegant either, but it works for all YANG node types.
How would your encoding look for this example?

Andy

---

From: Andy Bierman <[email-masked]>
Date: Fri, 21 Mar 2014 09:43:02 -0700

On Fri, Mar 21, 2014 at 8:37 AM, Andy Bierman <[email-masked]> wrote:

>>> > We need attributes for several things, so lets try to figure out how
>>> to enable
>>> > them.
>>>

oops -- host-name should be up 1 level, sibling of A
Same mistake below...

Andy

}

---

From: Ladislav Lhotka <[email-masked]>
Date: Sat, 22 Mar 2014 09:08:35 +0100

> The attributes cannot be siblings (or ancestors) of the target data node.

An option for boolean-type properties is to wrap the affected object or value, e.g.

"@protect": {
    "host-name": ...
}

or

"foo" : [ 1, 2, {"@protect": 3}, 4]

Instead of defining a general JSON equivalent of XML attributes, it might actually be easier to come up with an ad hoc representation for every use case. This is the approach of some native JSON applications such as MongoDB.

So, the specification of each global property (e.g. "protected") would also define an appropriate encoding in both XML and JSON.

> How would your encoding look for this example?

"@owned-object": {
    "@owner": "system",
    "host-name": "router"
}

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Mar 2014 03:47:28 -0700

On Sat, Mar 22, 2014 at 1:08 AM, Ladislav Lhotka <[email-masked]> wrote:

> >>> > If it would be represented, as an object then we can assign
> attributes
> >>> to it.
> >>> >
> >>> > Example
> >>> > "host-name" {
> >>> >    "data" : "router",
> to
> Instead of defining a general JSON equivalent of XML attributes, it might
> actually be easier to come up with an ad hoc representation for every use
> case. This is the approach of some native JSON applications such as MongoDB.
>
> So, the specification of each global property (e.g. "protected") would
> also define an appropriate encoding in both XML and JSON.
>
> >
Can you show how 2 list entries and 2 leaf-list entries
have different attribute values.  Of course we need to
support string values, not just boolean.

Andy

---

From: Andy Bierman <[email-masked]>
Date: Sat, 22 Mar 2014 09:41:15 -0700

> case. This is the approach of some native JSON applications such as MongoDB.

The attribute mapping needs to correspond to the XML attribute mapping.
Attributes have string values, so the mapping above will not work.

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

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.
A robust deterministic mapping is required, ad-hoc or not. Perhaps an
identity registration
scheme is good enough, since it provides a module-name for the attribute
name.
(i.e., the tool needs to know all the identities derived-from the
'metadata' base identity)

  module foo-mod {
    ...
    import nexconf-ex { prefix nx; }

    identity owner {
       base nx:metadata;
    }
  }

Andy

So, the specification of each global property (e.g. "protected") would also
> define an appropriate encoding in both XML and JSON.
>
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 23 Mar 2014 10:42:44 +0100

...

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

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

> I think a standard mechanism is needed to properly map attributes to JSON

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.

>     import nexconf-ex { prefix nx; }

I would prefer either to define global attributes outside YANG, or to introduce a new top-level statement for them in YANG 1.1, e.g. "global-attribute".

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Sun, 23 Mar 2014 11:07:41 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> 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
>   }
> }
> 

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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Mar 2014 03:26:29 -0700

> types, too, not only string.
I meant they are encoded in XML as quoted strings

> 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
>   }
> }
>
I don't think this works for lists and leaf-lists.
Can you expand the encoding to show a real example with
container, list, leaf, and leaf-list used?

Not only doesn't it work for siblings, but it depends on the order (@owner
followed by @value),
and JSON objects are not ordered.

> Such property objects may nest, e.g.

why are properties needed?
why do we need attributes within attributes?

Both constructs work for list and leaf-list entries, and may be also
> combined.
> I would prefer either to define global attributes outside YANG, or to
> introduce a new top-level statement for them in YANG 1.1, e.g.
> "global-attribute".

Lada
Andy

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Mar 2014 03:53:05 -0700

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

> > I don't understand. XML schemas can define attribute values to be of
> other
> > types, too, not only string.
> >
> > >
> > 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
> > }
> >
I agree this is getting too complicated.

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

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 23 Mar 2014 16:07:49 +0100

Andy Bierman <[email-masked]> writes:

>> "@tagged-value" object.

container
=========

"foo": { "bar": 42 }

becomes

"foo": {
  "@tagged-value": {
    "@tag1": 54,
    "@value": { "bar": 42 },
    "@tag2": "hi!"
  }
}

leaf
====

"bar": 42

becomes

"bar": {
  "@tagged-value": {
    "@tag3" = false,
    "@value": 42
  }
}
    
leaf-list
=========

"foos": [ 6, 3, 7, 8]

when tagging the whole array becomes 

"foos": {
  "@tagged-value": {
    "@value": [ 6, 3, 7, 8 ]
    "tag4": true

or, when tagging only one entry, becomes

"foos":
  [ 6,
    { @tagged-value: { "@tag5": 1, "@value": 3 } },
    7,
    8
  ]

list
====

is analogical, only scalar values (numbers in the above example) will be replaced with objects. 

> and JSON objects are not ordered.

No, it doesn't, as you can see in the examples the "@value" member can appear at any place and the order of tags is also irrelevant.

The only restriction is that no tag can have the key "@value".
 
>> object, e.g.

They are not strictly needed, only their encoding is much nicer, and I assume quite often XML attributes are supposed to be used for such binary properties, such as "protect", "deactivate" etc.

So the examples above could also be written

"@tagged-value": {
  "@value": 42,
  "@foo": true
}

and

"@tagged-value": {
  "@value": 42,
  "@foo": true,
  "@bar": true
}

> why do we need attributes within attributes?

To be able to express that a single value has multiple properties.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Mar 2014 08:24:49 -0700

On Sun, Mar 23, 2014 at 8:07 AM, Ladislav Lhotka <[email-masked]> wrote:

> >> This is another extension that violates the rule stated in RFC 6020,
> sec.
> >> 6.3.1:
> >>

Try the example I did where entry1 is owned by owner admin1 and entry2
is owned by admin2.  I don't think this works.

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.

Andy

> No, it doesn't, as you can see in the examples the "@value" member can
> appear at any place and the order of tags is also irrelevant.
>
> They are not strictly needed, only their encoding is much nicer, and I
> assume quite often XML attributes are supposed to be used for such binary
> properties, such as "protect", "deactivate" etc.
>

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 23 Mar 2014 16:26:00 +0100

Martin Bjorklund <[email-masked]> writes:

>> sec. 6.3.1:

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

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

Lada

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Mar 2014 09:06:21 -0700

> >      or res['@tagged-value']['ssh']['@tagged-value']['enabled']

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.

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Sun, 23 Mar 2014 17:14:49 +0100

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

> 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

---

From: Andy Bierman <[email-masked]>
Date: Sun, 23 Mar 2014 09:41:46 -0700

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

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

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.

> "property" encoding is IMO more elegant:
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

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 14:34:40 +0100 (CET)

Hi,

Here's yet another attempt to handle attributes in JSON, without
changing the encoding for the case that there are no attributes
present.

In all examples, the attributes "inactive" and "etag" are present.

Attributes are encoded differently depending on the type of object:

leaf
----

Encode the attributes as a sibling to the leaf.

  leaf foo {
    type string;
  }

  "foo": "some value";
  "@foo": {
     "inactive": true,
     "etag": "...";
   }

list instance
-------------

Encode the attributes within the list instance.

  list bar {
    key name;
    leaf name {
      type string;
    }
    ...
  }

  "bar": [
     {
        "@bar": {
           "inactive": true,
           "etag": "..."
         }
         "name": "instance name";
      }]

container
---------

Encode the attributes within the container.

  container baz;

  "baz": {
     "@baz": {
        "inactive": true,
        "etag": "..."
       }
  }

leaf-list
---------

Encode the attributes as a sibling to the leaf-list, with an array of
same length as the leaf-list itself.

  leaf-list buzz {
     type string;
  }

  "buzz": [ "val1", "val2", "val3" ],
  "@buzz: [ null, 
            { "inactive": true,
              "etag": "..."
            }
            null]

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Mar 2014 14:51:53 +0100

> Encode the attributes as a sibling to the leaf.

This could be ambiguous:

list bar {
  key name;
  leaf name { ... }
  leaf bar { ... }
}

Then you don't know whether the attributes belong to the list entry or to the contained leaf.

Lada

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 14:57:37 +0100 (CET)

> or to the contained leaf.

Right. Then we use "@@bar" for the list / container attributes.

/martin

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Mar 2014 15:10:09 +0100

> Right. Then we use "@@bar" for the list / container attributes.

OK, then this scheme is fine with me.

Lada

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Mar 2014 07:19:59 -0700

> OK, then this scheme is fine with me.
Looks more complicated than other solution proposals.
Looks very cumbersome to implement, especially for leaf-lists.
Maybe it will take an interim meeting to figure out how to agree
on an attribute encoding for JSON.

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 15:27:37 +0100 (CET)

> Looks more complicated than other solution proposals.

Do we agree that we don't want different encodings for values if there
are attributes or not?  I.e., if my code works when no attributes are
present, it should also work if there are attributes?

If so, do we have any other proposal?

I am all for a simpler solution!

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Mar 2014 07:43:53 -0700

> present, it should also work if there are attributes?
Not if the normal encoding is painful to use.
The use attributes is going to be rare.
I want the expected "plain" encoding when there are no attributes.
Code that generates JSON and does not care about attributes
must not be rendered useless because the JSON is specially encoded
in RESTCONF.  We want to leverage wide knowledge of JSON,
not invent our own incompatible version of it.

> I am all for a simpler solution!

Putting attributes at the sibling level does not work for leaf-lists.
Even for leafs, it is difficult to parse.  JSON objects are unordered,
so the "@foo" could appear anywhere, even before "foo".  The schemes
I proposed always keeps the attributes within the node for the attributes
(just like XML).

One idea I had was to simply disallow attributes for leaf and leaf-list.
They can only go in container or list nodes.  This is restrictive but then
there
will not be any dual decoding possibilities.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 26 Mar 2014 16:05:11 +0100

> present, it should also work if there are attributes?

I am not sure even your encoding satisfies this requirement. At least your code has to be instructed to ignore the attribute stuff.

> not invent our own incompatible version of it.

This is my preference, too.

> If so, do we have any other proposal?

Leave it to proponents of every use case to figure out ad hoc how to encode what’s needed, or resort to XML.

Lada

> They can only go in container or list nodes.  This is restrictive but then there

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 16:12:20 +0100 (CET)

Ladislav Lhotka <[email-masked]> wrote:
> I am not sure even your encoding satisfies this requirement. At least
> your code has to be instructed to ignore the attribute stuff.

In general, I think robust code would ignore unknown fields.

> This is my preference, too.

Well, of course.  But I don't think anyone has proposed something that
is not valid json.

> encode what’s needed, or resort to XML.

Which for RESTCONF would mean use XML, IMO.

I still think a common definition would be better.

/martin

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 16:17:44 +0100 (CET)

> Putting attributes at the sibling level does not work for leaf-lists.

See my proposal.

> so the "@foo" could appear anywhere, even before "foo".

Sure.  So what?  Since they are unordered, you have to parse
everything before starting to process anyway. 

> The schemes

The proposals I have seen either changes the encoding depending on
atribute presence, or are very chatty, which would remove the
simplicity of using JSON.

> will not be any dual decoding possibilities.

Yes I think this is a bit too restrictive.  (We tried in RESTCONF to
let leafs just be fields, but now they are their own resources.)

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Mar 2014 08:47:47 -0700

On Wed, Mar 26, 2014 at 8:12 AM, Martin Bjorklund <[email-masked]> wrote:

> > > > > >> Then you don't know whether the attributes belong to the list
> entry
> > > > > >> or to the contained leaf.
> > > > > >
This is not a preference. It is critical that plain JSON code
that knows how to deal with plain data structures does not break.

> is not valid json.

That is not the point.  A normal JSON tool is going to generate or expect
"foo":"bar" for a simple leaf, or "foo":[1, 2, 3]  for a simple array, for
example.

The encoding for the data nodes MUST be exactly
the same as the YANG-to-JSON draft now, if no attributes are used.

Only a client that knows about attributes will need to associate an
attribute
with its parent data node.  This must be easy to do.
Other clients should be able to ignore attributes.
A server must reject messages with unknown attributes.

I agree that no proposal is satisfactory for leaf or leaf-list nodes.

> > Leave it to proponents of every use case to figure out ad hoc how to
> > encode what's needed, or resort to XML.
>

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Wed, 26 Mar 2014 16:51:13 +0100 (CET)

> the same as the YANG-to-JSON draft now, if no attributes are used.

This is exactly my point!

> with its parent data node.

Yes!

> This must be easy to do.

As easy as possible.  IMO this falls into the category of "possible to
do".  The normal case must be easy to do.

> Other clients should be able to ignore attributes.

Yes!

> I agree that no proposal is satisfactory for leaf or leaf-list nodes.

My proposal satifies all these properties, except "easy to do
attributes".

/martin

---

From: Andy Bierman <[email-masked]>
Date: Wed, 26 Mar 2014 09:06:05 -0700

> My proposal satifies all these properties, except "easy to do
Yes -- there are corner cases to detect (like array given for @foo,
but foo is a leaf).  The most annoying part is parsing @foo first,
and holding onto the data until foo is found (if it exists - another error
to detect is @foo but no foo).

I guess this is OK.
NACM does not provide any control over access to attributes,
which is good.  We cannot have NACM filter out a leaf-list value
but not filter out the attributes for the associated leaf-list instance.

Andy