Celebrate the XML Decade

IdaAshley writes "IBM Systems Journal recently published an issue dedicated to XML's 10th anniversary. Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML. Learn why XML has been successful, and what it would take for XML to continue its success."

Re:Celebrate the XML Decade

Celebrate the XML Decade

I tried. Oh Lord, how I tried!

I started this morning by talking to everyone in XML.

I hope the black eye my coworker gave me heals before my presentation to the CTO tomorrow morning :-(

Re:Celebrate the XML Decade

Really...

We all needed to leave the first post in this to the guy with
the sig

"XML is like violence, if it doenst fix the problem, you arent using enough"

Or words to that effect.

Re:Celebrate the XML Decade

Someone put that in our Bugzilla quips a while back - it's still one of my favorites!

My conspiracy theory is that XML was secretly invented by Intel in order to require 3GHz processors for the simplest of tasks.

Re:Celebrate the XML Decade

I started this morning by talking to everyone in XML.

<conversation>
<greeting type="friendly">Hello, fellow coworker type dude!</greeting>
<response type="violent">Have a black eye!</response>
</conversation>

Re:Celebrate the XML Decade

<greeting type="friendly">Hello, fellow coworker type dude!</greeting>

That's a poorly designed format. You should make "greeting" a complex type and use elements to represent the greeting text and the greeting type. Then, the greeting type can be properly validated against a W3C XML Schema. There's no valid reason to use an attribute in cases like these.

Re:Celebrate the XML Decade

That's a poorly designed format. You should make "greeting" a complex type and use elements to represent the greeting text and the greeting type. Then, the greeting type can be properly validated against a W3C XML Schema. There's no valid reason to use an attribute in cases like these.

I took the liberty of revising the format a little, is this better?

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<conversation
xmlns="http://slashdot.org/sarcasm/XML/conversatio n"
xmlns:html="http://www.w3.org/1999/xhtml">

<participants>
<participant>
<short-name>OP</short-name>
<full-name>Original poster</full-name>
</participant>
<participant>
<short-name>CW</short-name>
<full-name>Unwitting coworker</full-name>
</participant>
</participants>

<relationships>
<two-way-relationship name="coworker">
<person>OP</person>
<person>CW</person>
</two-way-relationship>
</relationships>

<greeting time="2006-11-17T10:12:10Z" speaker="OP" targets="CW">
<type>
<demeanour>friendly</demeanour>
</type>
<speech>
<text type="text/plain">
Hello, fellow coworker type dude!
</text>
</speech>
</greeting>

<response time="2006-11-17T10:12:34Z" speaker="CW" targets="OP">
<type>
<demeanour>angry</demeanour>
<context>
<divorce type="messy"/>
<custody-battle type="messy"/>
</context>
</type>
<speech>
<text type="application/xhtml+xml">
Have a <html:em>black eye</html:em>!
</text>
</speech>
<action>
<punch>
<recipient>OP</recipient>
<aim>eye</aim>
</punch>
</action>
</response>

</conversation>

I'm sort of disappointed that I only got to use two namespaces. Can't get indentation to work either, unfortunately.

Half-Life 7?

From TFA:

It goes on to give HL7 as an example of such a modeling approach.

Wow, they really do think XML has staying power! By my count Half-Life 7 is due to land sometime 2097...

Why XML was successful

Marketing to PHBs, mostly.

However here on earth a lot of people still hand-code the stuff. IMO a C-like syntax using nested {}s would've been better.

Re:Why XML was successful

"IMO a C-like syntax using nested {}s would've been better."

JSON [wikipedia.org]?

Re:Why XML was successful

A lot of people ask about using a different syntax, such as @name{....} as Scribe (and later LaTeX) did. Note that @element{xxx} is in fact a possible syntax that can be defined using SGML. But we were after something different.

When we designed XML, we had over a decade of solid experience with interoperability in the world of SGML, and we also knew about the kinds of problems that different sorts of users had with different sorts of syntax.

The primary users of SGML-based documentation systems were not programmers. They were people who were often not likely to know about a bracket-matching option in an editor or about code indenting, for example. But they were still legitimate users.

You can't easily test the markup in a declarative system: if in an HTML document I used H3 instead of P in a document it might not look right, but it would still parse OK. If I muddle up Author and Title in a bibliography, same thing.

So, the redundancy of end tags in XML is there because, in practice, if you didn't have it, we had learned that our users had problems correcting their documents, and we knew that, in general, it was only rarely possible for software to give the users much help. There were some experiments early on with </>, allowed by SGML (with various options set) to end any element; it soon became obvious that this caused more problems than it was worth, and even Microsoft disabled the troublesome feature in their XML parser.

It's true that today XML is used in lots of situations we didn't predict. We were amazed that by the time we got XML published as a Recommendation there were over 200 users. So no, we didn't predict the future percfectly. But the popularity of XML shows we can't have done all that badly, really ;-)

Liam

(Liam Quin, currently W3C XML Activity Lead)

Re:Why XML was successful

> The error message does not help people all that much

One case where it helps most is when an incorrect start tag was applied; with the empty end tag this could not be detected, and it turned out to be more comman than one might expect. You're right that the error messages often aren't good, but did you ever try debugging a large SGML document with OMITTAG and SHORTREF in use? The error message was almost always "characters found after end of document" because the required strategy by SGML (in one of the most common error situations) was to close elements until you got a match, so the parser typically closed elements all the way up the tree to the document element, and then gave up.

We were bound, at the time, to strict SGML compatibility; perhaps if we had known XML would succeed we could have made more changes, but then we would have strayed further from the well-trodden path of implementation experience.

As to comments for attributes, I agree with you; we lost them, though because we needed a language simple enough it could be processed e.g. with Perl. We didn't dare dream that Perl would support XML natively!

I agree with you that structured tools should generally be used. The redundancy and simplicity help computer-generated XML, and help to detect, say, missing portions of documents. If xml-rpc is scary, s-expr rpc is even scarier! :-)

Liam

Re:Why XML was successful

Sorta... XML came at a time when there weren't a whole lot of good viable data representation standards. Those that did (i.e. SGML) were too complicated for light use. XML was meant to be used by the masses while still technically remain an SGML subset. We have better alternatives today, but once something is in widespread use, it's not going away for awhile.

Re:Why XML was successful

A curly brace syntax would have been a better format for "large scale enterprise publishing"? As someone who has spent more than a decade in that field, I must disagree strongly. A curly brace would have been better to allow enable generic SGML to be served, received, and processed on the Web in the way that is now possible with HTML. [w3.org] Please do not confuse what XML is used for with what it was designed for. There is a reason that XML delivery units are called "documents" and not "messages".

Unfortunately I'm a Java developer...

... and most "enterprisey" Java developers have never met a problem that couldn't be fixed with more XML.

Re:Unfortunately I'm a Java developer...

My bosses were wary when I suggested XML as our data representation for a new project. Here were some of the arguments:

Pro

• Easy to change the schema, don't have to convert old data.
• They didn't know exactly what XML was, so if I recommended it, ... (a.k.a. "gee whiz" factor?)
• The other developers liked the idea

Con

• They weren't sure whether this would increase (better system = save time?) or decrease (reinvent the wheel = waste a lot of time in meetings?) productivity
• Takes lots of space (no "binary XML")
• Slow processing, right? (see "Takes lots of space")

Eventually we settled on gzipped xml. It required a little more code, but everyone seemed happy. Oh, and we stored images as separate .png.

I think my experience is pretty common, though. And from experience, libxml2 + libz is still very, very fast, and there's not a (whole lot) of wasted space.

I'd like to hear other people's success stories, if anyone wants to reply... I liked reading the article, too.

Re:Unfortunately I'm a Java developer...

The "slow processing" is caused by more than taking a lot of space. XML is basically a document markup but is frequently and regular used as a wire protocol, which has very different design requirements if you want a good standard. And in fact we already have a good standard for this kind of thing called "ASN.1", which was actually engineered to be extremely efficient as a wire protocol standard. (There is also an ITU standard for encoding XML as ASN.1 called XER, which solves many of the performance problems.)

Arguably the single biggest problem with XML that causes slow processing is that software can predict almost nothing about an XML stream and therefore has to allow for anything. The opening bracket tells you very little about what to expect, and creates few implicit failure or non-conformance tests that allows one to terminate processing because there is no definition of "unreasonable". If I want to embed a terabyte of data between XML tags, there is no built-in basic mechanism to inform the software of how much data I should expect to see before a closing tag and no basic mechanism to cue the software as to the type of data to expect. (Yes, you can sort of do it with lots of other layers strapped on, but it isn't core and strapping it on adds complexity.) This is the primary reason it gives miserable performance as a wire protocol format -- the software cannot make decisions about the data without slurping most or all of it, with no way to predict what "most" or "all" actually is. In well engineered standards such as ASN.1, they use the good old tag-length-value (TLV) format. The "tag" tells you what to expect, the length tells you how many bytes to expect, and the value is the actual data. In short, the encoding tells the software exactly what it is about to do before it does it in enough detail that the software can make smart and performant handling decisions.

The only real advantage XML has is that it is (sort of) human readable. Raw TLV formatted documents are a bit opaque, but they can be trivially converted into an XML-like format with no loss (and back) without giving software parsers headaches. There is buckets of irony that the deficiencies of XML are being fixed by essentially converting it to ASN.1 style formats so that machines can parse them with maximum efficiency. Yet another case of computer science history repeating itself. XML is not useful for much more than a presentation layer, and the fact that it is often treated as far more is ridiculous.

Just in time for the festive season

This year I'll be sending out christmas cards in XML and then placing a large banner outside my house with the appropriate schema.

Then with every following year, I'll be sending a stylesheet card which they can apply to the original XML.

And if they need to locate their names on the card, they can use //recipient[@name='mum']

No mention of XML's creators?

Strange that an article celebrating XML [w3.org]'s anniversary would neglect to mention XML's creator [tbray.org]. I wonder if the fact he works for a competitor [sun.com] has anything to do with it...

Re:No mention of XML's creators?

I have to do this once per year or so, here's the 2006 iteration: I am not XML's inventor. There were 150 people in the debating society and 11 people in the voting cabal and 3 co-editors of the spec. Of the core group, I (a) was the loudest mouth, (b) was independent so I didn't have to get PR clearance to talk, and (c) don't mind marketing work.
-Tim

Don't feel too bad, Tim

Al Gore declaims the same every anniversary of the Internet.

A decade of bloat.

All we can celebrate is a decade of bloat. For hard drive manufacturers and bandwidth providers, this has been a great development. But for those of us who have to deal with systems that use XML, we often wish that they had chosen a far more compact representation.

S-expressions, of the sort used in Common Lisp and Scheme, would have been a good alternative. They're simple, use a minimal number of characters, and are very easy to parse. Hell, most Comp Sci grads have written at least once such parser during their education.

The worst use has perhaps been with AJAX. Had AJAX been based around data passed as sexprs rather than as XML, it would consume much less bandwidth, and could be handled far quicker on the server side. Unfortunately, a poor technical decision was made to use XML. And so we get to hear all about the performance problems people experience with AJAX systems.

Re:JSON itself is still quite bloated.

Not all XML is readable by humans.

The formatting strings in Janus controls come to mind.

I have heard that the new Office format (XML) was pretty unreadable.

And what is with modding everything in this thread to zero.

news flash

Take a look at XML application techniques, and general discussion of the technical, economic and even cultural effects of XML.

Cultural Effects? This is a spec for structuring data, not a Picasso.

XML Decade?

Wait... let me figure this one out...

MCMXC was 1990...
MDCCCLX was 1860...

I give up! Which decade was XML?

- RG>

So where is this old chestnut?

I don't know the origin of the saying but it brings to mind something I use when discussing the subject with customer architects:

XML is like violence. If it doesn't work, you're not using enough of it.

If anyone can come up with the true source of this -- or the accurate quote -- I'd appreciate it.

XML is what it is

Can we forget the hype, can we forget the PHBs, can we forget all the nonsense?

XML has a purpose, combined with expat, it is a convenient, if inefficient, method by which programs can exchange data relatively easily.

I am not an XML fan, by any means, but if absolute efficiency is not important, XML provides a common format for data exchange.

Stuck

So we're officially stuck with this crap forever.

Yay! Lets party!

XML is for data interchange, nothing else. Unfortunately, it's being used for everything but.

Longevity

What XML needs now is a standardized (even ad hoc) format for Binary XML. XML is such a verbose format...

just plain wrong

Apple replacing the perfectly fine, hand editable plist format with an XML version. ick.

a decade of ...

vague semantics, confusing specifications, unwarranted complexity, standards proliferation, poor tools, and wildly inappropriate application. Not to mention rampant disregard for existing work in nearly every arena it entered. So the essence of XML is this: the problem it solves is not hard, and it does not solve the problem well. [bell-labs.com]

Obligatory link

To the Parable of the Languages [burningbird.net]

What about me, said C#. I look like Prince!

Bite me! said C.

(I did a quick scan of the replies for the link and didn't find it, so mod me redundant if need be)

notice too late

Celebrate the XML Decade:

Bah, it's too late to tell us to celebrate during the decade of XML because that decade is now over!

Yeah, should have done that; celebrating.

Significant technical victory

XML has won a significant technical victory. It has managed to stand firm in the face of the relentless onslaught of doubling processor speeds and memory capacities, so that our word processors are just as slow and bloated as they were a decade ago. Outstanding! Yay for XML!

Ten years of XML ...

Ten years of XML ... and here I am relearning TeX.

L

XML: the CSV of Y2K

Just as blogs are the personal homepages of the new millenium.

Can someone explain why I should care?

I see XML as a glorified CSV file. Instead of being a two-dimensional representation of a data structure, you can use an N-dimensional representation.

If that's all it was, I wouldn't mind. But it gets so much hype. Why?

Celebrate?

We must not be thinking of the same XML.

XML is a nescessary evil...

XML is a nescessary evil. Even though it's slow and inefficent, it's a good system for quickly developing a parser for varied file types without having to design an editor.

Acedemicly-pure XML is just needless overkill, IMO.

Re:XML's Existing

<?xml version="1.0"?>
<content name="Shameless Self Promotion">

Good point, though there's a better way to edit binary files.

For example, I make a product called FileCarver which allows you to create a file format definition (in XML! heh), that describes the format of a binary file, and the program will automatically provide you with a GUI to edit it. Check it out at http:/fizzysoft.net/filecarver/

</content>

Re:XML "Sucks"

When does a broken link constitute "Informative"?

Re:XML "Sucks"

This is slashdot. Nobody reads the links.

Re:XML -- The answer to a problem that didn't exis

You are trolling, right? Your rant basically consists of few obvious misunderstandings or statements that are factually wrong.

Seems like a knee-jerk reaction from someone who doesn't understand what XML is and its intended purpose. Seeing the HTML remark was rather amusing though. Way to go to show your ignorance on the subject.

BTW: XML is not designed to or intended to be a SQL replacement. Only morons would think that, claim that or use it as such.

Re:XML "Sucks"

Here [rants.org] is a more accessible opinion about XML.