A slight detour: Why XML?

XML was invented as an “markup language”. Noting less and nothing more. XML might be OK, as an inter system “lingua franca” (universal language), in today’s SOA world, of high fashion. But… Big problem is that XML needs an especially tuned  transport solution for a faster inter-system message transport. And no one yet has same up with an satisfactory solution for that. Compression wont do here, simply because software and time, is needed to compress/decompress every call/reply to/from xml. In all current SOA solutions, min 50% of the code and software layers is devoted to XML compression/decompression and coding/decoding. And do not forget to multiply that, with a number of different languages and runtime environments connected to the XML message bus.

And also: Why XSLT?

XML+XSLT is rendered as an over-engineered solution. Complex to use. and debugging is very difficult.  XML+XSLT=HTML looked until recently as a “winning formula” … but in real life, this combination is difficult to use. This kind of development renders HTML designers job, almost impossible. Contrary to that, JSON+AJAX=HTML is not so mature (old?) but is much more natural fit, for HTML UI driven app’s. Outcome: this development is much less costly than XML+XSLT based one.

Therefore the big issue is: XML requires transformation to/from platform/applications native language. Big solution: JSON is programming language (JavaScript), thus transformation step is not necessary. Provided application is developed in JavaScript. Where this is exactly how each and every web application front end is developed.

XML can be transformed with JavaScript to HTML, without XSLT, but nowhere near so naturally and quickly as JSON. That is because JSON is JavaScript. With JSON there is no paradigm transformation. XML is different paradigm.

There is also a concept of XML serialization. Where run-time environment  “contains” mechanisms for transforming XML to.from platforms  native representation of objects.  Some say that XML “serialization” delivers  “natural solution” to the code/decode obstacle. Example is .NET with ‘attributes’ developed for that. But developers know it turns out to be anything but natural.

Formalisation of XML to JSON mapping

I am not in the business of reinventing “hot water” here. Good people have spent mountains of man-hours to define and deliver XML goodies like: XSD, XSL, etc. I of course, have nothing against any of these. I just advocate DBJSON and JSON as better notation than XML. And for different purpose than document annotation. Also, much easier to use when JavaScript is on both sides of the communication lines. For formal discussion and rules on this subject I can refer you to this two url’s :


So, over there we have the conceptual formalization, to allow us to map “everything” from the XML to JSON.

Next page please.

6 thoughts on “DBJSON: SELECT * FROM persons AS JSON”

Comments are closed.