Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

JSON or XML: Just Decide

mnot.net

Post reply on HN
Print view View original

31–40 of 44 posts

Re: JSON or XML: Just Decide

#31

Post by Yarnage »

dajobe wrote: post #26
tptacek wrote: post #21

Earlier quoted context omitted.

We use JSON for graphs. What sucks about it? In what sense is XML better at representing graphs?

There's no way to point from one part of a JSON doc to another without inventing a terminology or convention for marking the start (anchor) and end of the arc (href). People use 'id' for one end but there's no way to say a json value is actually a reference (href) not just a string. XML has that built in (ID IDREF) and so does HTML, but I didn't say XML was better, I said JSON sucks at markup and graphs. JSON's handy…

What do you mean by "built in"? I don't see how or why an ID couldn't be used in the same manner; the implementation is just a little different because they store data differently.

XML is only a series of nodes and attributes. There isn't really anything else special about it and it's trivial to represent it in JSON so I'm not sure I follow your issue. Could you provide an example?

Re: JSON or XML: Just Decide

#32

Post by 6ren »

He's talking specifically about web APIs.

Web APIs tend to have simple, shallowly nested formats. In an informal survey, the deepest nesting I found was 3 levels. JSON is simple, and has resisted all efforts to complicate it, or to add to its stack. There is no popular schema for JSON, no "JSLT". no visual JSON mapping tools. The only tooling is databinding (and if you consider JSON as a subset of JavaScript, it arguably has not even that).

The XML toolchain, especially XML Schema and XSLT, is highly engineered - well, over-engineered. The designers threw in everything they could think of. As a result, even enterprise tools don't need to support the whole spec.

I think it's fair to say that if you need something more powerful (and therefore more complicated) than JSON, you should use XML. It seems the very existence of the XML toolchain helps keep JSON simple: instead of demand for complexity being channeled into over-tooling JSON, it is harmlessly diverted to XML.

The deeper question is: do our tasks really NEED that extra complexity? It seems related to loose dynamic typing vs. tight static typing (and scripting vs. compiled). Maybe web APIs are an exception - or, because very young, haven't yet needed the complexity that beset CORBA, then XML... Or maybe they are an exception, but it doesn't matter because everything is becoming a web API anyway. Or... maybe we're finally got it right...?

There are pervasive needs that JSON doesn't address. For example, there's a problem with coupling between JSON and application data structures in that they must be the same basic shape. So to give your JSON format the ideal shape for consumers, you need to translate into a layer of objects first - and your consumers need to do the same thing to get it into their internal data structures, Similarly, you aren't free to evolve; instead, you produce another version, and all your clients must upgrade. Most web APIs are very very young, yet have several versions already... The same problems occurred in XML (and CORBA), and though JSON is an improvement in that it allows fields to be added more easily, the tooling to support conversion/evolution hasn't grown up around it (and isn't growing).

I think the answer is that JSON works great when the underlying features of applications are changing quickly because you can't "evolve" around this, you need humans to rethink the basics. while "web APIs" continue in vigorous growth, it will dominate. Maybe it will settle down and consolidate, once everything has changed into a web API... or maybe continuous churn will become the rule, as everything accelerates?

[Interestingly, relational algebra squarely addressed and solved these problems 42 ago. It's still going strong; though also under attack by the similar forces (NoSQL) allied with loose dynamic typing of scripting languages, and the need for so-called "web-scale" performance being greater than the need for evolution/conversion... at present.]

Re: JSON or XML: Just Decide

#34

Post by mindcrime »

rollypolly wrote: post #27
mindcrime wrote: post #9

Use the right tool for the job. I wouldn't say that XML or JSON is always right. But I will say that I believe XML has a better ecosystem around it; with things like XSD, XSLT, XQuery/XPath, etc., and some pretty easy to use data-binding frameworks like JAX-B. My feeling is that XML makes it a lot easier to do certain classes of things that I want to do, like taking a business event message off a queue, match it agai…

Yeah, the XML ecosystem is priceless. XPath, for example, is the one reason a project I'm working on can't switch to JSON.

I was about to ask if JSON had an equivalent to XPath / XQuery, but it looks like the answer is "yes." http://stackoverflow.com/questions/8481380/is-there-a-json-e...

That's cool to know, and I might just give it a look. But my perception is still that the supporting ecosystem around XML is more mature and comprehensive, at least for some use-cases.

Re: JSON or XML: Just Decide

#35

Post by Yarnage »

6ren wrote: post #32

He's talking specifically about web APIs. Web APIs tend to have simple, shallowly nested formats. In an informal survey, the deepest nesting I found was 3 levels. JSON is simple, and has resisted all efforts to complicate it, or to add to its stack. There is no popular schema for JSON, no "JSLT". no visual JSON mapping tools. The only tooling is databinding (and if you consider JSON as a subset of JavaScript, it argu…

>For example, there's a problem with coupling between JSON and application data structures in that they must be the same basic shape. So to give your JSON format the ideal shape for consumers, you need to translate into a layer of objects first - and your consumers need to do the same thing to get it into their internal data structures,

Don't you need to do the same-thing with XML? How do you use XML data without conforming it to your internal structures first? You can't just guess...I just don't get the difference here. I'm trying to understand what XML can offer that JSON cannot. Do you have an example?

>Similarly, you aren't free to evolve; instead, you produce another version, and all your clients must upgrade.

Same-thing here; doesn't XML have the same issue? Upgrading formats can make XML useless just as well as JSON. Also, just like JSON, you can upgrade them without issue so I'm not seeing the distinct advantage of XML over JSON. Do you have an example?

I'm not trying to be argumentative; I just haven't seen any examples showing what makes XML better than JSON just lots of "you can't do this in JSON" and I can't find a way to make that true in my head...

Re: JSON or XML: Just Decide

#36

Post by Yarnage »

cpunks wrote: post #14

Or... they're designed for different purposes and not even competitors. XML is a markup language: http://en.wikipedia.org/wiki/Markup_language It was designed for documents. Try converting an HTML page to JSON. Try something as simple as: Hello World! The most common introductory program is called Hello, World . Go on. If you think JSON wins, just do it, and post it below. The problem was when people started mis-appl…

Data representation is great in JSON. Actual layout information? Well it's doable but it's not as easy to see. This is why HTML is NOT XML and also why you wouldn't want to convert HTML to JSON.

So I'm not really sure what your point is. Are you trying to say that, because HTML (which is NOT XML) is awkward to represent in JSON, that XML wins?

Re: JSON or XML: Just Decide

#37

Post by 6ren »

Yarnage wrote: post #35
6ren wrote: post #32

He's talking specifically about web APIs. Web APIs tend to have simple, shallowly nested formats. In an informal survey, the deepest nesting I found was 3 levels. JSON is simple, and has resisted all efforts to complicate it, or to add to its stack. There is no popular schema for JSON, no "JSLT". no visual JSON mapping tools. The only tooling is databinding (and if you consider JSON as a subset of JavaScript, it argu…

>For example, there's a problem with coupling between JSON and application data structures in that they must be the same basic shape. So to give your JSON format the ideal shape for consumers, you need to translate into a layer of objects first - and your consumers need to do the same thing to get it into their internal data structures, Don't you need to do the same-thing with XML? How do you use XML data without con…

Yes, XML has the same problem. The end of that paragraph reads:

> The same problems occurred in XML (and CORBA), and though JSON is an improvement in that it allows fields to be added more easily, the tooling to support conversion/evolution hasn't grown up around it (and isn't growing).

Maybe it's not clear, but the tooling to solve these problems has grown up around XML. Mainly XSLT, and visual mappers that operate on top of that. Examples: MS's Biztalk mapper http://msdn.microsoft.com/en-us/library/aa547076.aspx; MapForce http://www.altova.com/mapforce.html; StylusStudio XML mapper http://www.stylusstudio.com/xml_to_xml_mapper.html; both IBM and Oracle have similar - this category of tooling has been around a decade or so; XSLT itself started in 1997 http://en.wikipedia.org/wiki/XSLT). Have a look at the images in those links - you'll immediately see what they do.

So to be precise, XML doesn't solve these problems, its tools do.

Re: JSON or XML: Just Decide

#38

Post by derickson »

mindcrime wrote: post #9

Use the right tool for the job. I wouldn't say that XML or JSON is always right. But I will say that I believe XML has a better ecosystem around it; with things like XSD, XSLT, XQuery/XPath, etc., and some pretty easy to use data-binding frameworks like JAX-B. My feeling is that XML makes it a lot easier to do certain classes of things that I want to do, like taking a business event message off a queue, match it agai…

Using an XML native NoSQL database is a game changer when consuming XML and producing XML HTTP APIs. A good XQuery engine makes many of the problems people are listing about XML simply go away.

I like @mnot's point about providing "excellent client bindings" in common languages.

Re: JSON or XML: Just Decide

#39

Post by rollypolly »

mindcrime wrote: post #34
rollypolly wrote: post #27

Earlier quoted context omitted.

Yeah, the XML ecosystem is priceless. XPath, for example, is the one reason a project I'm working on can't switch to JSON.

I was about to ask if JSON had an equivalent to XPath / XQuery, but it looks like the answer is "yes." http://stackoverflow.com/questions/8481380/is-there-a-json-e... That's cool to know, and I might just give it a look. But my perception is still that the supporting ecosystem around XML is more mature and comprehensive, at least for some use-cases.

Interesting. All these solutions are javascript-based tho. We need a C-based solution (like libxml2).

Re: JSON or XML: Just Decide

#40

Post by mindcrime »

derickson wrote: post #38
mindcrime wrote: post #9

Use the right tool for the job. I wouldn't say that XML or JSON is always right. But I will say that I believe XML has a better ecosystem around it; with things like XSD, XSLT, XQuery/XPath, etc., and some pretty easy to use data-binding frameworks like JAX-B. My feeling is that XML makes it a lot easier to do certain classes of things that I want to do, like taking a business event message off a queue, match it agai…

Using an XML native NoSQL database is a game changer when consuming XML and producing XML HTTP APIs. A good XQuery engine makes many of the problems people are listing about XML simply go away. I like @mnot's point about providing "excellent client bindings" in common languages.

What DB do you like for storing and querying XML? I've been using eXistDB lately, but I'd be curious to hear if people are finding something else to be better.
Post reply on HN