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

Why JSON will continue to push XML out of the picture

blog.appfog.com

Post reply on HN
Print view View original

31–40 of 47 posts

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

#31

Post by lmm »

mahmoudimus wrote: post #14
mtrimpe wrote: post #12

Earlier quoted context omitted.

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 ser…

HATEOAS, discoverable apis, and the overengineered gunk that has today hijacked the name of REST (ironic, when much of the point of the original REST was to be not SOAP) remain pipe dreams. You can't write an API that clients that don't know your API can use, and I suspect it will take at least a hundred years until that becomes possible.

Certainly XML schema doesn't let you accomplish this. All I've ever seen it accomplish is telling you that a document doesn't conform to the schema, functionality that you can trivially achieve in JSON any number of ways (e.g. an API version field in the data).

There's no point trying to write a schema system without a use case that it can solve, and I've never seen such a thing.

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

#32

Post by jerf »

Joeri wrote: post #24
portmanteaufu wrote: post #7

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…

XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end. JSON on the other hand is duck typing in web service form. You can shove any data structure in on one end, and get it back out the other end, without writing any custom code, and without actually knowing the type of the data you've sen…

"XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end."

This is a characteristic of the encoding and decoding layer, not the data format. Haskell's aeson library [1] is a JSON serialization library that is perfectly well strongly typed. And yes, that's strongly typed with your local domain datatypes and a relatively-easy-to-specify conversion back and forth, not merely strongly typed by virtue of having a "JSONString" type here and a "JSONNum" type there.

[1]: http://hackage.haskell.org/packages/archive/aeson/0.6.0.2/do...

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

#33

Post by emmett »

tptacek wrote: post #23
clarkevans wrote: post #8

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…

This makes sense, but from what I can tell, in virtually no major XML-based systems is the basis for XML files an underlying text extended with markup. Most XML systems, since the dawn of XML, have been top-to-bottom structured data.

With the almost unique exception of xhtml. But that's actually the only one I can think of.

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

#34

Post by lmkg »

chimeracoder wrote: post #19
lmkg wrote: post #11

Earlier quoted context omitted.

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 l…

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

The big difference is how people look at it, not what it really is. JavaScript has a built-in key-value map data structure. An assoc-list isn't a built-in data structure, it's a way of using a more primitive data structure (lists). In particular, assoc-lists don't really look different than normal lists, so it's a slightly larger mental leap to think in terms of them. Furthermore, Lisp doesn't use assoc-lists as often as JavaScript uses key-value maps, preferring flat lists instead, so even if there were a specialized reader-macro for assoc-lists it wouldn't have been as ubiquitous.

I agree that XML and Lisp grammars are basically interchangeable. My comment was answering a question about the emergence of JSON, and my comments about assoc-lists were only in relation to JSON, not XML.

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

#35

Post by Joeri »

jerf wrote: post #32
Joeri wrote: post #24

Earlier quoted context omitted.

XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end. JSON on the other hand is duck typing in web service form. You can shove any data structure in on one end, and get it back out the other end, without writing any custom code, and without actually knowing the type of the data you've sen…

"XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end." This is a characteristic of the encoding and decoding layer, not the data format. Haskell's aeson library [1] is a JSON serialization library that is perfectly well strongly typed. And yes, that's strongly typed with your local domai…

That's an impressively succinct way of mapping types to JSON, but it's still a mapping. There's one step for the developer between obtaining the JSON and using its data. In weakly typed languages there is no such step, the JSON data is the object you interact with in your business logic.

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

#36

Post by silverbax88 »

tptacek wrote: post #23
clarkevans wrote: post #8

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…

This makes sense, but from what I can tell, in virtually no major XML-based systems is the basis for XML files an underlying text extended with markup. Most XML systems, since the dawn of XML, have been top-to-bottom structured data.

In the financial sector/mortgage/insurace, there are several major standards that are based on XML which is not top-down.

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

#37

Post by wes-exp »

lmkg wrote: post #11
Xcelerate wrote: post #2

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 also had plists, which practically look like Json:

For instance (:name "Bob" :age 50) being a plist called person would give (getf person :age) as 50.

That seems pretty similar to {"name": "Bob", "age": 50} and person.age to retrieve the value 50.

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

#38

Post by ianburrell »

bartonfink wrote: post #30
tptacek wrote: post #23

Earlier quoted context omitted.

This makes sense, but from what I can tell, in virtually no major XML-based systems is the basis for XML files an underlying text extended with markup. Most XML systems, since the dawn of XML, have been top-to-bottom structured data.

I may be talking out of my ass here, but isn't OO-XML and whatever Microsoft calls their new Office format exactly that?

Both OO-XML and ODF are XML based. They both put the main XML document in a ZIP archive along with metadata and other resources.

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

#39

Post by tptacek »

bartonfink wrote: post #30
tptacek wrote: post #23

Earlier quoted context omitted.

This makes sense, but from what I can tell, in virtually no major XML-based systems is the basis for XML files an underlying text extended with markup. Most XML systems, since the dawn of XML, have been top-to-bottom structured data.

I may be talking out of my ass here, but isn't OO-XML and whatever Microsoft calls their new Office format exactly that?

You're right, I forgot about the "proprietary" document formats that got transformed into "open" (heh) XML formats. Good point. Thanks!

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

#40

Post by jerf »

Joeri wrote: post #35
jerf wrote: post #32

Earlier quoted context omitted.

"XML is a smooth fit on strongly typed languages. You can easily translate an exact type into a corresponding XML encoding and know the type of what you're getting out on the other end." This is a characteristic of the encoding and decoding layer, not the data format. Haskell's aeson library [1] is a JSON serialization library that is perfectly well strongly typed. And yes, that's strongly typed with your local domai…

That's an impressively succinct way of mapping types to JSON, but it's still a mapping. There's one step for the developer between obtaining the JSON and using its data. In weakly typed languages there is no such step, the JSON data is the object you interact with in your business logic.

There's always a serialization step. The type of the resulting data is a consequence of the serialization technique, not the data format. I demonstrated the part you seemed to most strongly claim didn't exist, JSON strong typing, but I can show you "weakly-typed" XML too. In addition to the DOM, which is a standardized "weak type" XML representation, you also have things like ElementTree http://effbot.org/zone/element-index.htm .

It is the case that JSON has a simple default weak serialization in many popular languages, and that it is a great deal of the reason for its popularity, but it is worth pointing out this is a local effect in the Javascript/Python/Perl/Ruby space, and that it hasn't got anything to do with strongly or weakly typed but rather what the target languages shipped with. There is no natural mapping for JSON in C++, C#, Erlang, Haskell, Prolog, SQL, or a wide variety of other languages (and Erlang and SQL are both fairly "weakly typed"), and even in JS/Python/Perl/Ruby there are some edge cases that can bite you if you aren't careful about exactly what the "just_decode_some_json_man()" is really doing with Unicode and numbers that may not fit into 32 bits.

(Also, I scarequote all my "weakly typed" because the term is basically ill-defined. I'm coming around to prefer "sloppy type", which is a language where all values are perfectly well strongly typed but the language and/or library is shot through with automatic coercions and/or extensive duck typing. A sloppy type language considers it a feature that a function may have a a value and not really know or care what it is.)

Post reply on HN