Update: To ensure proper context is propagated, as per Douglas Crockford’s follow-up comment below,
The context of my statement was Ajax data transfer. In that specific context, XML is in fact being replaced with JSON. I didn’t say anything about doing dishes.
Which, I believe, is an absolutely fair statement to make. In fact, if you were to run a couple of quick queries on the two pages this article spans you could determine quite easily that yes, in fact, this article had a heavy tendency to use the word ‘AJAX’,
Page1//html:p[contains(.,’AJAX’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_1.html//html:html/html:body//html:p[contains(.,’AJAX’)]
Page2//html:p[contains(.,’AJAX’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_2.html//html:html/html:body//html:p[contains(.,’AJAX’)]
What about dishes?
Page1//html:p[contains(.,’dishes’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_1.html//html:html/html:body//html:p[contains(.,’dishes’)]
Page2//html:p[contains(.,’dishes’)] = http://personplacething.info/service/proxy/return-xml-from-html/?uri=http://www.infoworld.com/article/07/09/07/crockford-ajax_2.html//html:html/html:body//html:p[contains(.,’dishes’)]
… Well, once again this statement can easily be determined to evaluate to true. Thanks for setting things straight, Douglas!
On a related note, isn’t it cool how you can combine something as ubiquitous as a URI path segment with something as ubiquitous as HTML turning the entire *live web* into an XPath query-able dynamic database as a result?
Anyone ever tried to do that same mapping with JSON?
Just wondering… ;-)
Enjoy your XML and JSON enhanced WebDevWeekends, everyone! :D
Update: I should quickly point out that my comment below regarding the comparison to Dave Winer had nothing to do with Crockford’s contributions to the development community — Douglas Crockford is a *HELLAVU* hacker and his contributions are both obvious and beautiful (as in Beautiful Code.) My statement was directly oriented towards his statement “Fortunately, XML has been replaced by JSON” which, if Dave Winer had invented JSON is exactly the kind of statement you would expect for him to make. Suggesting that XML has been replaced by JSON makes about as much sense as would suggesting that JSON has replaced data. While JSON is great as a data serialization format it doesn’t cook your dinner and clean your dishes. It’s a data container. A *NICE* data container, but a container none-the-less.
Anyway, just wanted to quickly clarify what I meant in my comparison below. Douglas Crockford doesn’t claim to have invented things he didn’t and then insist he be given credit regardless of the fact. And he most certainly knows how to write code like very few people on this planet are capable of. My apologies for making it seem I was suggesting otherwise.
[Original Post]
Web, AJAX slammed for deficiencies | InfoWorld | News | September 07, 2007 | By Paul Krill
XML is complicated and inefficient, he said. “Fortunately, XML has been replaced by JSON,” Crockford said. “This gives me some confidence that we can fix the standards in the Web. This is our first success at that.”
Yikes! And here I was thinking there would never again be another Dave Winer. ;-)
It is actually being replaced in one place I know of.
Still, you'll have to pry elementtree from my cold, dead..um..python 2.5.
At my workplace, we're rapidly agreeing to use JSON instead of XML. It's generally easy to generate and parse, regardless of whether you are human or computer. Many people would dispute that with regards to XML.
hey, I have lots of respect for Crockford, and I think he is probably a better programmer than Winer. I suspect he dislikes XML for the reasons that lots of programmers dislike it, because he really doesn't understand documents. He understands data. As an address format XML is sort of crap. However as a document in which we happen to have paragraphs, tables, oh and an embedded description of an Address, XML is the best solution you are likely to get. Json is not adequate.
Also I personally find JSONs ISO-8859-1 baggage highly disconcerting as a data format meant to do anything meaningful in this thing called the Web which I have it on good authority is World Wide.
Especially as this is the second bit of going backwards I've had to deal with this morning, someone else told me we had to do our document archiving system in ISO 8859-1 by LAW!!! aaarrggh. bastards.
Did you not get the memo? Well I guess if Crockford says so, then it is official! Do you want to start posting over at Json.Com ?
Just kidding! While _I_ think JSON is kewl, and easier to use on the client side, there are a TON of tools for XML. Do any RDBMS support JSON? None I know of, but XML seems to be in ALL of them. (Never mind that only RELATIONAL data belongs in an DB)
But hold on! Comparing Crockford to Dave Winer could get you in BIG trouble. I an not sure which of them would be insulted more.
Douglas Crockford was talking about Ajax. How often with Ajax do you need to send xml to the browser?
Most of the time, you just send back plain text to inject in the document or json for something a little more complex.
"I believe that the most important thing to understand in the JSON and XML debate is that they are really fundamentally built for two distinct purposes. XML is built for giving semantic meaning two text within documents. JSON is built for data structures. Unfortuneately, most developers have not understood this, and just used whatever that felt was the most popular. Yes, XML can describe data structures, but when you start really looking at the syntax for describing simple things like empty arrays in XML, it should be obvious to people, that JSON is much more naturally built for data structures."
@Dan,
Firstly, where ya been?! You've been missed, Phant-err, I mean Dan! :D
Secondly, oh good, a development company that knows so much about web development that the first thing they do is break the back button. > http://couchdb.org/CouchDB/CouchDBWeb.nsf/Home?OpenForm < Nice!
Sorry, I have no doubt these guys no how to write code, but for a "A Document Based Database" company I would expect them be more, you know, document oriented, and on the web, documents tend to suggest a REST-based architecture with proper separation of state between documents using a proper URI structure. And when I come across a site in which the first thing they do is force you to live within their "One Document URI Fits All" mentality my first reaction is that the last thing these kinds of people should be doing is writing "Document-Oriented" frameworks, or DB's, or whatever.
It seems the above back button break only takes place if you access http://jan.prima.de/~jan/plok/archives/89-CouchDb-updates.html and click on the CouchDB link *inside of Opera*. If you access http://couchdb.org/CouchDB/CouchDBWeb.nsf/Home?OpenForm directly and/or access it via clicking the same "CouchDB" link in the same page linked to above inside of any other browser, the back button works just fine.
Of course I don't want to come across as someone who hates JSON. JSON is great as a data serialization format, and while if you try really hard you could attempt to force it into a document oriented world, what's the point? (X)HTML isn't going anywhere, and to maintain page state in JSON, on the client or the server means you are enforcing an "always transform to/from JSON <~> (X)HTML" rule that simply doesn't need to be in place.
In short: If people are going to use JSON -- and I'm one of those folks who enjoys using it -- then use it as an over the wire data serialization format *NOT* as a drop-in replacement for (X)HTML which is exactly what some folks who know better seem to be attempting to champion.
I've actually started providing JSON services in addition to XML services for applications I'm writing that are publicly exposed, where it makes sense. Most of my back end work is still in XML - XSLT2 beats just about anything for doing complex structural manipulation (including generation of JSON from XML ;-) but I find that there are a number of younger web devs in particular who don't want to be bothered with parsing XML code, trying to set up the necessary clunky code for querying with XPath, or otherwise want to get their hands dirty with actual document manipulation.
Yeah, Crockford is a hard-core evangelist for his viewpoint, and yes I think that there are still quite a number of things for which JSON is not in fact all that good at representing, but I wouldn't put Crockford in the same camp as Winer. Winer had a couple of really good ideas then proceeded to act like a jerk with them; Crockford's generally worked very hard to insure that JSON can in fact work where it needs to.
@Ovid,
>> At my workplace, we're rapidly agreeing to use JSON instead of XML. It's generally easy to generate and parse, regardless of whether you are human or computer. Many people would dispute that with regards to XML. In my own experience there are really not that many people who find XML to be difficult to parse with either a computer or their own brains. What gets in the way most of the time is the tools they are forced to do that parsing with (from the standpoint of a computer.)
XSLT is by far and beyond the most common XML processing tool, and few will argue the fact that XSLT is a somewhat difficult language to learn at first (though it's drop dead simple once your brain has been properly rewired) and in this regard it's my own belief that the reason JSON tends to maintain a religious cult "I hate XML" following has more to do with being forced to process XML with either a language they don't understand or with Javascript and DOM, and to be quite honest if my only choice to process XML was Javascript and DOM I would give up coding all together and take on a career as a river guide or move to the Antarctic to study Polar Bears, so I can't really blame anyone for preferring JSON as a result.
@bryan,
>> hey, I have lots of respect for Crockford, and I think he is probably a better programmer than Winer.
Oh there's no question! Please see my update to the post for better clarification as to what I was referring to.
>> I suspect he dislikes XML for the reasons that lots of programmers dislike it, because he really doesn't understand documents.
I think that's a pretty fair statement. There are document oriented people and there are data oriented people. Crockford is definitely of the data oriented mentality.
>> He understands data. As an address format XML is sort of crap. However as a document in which we happen to have paragraphs, tables, oh and an embedded description of an Address, XML is the best solution you are likely to get. Json is not adequate.
Absolutely agree with that statement!
>> Also I personally find JSONs ISO-8859-1 baggage highly disconcerting as a data format meant to do anything meaningful in this thing called the Web which I have it on good authority is World Wide.
There are quite a few limitations in JSON that leaves me scratching my head as to why people see it as a drop-in replacement for XML. It just doesn't make any logical sense.
>> Especially as this is the second bit of going backwards I've had to deal with this morning, someone else told me we had to do our document archiving system in ISO 8859-1 by LAW!!! aaarrggh. bastards.
YIKES! Well I sure hope everyone in your company either speaks and/or interacts with people who only speak Latin-based languages! :D
@Ric,
>> Did you not get the memo?
No. When was it sent? ;-)
>> Well I guess if Crockford says so, then it is official! Do you want to start posting over at Json.Com ?
Could I? That would be *GREAT*, as if XML is no longer in existence then my guess is that XML.com is headed for the same downward spiral that the pager industry experienced when cell phones hit the scene.
Where do I sign?! ;-) :D
>> Just kidding!
WHAT?! Now where am I supposed to bitch and moan and cry about the stupid things that irritate me? This sucks!! ;-) :D
>> While _I_ think JSON is kewl, and easier to use on the client side, there are a TON of tools for XML. Do any RDBMS support JSON?
Not a clue. They probably will eventually, but there certainly a bit of time before it reaches the level of ubiquity that XML currently enjoys.
>> None I know of, but XML seems to be in ALL of them. (Never mind that only RELATIONAL data belongs in an DB)
I should have read a bit further before writing that last sentence ;-)
>> But hold on! Comparing Crockford to Dave Winer could get you in BIG trouble. I an not sure which of them would be insulted more.
:D :D :D Yeah, I've fixed that above. Hopefully my comparison is now brought into proper context.
@Dinoboff,
>> Douglas Crockford was talking about Ajax. How often with Ajax do you need to send xml to the browser?
I do all the time, but then again the way I use XML in the browser is different than most. View source @ http://personplacething.info/screen-scrape/ for a better understanding of what I mean.
>> Most of the time, you just send back plain text to inject in the document or json for something a little more complex.
Yeah, again the way I use XML is different than most, and in this regard using anything other XML doesn't make any sense. But I do recognize that JSON most certainly has its place, so no contention in that regard here.
@Robert,
>> "I believe that the most important thing to understand in the JSON and XML debate is that they are really fundamentally built for two distinct purposes. XML is built for giving semantic meaning two text within documents. JSON is built for data structures.
Nicely stated!
>> Unfortuneately, most developers have not understood this, and just used whatever that felt was the most popular. Yes, XML can describe data structures, but when you start really looking at the syntax for describing simple things like empty arrays in XML, it should be obvious to people, that JSON is much more naturally built for data structures."
Absolutely agree!
@Kurt,
>> Yeah, Crockford is a hard-core evangelist for his viewpoint, and yes I think that there are still quite a number of things for which JSON is not in fact all that good at representing, but I wouldn't put Crockford in the same camp as Winer.
Yeah, that was my bad for not clarifying the comparison I was making. Please see my update to the original post.
>> Winer had a couple of really good ideas then proceeded to act like a jerk with them; Crockford's generally worked very hard to insure that JSON can in fact work where it needs to.
100% agree!
The comment by Robert finds the heart of the JSON/XML debate. XML shines in the document realm, JSON in the data structure realm. ODF, HTML, OOXML and similar docs are done in XML, JSON would be ridiculous. If you are working with passing around data structure information though, JSON is beautiful, and XML works OK. Judging by the hoopla, I have to agree with Robert, most people don't seem to "get" this. Maybe its because many programmers don't work or even think in the document realm - unfortunate as the rest of the world certainly doesn't think in the data structure realm.
@mawrya,
>> The comment by Robert finds the heart of the JSON/XML debate. XML shines in the document realm, JSON in the data structure realm. ODF, HTML, OOXML and similar docs are done in XML, JSON would be ridiculous. If you are working with passing around data structure information though, JSON is beautiful, and XML works OK. Judging by the hoopla, I have to agree with Robert, most people don't seem to "get" this. Maybe its because many programmers don't work or even think in the document realm - unfortunate as the rest of the world certainly doesn't think in the data structure realm.
I do like what Crockford said regarding HTML being confused as to "whether it is a document format or an application delivery format". HTML is a document format that has been bent into that shape of an application GUI format when required. XHTML seems to try and improve on the situation by introducing menu elements, but I wonder if we really need something separate yet complimentary, like XUL...maybe...but even more. Have you ever read anything about this HTML dichotomy? It seems glaring but I assume most people don't see this as I haven't seen much written about it.
The context of my statement was Ajax data transfer. In that specific context, XML is in fact being replaced with JSON. I didn't say anything about doing dishes.
@Douglas,
>> The context of my statement was Ajax data transfer. In that specific context, XML is in fact being replaced with JSON.
Fair enough. And in that context your statement definitely holds water. I'll update the post accordingly to be sure others gain a better understanding of the proper context.
>> I didn't say anything about doing dishes.
True. Though there are others on this planet who seem to lose sight of the fact that there is no such thing as a Silver Bullet Refrigerator, Stove, and Dishwasher that also cooks, sets the table and cleans up aftwerwards, and unfortunately your wonderful contribution to this world tends to attract a younger crowd of developers who directly associate DOM with XML and therfore believe that XML is pure evil plain and simple.
None-the-less, this doesn't take away from the fact that in and of itself, JSON is a wonderful tool. Thanks for creating it for the rest of us (as well as yourself) to enjoy!
@mawrya,
Sorry, seemed to have missed your most recent comment,
>> I do like what Crockford said regarding HTML being confused as to "whether it is a document format or an application delivery format". > HTML is a document format that has been bent into that shape of an application GUI format when required. XHTML seems to try and improve on the situation by introducing menu elements, > but I wonder if we really need something separate yet complimentary, like XUL...maybe...but even more. > Have you ever read anything about this HTML dichotomy? It seems glaring but I assume most people don't see this as I haven't seen much written about it.