Subject: Re: A standard for XML - JSON mapping.

From: Carsten Bormann <[email-masked]>
Date: Mon, 01 Feb 2016 11:04:50 +0100

> <https://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.1.0/com.ibm.dp.doc/json_jsonx.html>?

This is for the transport of JSON data in XML documents, not for
converting XML data into a JSON representation.

JSON -> JSONx:

{ "Ticker" : "IBM" }
->
<json:object>
  <json:string name="Ticker">IBM</json:string>
</json:object>

(In any case, I'm wondering if you are citing this because you think we
should be using it or just as a vivid demonstration of how futile these
efforts are...)

Grüße, Carsten

---

From: Julian Reschke <[email-masked]>
Date: Mon, 1 Feb 2016 12:03:54 +0100

> converting XML data into a JSON representation.

Ack. Good point.

> should be using it or just as a vivid demonstration of how futile these

I'm not sure about the futile part; AFAIU, there are valid use cases for 
the above.

But XML->JSON of course is much more complex; if a generic 
transformation is needed the result will be extremely ugly.

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 01 Feb 2016 12:14:08 +0100

> I'm not sure about the futile part; AFAIU, there are valid use cases for

Sure, IBM's format seems to work for IBM's use case.  I just think that
trying to define a generic, application-independent mapping between JSON
and XML is not so useful.

> transformation is needed the result will be extremely ugly.

Obviously. The XML data model (e.g., ESIS) is much more complex than
JSON's, and whatever generic mapping from ESIS to the JSON data model is
defined, it won't "look like JSON" in the end.

Grüße, Carsten

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Mon, 1 Feb 2016 15:41:53 -0500

> defined, it won't "look like JSON" in the end.

The real question is how much of the XML encoding you want to keep.

XML is really a document format and so as a guide, all the information
that appears on the page should appear as element content and
everything that does not should appear as attributes:

<h1 id="heading">This is the way you should do XML</h1>

and not:

<section  anchor="heading" title="This is not how to do XML, sorry" />

Which is why XML is not a good choice for a data markup language as
there are multiple ways to encode the same data structure to put the
bits on the wire and these differences only ever get in the way. ASN.1
has the same problem but to a much lesser degree. There are even more
stylistic choices in XML schema.

So as a general rule, I would not look to convert XML data to JSON,
instead I would look at what data structures the XML data is typically
mapped to in the applications.

In SAML/1.0, all the data structures were defined in a data
description language and that was used to emit the XML schema in a
regular fashion. So there is a fairly straightforward mapping but not
one that is evident from the schema.

If you wanted to have a Web Service that presented JSON and XML front
ends, then a data description language is the way to go.

If you do VisualStudio, my tool is now open source and available as a
VSIX extension. Otherwise you can pull the code and run it on any
platform that has .NET:

https://github.com/hallambaker/PHB-Build-Tools

The code can also generate ASN.1 if you really want.

---

From: tom p. <[email-masked]>
Date: Tue, 2 Feb 2016 16:38:54 +0000

----- Original Message -----
From: "Julian Reschke" <[email-masked]>
To: "Carsten Bormann" <[email-masked]>
Cc: <[email-masked]>
Sent: Monday, February 01, 2016 11:03 AM
> On 2016-02-01 11:04, Carsten Bormann wrote:
<https://www-01.ibm.com/support/knowledgecenter/SS9H2Y_7.1.0/com.ibm.dp.
doc/json_jsonx.html>?
> transformation is needed the result will be extremely ugly.

I wonder if you are familiar with restconf, which is NETCONF over HTTP
with the YANG data in either XML (which is what NETCONF uses for its RPC
and data therein) or in JSON.  There have been a number of discussions
on how to do in JSON what has previously been done in XML and while
sometimes JSON makes it easier, other times JSON lacks the functionality
that has been used previously; I have followed (but not understood) the
discussions on JSON.  The I-D is currently in WG Last Call so before too
long, it will hit this list, whereupon its ugliness, or prettiness, will
be there for all to see.

Tom Petch

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 02 Feb 2016 17:55:53 +0100

> and data therein) or in JSON.  

Certainly (RESTCONF is the basis of COMI in the CoRE WG).

The YANG-JSON mapping is solving a different problem than the one that
was discussed here: It is representing data that conforms to a YANG
Model in JSON (where that data previously has been represented in XML).
 So it does not have to cope with all the strangeness of XML, but only
with those parts of XML used by YANG.

Some complexities in YANG-JSON come from the fact that YANG has been
designed in a way that is a bit too XML-friendly, and that YANG-JSON
tries to be I-JSON (RFC 7493), so it can only use a subset of JSON.

(The core of COMI is a YANG-CBOR mapping, which will inherit some of the
former, but we hope none of the latter class of problems.)

Grüße, Carsten