Live data from Hacker News

Why JSON will continue to push XML out of the picture

blog.appfog.com

11–20 of 47 posts

Re: Why JSON will continue to push XML out of the picture

#11

Could someone who knows a lot about these things tell me why JSON took such a long time to arrive? JSON, at its core, is essentially a hierarchy of maps and lists -- which seems a very intuitive and useful way to store data. XML on the other hand has always baffled me with its attributes and the redundant and verbose tags (why do I need data ?). I'm sure there was a good reason at the time for this, so perhaps someon…

What took the longest time was for a language to come out with key-value maps as the main core data structure, and a specialized literal syntax. Once that happened, it was relatively quick for that syntax to become a standardized interchange format for K-V data.

Lisp had assoc-lists, but those were a convention, not a specialized structure. Many languages had K-V maps as libraries, but not core structures, and most lacked literal syntax. Eventually most scripting languages starting getting them as native, and even having literal syntax, but they weren't the "go-to" data structure for doing things. In Python, for example, all of its objects are really just hash maps, but when you're working with them you pretend that they're objects and not hash maps, and you use lists more than maps anyways.

JavaScript (and maybe Lua) was the first language to build itself around K-V maps, so it was the first language where idiomatic usage included a lot of map literals. Like Python, its objects were all really just maps, but unlike it encouraged taking advantage of that fact. Also, because it was on the web, there was a lot of need to be serializing data structures and passing them around. Eventually someone realized "this is much better than XML!" and gave it a name, and that's how we got where we are today.

XML's popularity is an accident of history, due in part to the rise of HTML, which is also an accident of history.

Re: Why JSON will continue to push XML out of the picture

#12

For me the single greatest selling point of JSON is that it's just so danged easy to go from json string to a usable map/list/dictionary in every language. Most of the time you can get from A to B in one or two lines of code. XML always seemed like such a struggle by comparison. Figuring out which parser(s) you've got installed, figuring out their respective APIs -- it felt like total overkill. The only way I could b…

I don't understand why JSON schemas and the OJMs (Object-JSON-Mappers ;) it would enable aren't being developed more heavily.

I love JSON, but when working on APIs between large companies / departments the "we'll just send JSON like this and email you when we change stuff" really won't cut it.

Re: Why JSON will continue to push XML out of the picture

#13

Could someone who knows a lot about these things tell me why JSON took such a long time to arrive? JSON, at its core, is essentially a hierarchy of maps and lists -- which seems a very intuitive and useful way to store data. XML on the other hand has always baffled me with its attributes and the redundant and verbose tags (why do I need data ?). I'm sure there was a good reason at the time for this, so perhaps someon…

I've actually always liked the idea of XML at it's core- attributes and so on often make data structures easier to understand (just look at HTML), but namespacing and all that junk ruined the whole thing.

The only reason I still use XML every now and then is XPath. There are third-party alternatives for JSON, but XPath is ubiquitous.

Re: Why JSON will continue to push XML out of the picture

#14
post #12

For me the single greatest selling point of JSON is that it's just so danged easy to go from json string to a usable map/list/dictionary in every language. Most of the time you can get from A to B in one or two lines of code. XML always seemed like such a struggle by comparison. Figuring out which parser(s) you've got installed, figuring out their respective APIs -- it felt like total overkill. The only way I could b…

I don't understand why JSON schemas and the OJMs (Object-JSON-Mappers ;) it would enable aren't being developed more heavily. I love JSON, but when working on APIs between large companies / departments the "we'll just send JSON like this and email you when we change stuff" really won't cut it.

Let me state that for the record, I believe JSON is a fantastic data interchange format, especially when compared with the current state of XML.

However, the point you've touched on is exactly my gripe with JSON. I just might not know enough, which is completely adequate, but afaik all the JSON schemas are either extremely complicated (I'm looking at you json-schema) or way too simple (jschema).

When working with service oriented architectures and if you're following the principles of RESTful architecture, discoverability and HATEOAS become central to your service. That means that the API needs to be self-documenting.

How does one do this with JSON? Essentially, if you boil the problem down, what someone would try to accomplish is "marking up" their JSON responses/requests. The irony is hilarious because this is exactly the job that XML was designed for.

It's obvious that the XML ecosystem grew way of control exogenously, but the core concept was very simple and was designed to solve this exact problem which I think the JSON ecosystem currently lacks.

Re: Why JSON will continue to push XML out of the picture

#15

Could someone who knows a lot about these things tell me why JSON took such a long time to arrive? JSON, at its core, is essentially a hierarchy of maps and lists -- which seems a very intuitive and useful way to store data. XML on the other hand has always baffled me with its attributes and the redundant and verbose tags (why do I need data ?). I'm sure there was a good reason at the time for this, so perhaps someon…

From a big data perspective, I'm pretty sure people were making do with CSV files before JSON came along. I think most practitioners would not subject themselves to stupid, stupid XML unless they really had to.

Re: Why JSON will continue to push XML out of the picture

#16
post #10

Well-written XML that was designed for humans instead of machines is much, much more easier to read than JSON. The primary reason is that unlike s-expressions or xml, there is no block-name. In JSON you loose valuable time figuring out the block context in a hierarchy since this isn't labelled. The only kind of JSON that is readable is flat JSON that is nested to a maximum of 1 level.

Either format can be pretty printed. If you need signposts to figure out where you are, it is a simple manner to add dictionary key names to things.

Re: Why JSON will continue to push XML out of the picture

#18

I think this article has done a great job enumerating trends that show JSON is beating XML for data serialization applications. I think these points are evidence of a shift in thinking, but not the reason for shift itself. Why JSON over XML? Because people need data serialization format and XML is a Markup Language. JSON is gaining widespread adoption for data serialization applications since it's the correct tool. X…

It also sounds like the right tool for making something like SVG. The vast majority of SVG data isn't text.

Re: Why JSON will continue to push XML out of the picture

#19
post #11

Could someone who knows a lot about these things tell me why JSON took such a long time to arrive? JSON, at its core, is essentially a hierarchy of maps and lists -- which seems a very intuitive and useful way to store data. XML on the other hand has always baffled me with its attributes and the redundant and verbose tags (why do I need data ?). I'm sure there was a good reason at the time for this, so perhaps someon…

What took the longest time was for a language to come out with key-value maps as the main core data structure, and a specialized literal syntax. Once that happened, it was relatively quick for that syntax to become a standardized interchange format for K-V data. Lisp had assoc-lists, but those were a convention, not a specialized structure. Many languages had K-V maps as libraries, but not core structures, and most l…

> Lisp had assoc-lists, but those were a convention, not a specialized structure.

I'm not sure what you mean by this. What's the difference, syntactically, between a convention and a specialized structure?

XML is Lisp. In fact, the XML grammar and Lisp's grammar are (almost) homomorphic[1]. SXML is a trivial mapping of XML to s-expressions which demonstrates this.

There's no point in comparing XML and S-expressions like that; they're essentially the same thing!

If you're talking about internal representation, well, that's up to the compiler. But since you have to declare the format either explicitly or by context, there's no 'advantage' of XML over s-expressions.

[1] To be pedantic, XML is homomorphic to SXML, which is a subset of the Lisp grammar, but that just means that Lisp recognizes some strings that aren't in the XML grammar, so if anything, Lisp is more powerful, but that's beside the point.

Re: Why JSON will continue to push XML out of the picture

#20

I don't foresee JSON ever replacing XML as a "full-blown successor" in the contexts where XML actually is useful: for marking up documents. As a general data storage format, XML is certainly going away.

It might for non-text document structures, perhaps.
Post reply on HN