Subject: [Json] Fwd: Blog: YANG Takes Off in the Industry

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Aug 2014 13:35:18 +0200

For large parts of the IETF, the JSON schema discussion we are not having is already settled.

(Or is it?  Should it be?  Scary.)

Grüße, Carsten

Begin forwarded message:

> From: Benoit Claise <[email-masked]>
> Subject: Blog: YANG Takes Off in the Industry
> Date: 1 Aug 2014 13:17:43 +0200
> To: IETF-Discussion list <[email-masked]>
> 
> Dear all,
> 
> [netmod WG list is bcc'ed]
> 
> Enjoy http://www.ietf.org/blog/2014/07/yang-takes-off-in-the-industry/
> 
> Regards, Benoit
> 
>

---

From: John Cowan <[email-masked]>
Date: Fri, 1 Aug 2014 07:54:08 -0400

> having is already settled.

Say what?  YANG is a data modeling language for network configuration
expressed in XML and defined in RFC 6020 -- which does not contain the
word JSON once.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
Possession is said to be nine points of the law,
but that's not saying how many points the law might have.
        --Thomas A. Cowan (law professor and my father)

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 1 Aug 2014 14:01:12 +0200

On 01 Aug 2014, at 13:54, John Cowan <[email-masked]> wrote:

> which does not contain the
> word JSON once.

That vacuum is filled by draft-ietf-netmod-yang-json-00.
(Nature abhors vacuum.)

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Aug 2014 08:11:19 -0400

> expressed in XML and defined in RFC 6020 -- which does not contain the

But you could use it to create a data model that was represented in JSON.

At this point it is rather clear that JSON has won the Web Services
data encoding battle. And it is perhaps not surprising. 80% of the
functionality of XML is there for the people using it to model
documents. And that community refuses to make any changes to XML or
XML schema to support protocol work. So XML is a bad choice for
protocol design.

So I think his point is that if you aren't doing JSON its not relevant anyway.

Using a schema to design a protocol is still a good idea. But only if
you have the right tools.

My tools generate the Internet Draft reference materials and the code
that is run to produce the examples from the same schema. So they are
both always in sync. It now generates C code as well so you can use it
in production.

Whether the schema helps of gets in the way depends on what sort of
programmer you are and what your security concerns are. For my code I
want to map the input stream to an in-language data representation and
validate the syntax and type of all the sub-nodes before I pass the
data on to my dispatch routine.

---

From: John Cowan <[email-masked]>
Date: Fri, 1 Aug 2014 08:35:46 -0400

Carsten Bormann scripsit:

> That vacuum is filled by draft-ietf-netmod-yang-json-00.  (Nature
> abhors vacuum.)

Neither here nor there: that is merely a JSON expression of the XML.  It
has nothing to do with modeling JSON.

> But you could use it to create a data model that was represented in

I haven't read the RFC in any detail, but the model given in 4.2.2 does
not seem to be a JSON model: it is far more complicated.

> And that community refuses to make any changes to XML or XML schema to
> support protocol work.

Or for any other purpose.  Ghu knows I tried.

> So XML is a bad choice for protocol design.

That conclusion I believe to be unwarranted.  The problems with XML are
mostly the hard-to-use APIs, of which one of the worst is that embedded
in all browsers.  If anything is carved in stone these days, it is the
DOM.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
Yakka foob mog.  Grug pubbawup zink wattoom gazork.  Chumble spuzz.
    --Calvin, giving Newton's First Law "in his own words"

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 1 Aug 2014 09:10:45 -0400

> in all browsers.  If anything is carved in stone these days, it is the

True, but JSON is (or certainly should be) just a serialization format
of the DOM. So it is actually a short distance between the two points
than XML.

Which is why a binary version of JSON should be a binary encoding of
the DOM and not some different data model.

---

From: John Cowan <[email-masked]>
Date: Fri, 1 Aug 2014 09:20:28 -0400

> of the DOM. So it is actually a short distance between the two points

I don't say that you can't construct a JSON serialization of the DOM,
but the DOM's native model, with its mixed content, node-centric rather
than path-centric naming, and other features, is far more like XML
than it is like JSON.  What JSON serializes is JavaScript values (or
rather less, given that it excludes infinity and NaN).  That makes it
convenient to represent JSON texts as anonymous JavaScript values
within a JavaScript program.

In any case this is far off-topic.

> the DOM and not some different data model.

A binary version of JSON should surely encode what JSON encodes, neither
more nor less.

-- 
John Cowan          http://www.ccil.org/~cowan        [email-masked]
No man is an island, entire of itself; every man is a piece of the
continent, a part of the main.  If a clod be washed away by the sea,
Europe is the less, as well as if a promontory were, as well as if a
manor of thy friends or of thine own were: any man's death diminishes me,
because I am involved in mankind, and therefore never send to know for
whom the bell tolls; it tolls for thee.  --John Donne

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 1 Aug 2014 17:08:34 +0200

> That vacuum is filled by draft-ietf-netmod-yang-json-00.

Right. In fact, JSON is a better fit than XML for data modelled with YANG, because, for example, YANG doesn’t allow for modelling XML attributes and mixed content.

Lada

> 
> Grüße, Carsten
> 
> _______________________________________________
> json mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/json

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

---

From: Ladislav Lhotka <[email-masked]>
Date: Fri, 1 Aug 2014 17:33:48 +0200

> Neither here nor there: that is merely a JSON expression of the XML.  It

Not really: the XML-JSON translation is schema-driven so that, for instance, XML leaf element text can become a string, numeric or boolean value in JSON depending on the type of that leaf node in the YANG data model. Also, an XML element may be mapped to a JSON name/object or name/array depending on whether it is defined as a container or list in YANG.

So, YANG can and does really act as a domain-specific schema language for both XML and JSON.

Lada