Why XML Doesn't Suck

Richard Eriksson writes "Recalling the earlier discussion on why XML sucks for programmers, Tim Bray clarifies his stance on his co-creation, XML, and gets back on his pulpit to declare that XML Doesn't Suck. He writes: 'Let's look at some of XML's chief virtues, then I'll address some of the XML-sucks arguments, in the same spirit that Sammy Sosa addresses a fastball.'"

Comments

I DO hate XML

[ruiner13]

I have to write SOAP calls for our .NET website, and i'll be damned if XML isn't the most irritating language ever. It wouldn't be so bad if everyone could agree on syntax, but since XML is so vague of a language for every implementation there is a different syntax, even amongst the SOAP standard XML specs. I am currently working on hafing our website make a SOAP call to a PERL::Lite SOAP server, and can't get the .NET to get the right data out of the response, even though the Perl server understands the .NET request fine, and is sending the right response. If it was really the panacea for programmers, there would be no interoperability problems. Sure, a human can look at any XML schema and know what is going on, but computers are the ones who have to deal with it, and they seem to have problems frequently.

Just my 2 cents.

Re:I DO hate XML

[Mr. McGibby]

You make a good point, but don't go far enough.

I think the original poster's point was that XML allows for so much abiguousness, that every tool seems to do it differently and none of them can understand each other. The standard should be so strict as to *require* that if the same representation of a "piece of data" is made by two different tools, the representation should be exactly the same. No reason to say, "oh, you can put an endline there if you want, or you can end a tag these two different ways, whatever suits your fancy.

Sure, the tools should have been written so that they all followed whatever standard is out there, but we all know that that doesn't happen. The standard should *force* the tool writer to be anal about the standard and follow all the conventions.

A good compiler should do as good a job as possible to warn you of errors, before they become runtime errors (because those are harder to find). In the same way, a language should be designed such that more errors are compiler than run-time. In the same way, a standard should nearly impossible to create a file that doesn't follow the standard perfectly and still work. XML folks actually tout the opposite as a benefit!

A tool is written and most of the time is tested with itself, and thus *seems* to work, but doesn't really.

XML Confers Longevity

[Spudnuts]

Mr. Bray makes a point about the longevity of XML based documents (where he says that tying up documents in a binary format is foolish), but this is a point that (La)TeX users have been arguing for years.

Will XML really solve this problem? Hopefully the OpenOffice format will help, but if Microsoft maintains its marketshare (and keeps its XML generation limited or even proprietary), are we really better off?

I'll just stick with LaTeX.

basically why it doesn't suck

[xagon7]

I havn't read the article yet, but XML does NOT suck because:

1. the data and/or fields added at anytime WITHOUT breaking anything

2. the data is in a heiracherical format, reducing data replication and allowing for a more sophisticated data structure.

3. the daya can be changed by a text editor.

4. and BECAUSE the data is text, it compresses REALLY well.

What's the big deal?

[Telex4]

I don't get all this fuss over XML. It seems to me that it's just a pretty handy markup language for programmers to use to store data in a human-readable (and therefore human-editable) fashion, that (with the help of things like libxml) also happens to be fairly machine readable. It's also extensible (X- duh!) and yet also has its limits.

Why are there so many /. stories about this? Can somebody explain why this raises people's passions so? It seems to me like arguing the merits of HTML or SGML - it's all so bloody obvious!

I agree, XML does not suck

[dsoltesz]

As a web developer & admin, XML is my best friend. I have cases where I need non-webheads to develop content (better yet, portable content), and XML is the only way - they only have to know a basic set of HTML tags, they don't have to worry about HTML validation, formatting, or anything else, and everything they generate is consistent!

Not ony can I transform their content into different views or formats, but (for example) the same XML file that is used to provide software documentation also is used to build the software GUI and provide tool tips and other forms of context sensitive help.

No database required. No parsing required. Just a couple libraries and tools, and we're set to go.

Code embedded in XML

[CyberGarp]

I saw a letter to Dr. Dobbs recently that was saying that XML needed to have the ability to embed things like Visual Basic and javascript in it to be really useful. I think that this is a horrible idea. The whole point of XML was to have a generic data model, i.e. one parser to rule them all.

I've been able to do thing like export MySQL schemas into XML, then using XSLT generate an entire set of base classes providing persistent objects. What was once weeks worth of work, now takes an afternoon (from concept to final product). The whole set is entirely consistent, no misspelled names or changed signatures. When bugs were found, I fixed all the files in one place and rerun the XML/XSLT script. Massive productivity boost. If that isn't an argument on why XML doesn't suck I don't know what is.

The idea of embedding code in XML is a perverse distortion of what XML is really about. XML would suck if one uses it for unintended purposes. I don't use a hammer to tighten machine bolts, well I guess some people do.

Electronic Data Interchange (EDI)

[Anonymous Coward]

I work for a VAN (Value Added Network) which is basically a middleman for data. You send an electronic purchase order to us; the company you're ordering from gets it from us. The value we add is we'll say you sent and tell you they got it.

However, we charge by the kilocharacter of data you send and receive per month. So, for us, XML is awesome, because it increases the size of an ASCII-X12 or EDIFACT document by a factor of 5-a lot more (usually somewhere around 15-20 I think).

X12 and EDIFACT are standards for business document exchange that have been around for a while, but people are converting to XML because they think it's better (eventhough, usually, they just use the X12 or EDIFACT format, but with XML tags).

For example, a line item record may go from something like this:

LIN:0001

to something like this:

<LIN_GROUP>
<LIN>
<LIN_01>0001</LIN_01>
</LIN>
</LIN_GROUP>

It's not always that bad, but it can also be much worse. (Imagine replacing each instance of "LIN" above with "Line_Item" and "LIN_01" with "Line_Item_Number".) (And why won't that semi-colon after the LIN_01 end tag go away?)

so-- for us, XML doesn't suck-- it increases our revenue. For our clients, it's sucks, because it increases their monthly bill.