Hacker News Reader

Comment by MostAwesomeDude | Hacker News Reader

Don't limit yourself to JSON. Your dislike of XML does not mean that JSON is always the right answer. Instead, write code that flexibly can render to any of a set of formats, and use content negotiation to determine which format the user agent wishes to consume. This lets you do things like let the read-only portion of your API be accessible via browser, and it will future-proof you.

View on HN

I did think that the criticism of XML for being hard to parse was a bit odd. Although I generally prefer JSON for simpler stuff XML is pretty easy to parse and sift through with XPath.

It has to do with the awful XML generated by automatic tooling (SOAP by WCF and JEE).

Hand-generated XML can be just as nice as using hand-generated JSON, and on the other hand automatic domain-model-to-JSON mapping can be as ugly as any XML monstrosity.

Most languages have the concept of arrays and hashes, which map unambiguously & idiomatically to JSON via generic serializers.

Creating idiomatic XML, on the other hand, is a little more tricky. Should something be a tag or an attribute? What should it be named?

Though for the same dataset, XML will be slower to parse. For performance's sake use JSON.

> Though for the same dataset, XML will be slower to parse. For performance's sake use JSON.

Loading a huge JSON file is almost certainly slower than using a SAX parser for a huge XML file. Maybe there are SAX like approaches for JSON, too.

Yes, it's called "streaming". Like in XML, you can also used a mixed approach. See e.g. https://sites.google.com/site/gson/streaming

I suspect that depends a lot on what platforms are used at the client and server.

when he says "use JSON where possible XML only where you have to", I thought it was funny, like developers out there are just dying to use this verbose behemoth instead of its terser cousin json. But anyways, I agree with everything you're saying just wondering if there actually are any devs out there who just adore some sweet XML (seriously) ?

OP here. I got an email with an interesting argument on the topic. Paraphrasing: Today JSON is hip, tomorrow may be something else. By supporting XML by default and using XSLT to translate it to alternate outputs, you're able to support multiple formats without having to modify your software itself. Ofcourse, this does come with the cost of having to maintain XSLT files.

To businesses that need to support multiple formats (enterprise requirements?), XML + XSLT sounds like a fair approach - it allows you to simultaneously create idiomatic XML & JSON

> By supporting XML by default and using XSLT to translate it to alternate outputs, you're able to support multiple formats without having to modify your software itself.

By separating out the rendering-to-an-output format from the basic logic of the application, you get similar benefits without creating a dependency on XML handling libraries and requiring another implementation language (XSLT) for the rendering component.

There's no benefit to using XSLT instead of just writing code to transform your data into another format.

I'm not a fan of XML, but I do like RDF, and unfortunately RDF/XML is the most common encoding format.

Reply on news.ycombinator.com