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 Replies to “DBJSON: SELECT * FROM persons AS JSON”

  1. I Like the idea very much. I think the bigger problem in the short term is that web browsers aren’t secure so you couldn’t use DBJSON to expose your database directly or else anyone could run any query they wanted to by hacking the JavaScript. It could work out of the box with Aptana’s Jaxer, with Rhino, or maybe even with Adobe AIR where the JavaScript runtime is more in the developers control. I’ll be interested to see how this goes.

  2. Thanks Ian,

    Text currently (05Nov08) on the blog contains a good idea but is shamefully chaotic, I know.

    The comment you made on the security is of course valid. Answering it properly opens a “can of worms” which is called : Server Side JavaScript ;o)

    I certainly would not allow my team to send SQL select statements from a browser page back to the RDBMS.
    But server side components written with JavaScript are an entirely different matter. Also.
    I can easily envisage an architecture where client-to-server selections are totally removed. And client-to-client_data selections are totally ok. Like TAFFY does.

    Interesting near future development are client side DB-s, full blown but lightweight , like SQL CE 3.5 SP1, etc … This is where client app talks to the local DB which is transparently synchronized with separate infrastructure with a DB back end, over the wire. I can immediately (today) write AJAX app which will run inside HTA pages and talk to the local SQLSVR CE3.5. Only DBJSON mediator is missing ;o)

    PS: DBJSON can have a secondary but still usefull role here: as an security broker/mediator.

    Regards: Dusan

    1. Zoom to March 2016: Who would think that NODE.JS would look so uncertain and distant, way back in 2008?

      But ok, I was not very far of the mark with “Server Side JavaScript” :)

  3. Very true. In fact I think Server Side JavaScript with tools like this has a really bright future and makes a lot of sense. Looking forward to seeing how this goes.

  4. @shadowbq : Thanks for your somewhat terse comment ;o)

    JavaScript in “CouchDB” is partial implementation of the “MapReduce” concept and framework.
    ( http://en.wikipedia.org/wiki/MapReduce )
    And on “MapReduce”, I am affraid I largely agree with David DeWitt and Michael Stonebraker, pioneering experts in parallel databases and shared nothing architectures. In short: thumbs down.

    I am talking here about ubiquitous add on to current SQL syntaxes inside RDBMS-es, which would be a key to people adopting and understanding JSON.

Comments are closed.