JSON to XML conversion

By Confusion on Saturday 21 June 2008 12:48 - Comments (4)
Categories: Software engineering, XML, Views: 14.855

If a form POST needs to pass a lot of structured data, it might be advisable to prescribe an XML format in which the data should be passed. This enables validation of the data with an XSD and the readability makes debugging easier. However, building an XML document in javascript is neither elegant nor easy. It is much easier to just build the object structure and convert it to a JSON string, for instance using this helper library (2.3 KB when 'compressed' with a decent utility; smaller if you don't need the 'parse' method and strip it).

Allowing JSON to be posted required the receiver to convert the JSON to XML before validating it, which poses three problems
  1. JSON doesn't have any namespaces
  2. JSON doesn't distinguish between elements and attributes, like XML does
  3. JSON doesn't really care about ordering
If the elements in the XML are all from the same namespace, the first problem can be remedied by adding the relevant default namespace declaration to the root element. If multiple namespaces are required, there are two solutions:
  1. Namespace the JSON elements in some way ( { ns1_element1: "bar" } )
  2. Magically determine which element is from which namespace
Obviously, both solutions have their problems. In the first case, you need a (synchronised) mapping of namespace identifiers to the actual namespaces that would need to be declared and, depending on usage, that mapping may be necessary in the javascript as well. In the second case, different namespaces cannot declare the same elements, which is quite limiting.

The second problem can be solved in much the same way: by prefixing the attributes-to-be, for instance with xml_attr_<elementname>. Another solution is keeping a (synchronised) list of the attributes appearing in the XSD, checking for their presence and converting them if required. Again, boh solutions have problems, similar to the solutions to the first problem.

The third problem can again be solved in two ways: either by requiring the JSON to be constructed in the correct order and keeping that order intact when converting the JSON to XML (for instance by using these classes, modified by changing the HashMap in JSONObject to a LinkedHashMap) or you could write code to magically impose the order required by the XSD on the resulting XML. The last solution poses a pretty daunting task, while the first solution is easier, provided the users receive clear feedback about ordering problems when testing the JSON they constructed.

After this analysis, our conclusion was that for our case, allowing the webdevelopers to post JSON is an acceptable solution, as we
  • All our elements are in one namespace,
  • The webdevelopers see no problem in making sure the JSON is ordered correctly
  • An attribute prefix does not really limit the possibilities, as long as it is documented, the webdevelopers are kept aware of it and clear feedback points out where they forgot to mark an attribute
The only question that remains on my part is: is it really much easier/cleaner to construct JSON that to construct XML in javascript?

Volgende: Unit testing emails 06-'08 Unit testing emails
Volgende: The Eclipse update annoyance 06-'08 The Eclipse update annoyance

Comments


By Tweakers user _Erikje_, Saturday 21 June 2008 16:34

Waarom zou je het JSON bericht omgaan zetten naar XML?
Is het niet makkelijker om de code die het XML berichtje verwerkt aan te passen dat deze zowel XML als JSON kan verwerken...

Ik zie XML en JSON gewoon als datadragers niet als speciale dingen. Dus het moet niet uitmaken hoe je de data binnen krijgt om het te kunnen verwerken

By Tweakers user Confusion, Saturday 21 June 2008 18:10

Als je de data in JSON formaat houdt, kan je
a) deze niet valideren zonder zelf een XSD variant voor JSON te bouwen en
b) deze niet omzetten zonder zelf een XSLT variant voor JSON te bouwen.
Dan is JSON->XML omzetting, met bovengenoemde nadelen, makkelijker :).

Qua business case: de data wordt bij deze klant in een uniform XML formaat opgeslagen in de database, maar hun klanten krijgen de data in het door hen gewenste formaat aangeleverd: xml, csv, vaste veldlengte, voorletters met of zonder punten als scheidingsteken, data in ISO 8601, timestamp of andere gewenst formaat, etc., etc. Die omzetting wordt middels XSLT's geregeld, terwijl de validiteit van data middels een XSD kan worden vastgesteld. Voor JSON bestaat, voorzover ik heb kunnen vinden, niets equivalents, laat staan dat er ondersteunende frameworks zijn waarmee dat eenvoudig te implementeren is.

By Jig, Tuesday 26 August 2008 19:55

Constructing JSON may be useful if the receiver does not have to convert the JSON to XML. If that were the case, the problems associated with translating appropriately JSON objects to the appropriate XML that you listed would no longer pose a problem. There would be no need for specifying namespaces or requiring the same namespace to be used with in the JSON message and no need for assuring the correct order in which the JSON properties are listed.

Now why would you not want to translate JSON to XML? XML is quite a powerful format for describing messages. It is interoperable as it is language-neutral and has been used widely and successfully in all languages for messaging.

Most modern programming languages are now object-oriented. Therefore, the JSON message format, in my opinion, would more closely match these object-centric languages than XML, because it is after all an "object notation". There is no need specify the order of properties of an object since they are simply properties as opposed to XML, the order of XML elements are important. JSON is also language-neutral.

Another reason why you would not want to convert JSON to XML is it also affects the performance. Why would you want to convert JSON to XML and then to actual programming objects, when the JSON already describes an object. The JSON objects should translate directly to the actual programming objects that live in the specific language. It simply further complicates the messaging flow.

Therefore, JSON should be the future of message formats in our increasingly object-oriented style of programming.

By geronimo, Thursday 8 April 2010 23:16

This posting is indeed absurd.

There is no problem whatsoever converting from a JSON data structure into XML. The worst thing to expect is, that are many thinkable XML structures. The problems mentioned above occur if you translate an *arbitrary* XML document into JSON...

Making a decision between JSON and XML is probably as pointless as to state there is only one programming language. Depending on the context, XML makes sense.

Comments are closed