The Problem Is Not JSON Or XML, It Is About Data Context

JSON tends to be easier to work with because it maps directly to the standard types and structures used by most programming languages (string, number, boolean, map, and list). XML requires additional types to represent elements, text nodes, etc., making it a bit more cumbersome to work with. JSON also has a much simpler path syntax: "foo.bar[0]" vs. XPath.

However, XML is excellent for defining more complex hierarchies that would be difficult or impossible to represent in JSON. For example, the following XML conveys that I specifically want a "Foo" that has a "bar" property of value "123":

<Foo bar="123"/>

In JSON, the best I can do is:

{ bar: "123" }

which doesn't tell me anything about the nature of the object that contains "bar".

So I agree that they both have their places.

Yes, there are quite a few for both. See the list at the bottom of http://json.org.

Here's the thing you're missing though. HTML *is* XML. If twitter provides me with nice, semantically marked up, well formed html, I don't need to covert or parse anything. I can just jam the output directly into a page as is and style it however I want with a css file. That's the easiest option of all.

You say the html isn't formed the way you want? Well, first I'd challenge you to make sure you really mean that, but if you aren't convinced, then there are already tons of great javascript libraries (I'm partial to JQuery) that know how to manipulate plain old html in whatever fashion you want. No xml parsers or xslt knowledge is required.

Actually, HTML is not XML. It looks a lot like it, but the rules are nowhere near as stringent. Only XHTML is truly XML, and, though that was a W3C recommendation for HTML 4.0, it has been dropped for HTML 5.

That aside, the purpose of using JSON or XML is to separate data from presentation. I may want to present that data in a form that is completely different from how you want to present it. I may not even want to use HTML - perhaps I want to generate an SVG diagram, or a PDF, or display it in a table control in a rich client app.

You are correct that it is possible to manipulate HTML via JavaScript, but doing so is generally much more difficult than manipulating either XML or JSON, because the rules for HTML are considerably more lax, and because HTML is designed for presentation, not data transfer.

Actually, I was avoiding HTML. Also, we need to be careful when dealing with HTML because it is not XML. XHTML-strict is XML, but traditional HTML is not. I believe HTML5 is supposed to be conformant XML, so that the differences will finally go away. As you say, if you get well-formed HTML, you do not need to do anything, but APIs typically are only giving you data, not what the HTML should look like. If you have your own internal APIs you could definitely transfer HTML directly. Personally, I am not a big fan of returning HTML from a web service because that normally means the service returns data that has one purpose only. I would prefer to get the data and then use frameworks like JQuery to build the HTML. Also, HTML is a display markup so you would need to know how the data is formatted in order to use it. Obviously, you need to know the format of JSON and XML data, but these can be "discovered" better than the HTML. Overall, not using HTML for data transfer is more of a personal preference.

Sorry about that. Based on your original comment it looked like you were trying to compare them directly. My apologies for making assumptions.

It is true that the rules for html are more lax, but if I'm an api provider I am free to produce html that is well formed xml and to guarantee that it is so. Call it xhtml if you wish. Nothing prevents me from presenting the same html differently from the way you do, either via css or more sophisticated javascript means.

How is using jquery (say) to manipulate html more difficult? Remember, my requirement is semantically marked up, well formed html. If a company like twitter is interested in having people use their api, they will make it as easy to use as possible. What I'm saying is that this is the easiest way.

My main point is that (svg and pdf formatting aside) the stuff I get from twitter or whomever is problably going to end up as html. Why not send it to me as html instead of making me convert it from some xml or json format *into* html.

p.s. Your statement that html isn't designed for data transfer is pretty funny considering that (I would guess) the majority of the world's data gets transferred as html every minute of every day.

Your statement that html isn't designed for data transfer is pretty funny considering that (I would guess) the majority of the world's data gets transferred as html every minute of every day.

You are describing the presentation of data. Most of the actual data is stored in a UI-independent manner in a back end system somewhere (e.g. in a relational database or...yup, you guessed it - XML or JSON, or some other format).

I'm honestly shocked that there is a single developer who would actually argue in favor of combining data and presentation! But to each his/her own, I guess. Fortunately, I believe you are in the minority here.

My main point is that (svg and pdf formatting aside) the stuff I get from twitter or whomever is problably going to end up as html. Why not send it to me as html instead of making me convert it from some xml or json format *into* html.

Because I don't want to have to work around or worry about your formatting, or deal with it when you decide to change that formatting. This isn't an issue for XML or JSON, since they are data formats (whereas, again, HTML is not).

Also, not all consumers of data feeds are simple web pages that want to regurgitate HTML. They could be (and often are) back end systems that want to perform more detailed transformation or analyses on content. Sourcing that content as HTML requires the developers of these systems to jump through way more hoops than they would otherwise have to, since HTML processing is typically fairly difficult in a headless environment.

So I can't follow your argument that HTML is the best choice for sharing data. I'm almost convinced that you're actually making a joke, trying to convince people that you are serious! :-)

You already have to worry about my (when I say "my" here I mean an API provider) formatting and deal with my changes in the JSON or proprietary XML cases. I can change those just as easily as I can change the html that I produce. The difference is that if I always produce html, and you don't modify it, you can at least be sure that *something* will render. If I change my xml or json format under your nose, your use of my api will probably break.

If you don't like my html you don't have to send it to your clients' browsers. You can manipulate it how you want. But then you have to do that with XML or JSON too. In fact you are required to since you can't display them as XML or JSON.

I can't say I'm not crazy, but I'm not really joking, nor do I think I am alone. My guess is that you may not understand what I mean by semantic html. Wikipedia can explain that better than I.

Thinking it through a little further, it occurs to me that "well-formed semantic HTML" is simply a special case of using XML for data exchange. So, in essence, you are actually arguing in favor of using XML. ;-)

Yeah, you win! There will be a little something extra in your paycheck this week. But it's better than just using XML because it's not proprietary, or at the least not *as* proprietary and browsers know how to do something with it.

I think you may be misusing the term "proprietary". XML is certainly not a proprietary technology, nor is JSON. Perhaps what you mean is "application-specific".

Either way, you run into the same issue with HTML - this site's content is formatted in an application-specific way, just as a hypothetical XML feed containing the same data might be. I would still need to write logic that is specific to this site in order to process it.

So let's look at a simple example. Let's say I want to write a service that provides access to contact information. I can easily envision how that data might be represented in JSON, or even XML. How would you do it in HTML? There's no "firstName", "lastName", etc. tag. You'd have to hijack some other tag and attach additional markup to it so that a caller would know that, rather than <td>, you actually mean "firstName". In JSON or XML, I can just use the purely semantic "firstName". Much more intutive, much easier to read, and much easier to process.

Fair enough, application specific then, but you obviously took my meaning. You say, "I would still need to write logic...". I say in the semantic html case "I might not need to write logic..." and in the application-specific xml or json case "I am required to write logic...". The difference between "might not need to" and "am required to" can be huge and is certainly reason to use semantic html as opposed to xml assuming I want to maximize the usefulness of my API.

As for your example, the answer is easy. I would use the hCard microformat. Take a look at how they model your exact example in html. One advantage that accrues magically is that other people know about hCard and can do things with it without any prior knowledge of your API. For example Firefox extensions like Operator. It costs a site developer very little to mark up contact data this way. 

Simple and to the point. You read my mind (or my article): it's not only true for XML vs Jason but you can generalize for TechX vs TechY.

When you hold a hammer, everything looks like a nail!