Wednesday, February 11th, 2009

JsonML: Who needs angle brackets?

Category: JSON

JsonML swaps out the world of the curly with that of the angle.

The purpose of JsonML is to provide a compact format for transporting XML-based data via JSON.

Simon Willison says it best:

An almost non-lossy serialization format for sending XML as JSON (plain text in between elements is ignored). Uses the (element-name, attribute-dictionary, list-of-children) tuple format, which sadly means many common cases end up taking more bytes than the original XML. Still an improvement on serializations that behave differently when a list of children has only one item in it.

Have you seen this path before? Hating on XML and going for JSON, but then trying to JSON as XML and at the end of it you just s/</{/g.

Just take a look at the GData JSON API

Posted by Dion Almaer at 6:39 am
21 Comments

++---
2.7 rating from 37 votes

21 Comments »

Comments feed TrackBack URI

never understood why people want to go full circle like this. Just use XML & XSLT if you want, or JSON and Javascript ….

Why would you want to do this?

Comment by DeviantSatan — February 11, 2009

I don’t understand why serializing html or xml data into json is such a problem that we need this concept?
.
Seems like the most straightfoward way is just to use a simple JS string with a JSON envelope. You could just have a {x:”…”} serialization, which is dumb but gets the job done with only about 6 charaters of overhead.
.
Am I missing something? Cause you can of course “parse” that string into a rich XML element for JS processing.
.
Or, just use an XSLT translation on your server side to transform your XML document into a rich nested JSON object before sending, and then just process through a JSON object on the client side.
.
I don’t get it.

Comment by shadedecho — February 11, 2009

So what advantage i am going to achieve if i send an HTML table in JSON format? how will it be better in terms of performance while sending data via AJAX?

Comment by kadnan — February 11, 2009

Wondering the same thing as others here, I actually looked at the link to investigate. The only real reason I saw, which was not put in the summary was that its basically a format to make DOM calls instead of innerHTML. By having the format easily accessible to javascript, it can be processed/filtered/merged etc. before being converted into DOM calls, and then because it uses DOM calls it allows easy access to elements without having to crawl the DOM afterwards.
.
Personally, I think at that point it makes more sense to do some kind of client-side templating, but I can see where the niche is. I’d also be interested to see the benchmarks on a large partial being inserted.

Comment by genericallyloud — February 11, 2009

oops, looks like they already have client-side templates!
http://jsonml.org/BST/

Comment by genericallyloud — February 11, 2009

I agree with genericallyloud.

We need a comparison outlining eg. the benefits of choosing XML/XSLT or JSON/JS DOM manipulation for large chunks of data.

I’ve wondered more than once which is actually the fastest: Doing templates with XML->XSLT or JSON and createElement / addChild etc DOM manipulation javascripting.

I’m working on a large project myself where we use JSON data client side which we transform to XML to be used server side (eg. for MS SQL processing with XPath and also C# code behind processing etc) – and that actually works out really well. We’re not doing HTML data in JSON, just application state data though.

Comment by MichaelSchoeler — February 11, 2009

(x)HTML via XSLT over XML is the fastest template solution I could use, generally speaking, and it is widely compatible in the client side (you do not need to pre-transform in the server, every browser supports XSLT transformation from IE > 5)

The point, in my opinion, is still this one: JSON is perfect as data transport protocol, the rest is a doubtfully useful overload for both protocol and/or bandwidth and/or performances.
Let JSON does data transportation and leave the layout layer out of the “interaction game”: why should we transport a table when all we need is an array?
[[1,2,3],[4,5,6]]
this is what we should move server to client and vice-versa, nothing else (imho)

Comment by WebReflection — February 11, 2009

It’s fundamentally the same as XMLmarkup – text with structures as a way to represent their relationships. It reduces file/data size but the time complexity is the same.

One issue with it is it’s not very human readable, even worse than XML. If you missed a } you’ll have to trace through the whole thing. For XML if you missed you can at least just check opening s and skip all others safely.

Another issue could be the performance. For this to work on current browsers, an interpretation step is needed – essentially eval the JSON and recursively build the DOM. So, every time a page is loaded, the browser has to store a potentially huge array/object AND a DOM tree. Normally the DOM tree will be stored in memory by browsers, but not another representation of the web page. Even though with current CPU and browser performance storing any object won’t be a problem most of the time, but given a typical web page may contain a couple hundred or thousand elements, and multiple tabs in competing in a single process, it’s probably something you want to avoid.

Comment by coolnalu — February 11, 2009

coolnalu, you forgot common events or inline styles, they cannot be transported once for all, they have to be in every single sub-node.
This problem does not exist with XSLT, since the onclick event, for example, is once for that XPath match and that’s it, complexity 1/N the size of a structured JsonML interaction (XML + XSL(T))
I do not know why a lot of people do not use XSL at all, it is portable as XML is, scalable, flexible, powerful, etc etc … but no, we prefer to re-invent the wheel every time, and not always in the best way, don’t we? ;-)

Comment by WebReflection — February 11, 2009

We have been wrestling with Javascript performance in one of our products and after trying all the methods, we ended up using innerHTML as the fastest method to update the AJAX content dynamically. If an AJAX call should produce some content, why can’t just generate HTML itself, so the browsers can process it natively instead of having to do that in Javascript. This is certainly not an elegant design, but any full featured, complex app will sooner or later need to make exceptions for performance.

Comment by ragjunk — February 11, 2009

Why do we always have to turn everything into a Versus? XML + XPath can be awesome to work with; just grab your XML and apply some XPath to get exactly what you need, fast. JSON is great for other use cases, especially when you are dealing with something that is just a big bag of dictionary values or want to do cross-domain stuff with JSONP.

Comment by Brad Neuberg — February 11, 2009

“I’ve wondered more than once which is actually the fastest: Doing templates with XML->XSLT or JSON and createElement / addChild etc DOM manipulation javascripting.”

If you cache your XSL processor rather than reparsing the XSL Document each time, then XSL will be faster. The most expensive part of the XSL transformation is parsing the XSL’s XML DOM and creating the processor object. This means don’t use the processor instruction method of transformation – use javascript to do the transform if performance s the goal.

Comment by RobKoberg — February 11, 2009

You’re all forgetting that JSON can be used cross-domain (with a SCRIPT) tag in Ajax applications, wheres XML is usually limited to the same domain (unless you’re using browser-specific tricks or a proxy server).

Comment by IxVan — February 11, 2009

JsonML is more than simply a JSON encoding for XML. It is also the underlying structure for creating intricate client-side templates: JBST (JsonML+Browser-Side Templates).

XSLT and XML can be used to produce client-side templating as well, but for many the syntax of JBST is much easier to manage. Syntactically JBST looks like JSP or ASP.NET UserControls.

While superficially used to perform similar tasks, JsonML and innerHTML are quite different beasts.

innerHTML requires you to have all the markup exactly as you want it ready to go, meaning that either the server is rendering the markup, or you are performing expensive string concatenations in JavaScript.

JsonML opens the door to client-side templating through JBST which means that your template is converted from HTML markup into a JavaScript template at build time. At runtime, you simply supply the data and you end up with DOM elements to be inserted or to replace an existing element (something innerHTML cannot easily do without extra DOM creation). Rebinding only requires requesting additional data, not the entire re-rendered markup. This is where large performance gains can be made as the markup can be nicely requested/cached separately from the data.

For simplicity, innerHTML has been the preferred method for the HTML-Message pattern style of Ajax. But tool-sets like JsonFx can make using JsonML and JBST just as easy while delivering a full browser-side templating Ajax pattern.

Comment by McK — February 11, 2009

>> If you cache your XSL processor rather than reparsing the XSL Document each time, then XSL will be faster

of course, XSL is the transformer, what changes is the XML (data), not its representation.
Same concept described by McK, but at the point you need two schema/protocols instead of one (JSON for the data, JsonML for the layout). Accordingly, I still wonder if it is worthy

Comment by WebReflection — February 12, 2009

P.S. guys in Ajaxian, you have some problem in the home page (layout … problems after “Fonts as a Web Service … etc”)

Comment by WebReflection — February 12, 2009

@IxVan — great point, that’s the most compelling argument I’ve seen for this thus far.
.
However, I use a “cross-domain trick” project that I run called flXHR which is a flash+javascript replacement with identical API to native XHR (so existing code works without further modification). http://flxhr.flensed.com
.
However, this JSONML and their templating may end up being helpful in a project I’m doing at work right now, so I’m glad to have that spin on the technology.

Comment by shadedecho — February 12, 2009

Why would I want to use both? My application or those web services I may interact with should use either XML or JSON, not both.

Comment by cnizz — February 13, 2009

@cnizz – You’d want to use both because sometimes you already have markup (e.g. XHTML), and JSON works extremely well with JavaScript. So in Ajax scenarios, it can be nice to express (and be able to deploy) your markup as a combination of JSON and JavaScript. With JsonML + Browser-Side Templates you can use JavaScript as your templating language inside of your XHTML.

JsonML in raw form is not meant to be human produced or consumed. If you need that, then just use XML or JSON. But when it is part of a templating solution, JsonML is a compact form for round-tripping markup in JavaScript. It is generated by machine (XSLT or compiler), so that you can lay out your work in XHTML as you naturally would, but it is sent down in JavaScript and can be compacted with all of your other client scripts.

JsonML is not meant to replace XML and it isn’t truly intended for data. That’s what JSON is for. But sometimes you have JSON data, and XML-based structured documents and you need to combine them. That’s when JsonML can provide real benefit.

Comment by McK — February 13, 2009

I’ve been exploring a more compact way of representing XML data in JSON format, and I came to the same conclusion that the [‘tagName’,{attr1Name:’attr1Value’},child1,…,childN] was about the most compact approach to representing XML nodes, while still respecting the structure of the XML document, and also producing something that looks / feels intuitive enough.

Comment by uize — May 9, 2009

Incidentally, JBST looks a little bit like the JST (JavaScript Templates) supported by the UIZE JavaScript Framework…
 
http://www.uize.com/explainers/javascript-templates.html

Comment by uize — May 9, 2009

Leave a comment

You must be logged in to post a comment.