OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
XML-to-JSON is in a state of disarray

Hi Folks,

[Definition] Disarray: a state of disorganization or untidiness.

I have discovered that there are lots of approaches to designing JSON from XML. Here are a few:

1. JSON-LD says "Hey, format your JSON my way. Doing so will make your JSON consistent with the RDF data model. Then you can use all the RDF tools."

2. Eclipse's MOXy handles XML to Java object mapping. It will serialize & deserialize to/from XML or JSON. 

3. Apache's Camel also supports XML to JSON conversion using prefixes and namespace mappings.

There are other approaches, such as IBM's JSONx. And many others.

Sigh. Such a state of disarray. Lots of people creating JSON designs to support their narrow niche. (JSON-LD and JSONx have arguably a broader niche than MOXy or Camel.)

Let's examine the consequences of this disarray:

If I want to process JSON using Java, then perhaps I should design JSON in the style of MOXy or Camel. 

But there are serious disadvantages to designing JSON in the style of MOXy or Camel:

- I can't play in the RDF world and can't leverage all the tools that it offers.

- Other programming languages (Python, Ruby, etc.) likely have a different approach. Beside, who says that I will always process JSON using Java?

- If I choose to design JSON in the style of Eclipse's MOXy then my JSON can't be processed by Apache's Camel and vice versa.

- MOXy and Camel are not W3C-compliant. In fact, they are not compliant with anybody but themselves.

If I want to be W3C-compliant and leverage RDF, then perhaps I should design JSON in the style of JSON-LD.

But there are serious disadvantages to designing JSON in the style of JSON-LD:

- The JSON can't be processed by Eclipse's MOXy or Apache's Camel.

- I don't necessarily need the RDF stuff.

All approaches look dismal.

What should I do?

Hey, here's a thought: design JSON in a "neutral" manner and then, when needed, transform the neutral-form-JSON into one of the other forms (MOXy, Camel, JSON-LD, etc.). But, but, but, ... What's a "neutral" form? Why invent another JSON design approach? Besides, unlike XML, which has XSLT, there is no JSON transformation language.

Help! I'm trapped in a XML-to-JSON design dilemma. What design approach do you recommend for generating JSON from XML? 


JSON-LD: http://www.w3.org/TR/json-ld/

Eclipse MOXy: http://www.eclipse.org/eclipselink/documentation/2.4/moxy/json003.htm

Apache Camel: http://camel.apache.org/xmljson.html 

IBM's JSONx: http://tools.ietf.org/html/draft-rsalz-jsonx-00 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 1993-2007 XML.org. This site is hosted by OASIS