To me, XML is merely a tool that provides context to text – and by extension, basic reasoning. Example, XSLTs extends XML by applying contextual transformation based on defined reasoning (screen size, ect.).

If you only require data interchange – and are using regular expressions anyway – the only(?) reason to use XML over .txt or .csv formats is communication. Here structure is only necessary to make apparent the data’s value (instead of the old fashioned syntax comments)…

If you’re using JSON to execute functions, then we are really no longer talking about a data model per se. XML has it’s roots in publishing, not scripting. To me, these are two very different tools.

Granted, these ideas are based strictly on theoretical ‘book’ learning. Please correct me if these manuals have steered me in the wrong direction…

Here’s a pastebin of it: http://pastebin.ca/965646

foo

bar

baz

Can you see anything you would have done differently?

This is a real example I’ve had to deal with (element names changed). I’ve seen other examples like that before. Have a look at any AJAX XML and ask yourself if there’s anything you would have done different — 95% of the time, there is. Not so much because there is no right/wrong, but moreso because there is no “simplest” way to do things most of the time. You can always justify the additional complexity. You can always change elements to attributes, attributes to subnodes, etc.

{“request”: [{"url": "foo"}, {"path": "baz"}]}

Doesn’t get much simpler.

@Shawn: Yes, it’s more constrained, less flexible… but it’s important to use the right tool for the job. You wouldn’t use JSON to represent HTML — that’s where XML is king.

Raw data transport is more often simple than not. If it isn’t, then it probably should be simplified.

Well, not quite…

My malicious page can include and then whenever someone who has logged in to your site views my page, Shazam! I get access to that data. Since it’s a script tag, it’s not subject to the same-origin-policy, and since I can override the constructor of Object, you don’t even need to assign the result to a variable. I am a little surprised that no-one else has mentioned this, but I guess normal people don’t think like Adam. (And I mean that as a compliment.

Since XML isn’t executable by anyone, you can’t pull the same trick. At least, I don’t think you can. Perhaps if there was some way to get at the data of an image tag…

“When you send data over XML, you’re not just sending data but you’re sending an entire culture along with it. And you need to be familiar with said culture to parse it.” Andrey Petrov

My question here is: Is this not a fundamental part of developing the ‘semantic web’: to create well defined definitions (DTD’s) – and standards (where possible) – of the complexities (the culture) involved in contribution & integration??

Another reasons that I like the concept of XML is the ability to utilize non-exponentiated parsing (PureXML in DB2 Viper for example) reducing the need for big math and encouraging mid-tier processing: granted this may come at a cost of greater demands on the I/O stream… But, this is a balance that can be managed through software design.

SO, it seems to me that the ambiguity referred to in XML goes back to the age old debate of simplicity versus flexibility. Thoughts??

All corrections are welcomed.

http://developer.yahoo.com/yui/docs/JSON.js.html

The same technique is described with more detailed inline comments here:

http://www.json.org/json2.js

@Andrey: JSON isn’t really less ambiguous—you still have to know what that list of lists of dictionaries *means*. As Blake Winton pointed out in email, parsing JSON still depends who’s doing the parsing.

@Kevin: I agree, if you don’t eval, it’s just as secure as XML. In that case, we’re arguing over the runtime and coding costs of one parsed representation vs. another.

@Bignose: I agree, JSON is a lot easier to read. I suspect this is the main reason it caught on, and other justifications are just rationalizations. (FWIW, I think it’s a pretty good reason…)

@Simon: Interesting to know that Yahoo has switched. Are they using eval() client-side, or parsing?