Subject: Re: [netmod] Y34: use cases for anydata

From: Phil Shafer <[email-masked]>
Date: Mon, 2 Feb 2015 13:41:04 -0500

Ladislav Lhotka writes:
>It's not about saving a few bytes on the wire but rather about keeping the interface betw
>een JSON encoding/decoding and an application simple and straightforward.

It should be about putting the data into a format where the client
can use it.  If 42 is a string, code like:

    if (code > 40) { .... }

will fail.

>I guess this simplicity is the main reason why programmers prefer JSON to XML - no DOMs 
>or things like that are needed in the middle. 

My take is that people like JSON because it translates trivially
into local data structures.  You can think of the lack of quotes
around select values and the presense of "[ ... ]" as a cheap means
of shipping meta-data in with JSON's data, just enough to allow the
receiver to decode it.  Using JSON from typeless languages like
javascript or python yields simpler coding.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Mon, 2 Feb 2015 11:56:48 -0800

> can use it.  If 42 is a string, code like:

The client needs to be careful when using anyxml.
By definition it contains no YANG type information, and
the server is not required to know numbers from strings
within the anyxml subtree.

The client cannot rely on a JSON encoded message
following some out-of-band schema.  It should not
assume anything about anyxml-encoded data from a server.

Andy

---

From: Ladislav Lhotka <[email-masked]>
Date: Tue, 03 Feb 2015 17:29:47 +0100

> can use it.  If 42 is a string, code like:

Agreed.

> javascript or python yields simpler coding.

And in strongly typed languages, using a standard JSON parser usually
means that the receiver has to know the type of each value in order to
be able to extract it from the parsed structure.

Lada

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

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Feb 2015 08:52:39 -0800

> be able to extract it from the parsed structure.

It would be unwise to design code this way with "anyxml" data.
IMO, inline data structures are horrible for APIs. The "schema" is
made up by the sender on the fly.

I often see JSON from customers that uses an object instead of
a 1-element array, or quoted numbers.  IMO the receiver
has to deal with this sloppy encoding, especially for anyxml.

Andy

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Feb 2015 12:25:04 -0500

>made up by the sender on the fly.

I won't debate the wisdom of using anyxml, but would argue that
having features like this in our language makes it much more flexible.

Consider the issue last IETF of wanting a server to proxy for unknown
chunks of YANG from slave boxes.  Having anyxml gives us an easy
solution.  Without it, we'd be forced to make special cases (like
proxy) into core feature of YANG.

>has to deal with this sloppy encoding, especially for anyxml.

Yes, the down side of an encoding that lets people do anything is
that people will do everything.

Thanks,
 Phil

---

From: Andy Bierman <[email-masked]>
Date: Tue, 3 Feb 2015 09:49:12 -0800

> proxy) into core feature of YANG.

We have an XML attribute solution for this called 'datapath'.
There is also a YANG extension to cause the sender to generate
the attribute:

http://www.netconfcentral.org/modules/yumaworks-extensions/2014-08-10#datapath.138

JSON attributes are horrible to parse, but we decided all
the unordered data and buffering are just implementation details.
So much easier to implement with XML.

It's a fairly obvious solution -- send the schema-identifier as meta-data
if you want the receiver to use a dynamically assigned schema-node
instead of anyxml.

> that people will do everything.

:-)

Andy

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Feb 2015 20:29:55 +0100 (CET)

> proxy) into core feature of YANG.

This use case shows why the proposed 'anydata' is useful.  anyxml to a
lesser extent, and only for the XML encoding.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Feb 2015 14:38:00 -0500

>lesser extent, and only for the XML encoding.

anyxml is XML content and can be validated/etc.  anydata seems like
"string" to me, but I may be missing something.

Thanks,
 Phil

---

From: Martin Bjorklund <[email-masked]>
Date: Tue, 03 Feb 2015 20:44:25 +0100 (CET)

> "string" to me, but I may be missing something.

In XML, anydata is encoded just like anyxml, i.e. "inline" (not a
string).  In JSON, anydata is also encoded "inline" as json
structures.

The difference is that anyxml is really any XML - mixed content, PI
etc.  anydata is restricted b/c it is the representation of something
that is (or maybe "could be") modelled in YANG.

/martin

---

From: Phil Shafer <[email-masked]>
Date: Tue, 3 Feb 2015 14:58:13 -0500

>that is (or maybe "could be") modelled in YANG.

Wouldn't such an encoding require an understanding of the schema?

    <a>1</a>

and:

    a: 1

might be equivalent, if a is a leaf, and

    <a>1</a><a>2</a><a>3</a>

and

    a: [ 1, 2, 3 ]

are equivalent if you know it's a leaf-list.  Without that
knowledge, converting the first example would be problematic,
since "a: [ 1 ]" would be the encoding if it were a leaf-list.
Converting data not covered by schema would be difficult.

Thanks,
 Phil

---

From: Ladislav Lhotka <[email-masked]>
Date: Wed, 04 Feb 2015 14:20:43 +0100

> made up by the sender on the fly.

I think we are still mixing anyxml with other YANG nodes in this discussion.

> has to deal with this sloppy encoding, especially for anyxml.

Again, two cases:

- anydata/anyxml: it's outside the scope for YANG but there may be other
  schema/protocol/rules, and these have to decide what will be
  accepted and what not.

- other YANG nodes: for XML encoding the rules in 6020 are relatively
  strict, and nothing forces the receiver to deal with sloppy encoding. I
  don't see any reason why JSON encoding should be different.

Lada