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."

Comments

Re:Celebrate the XML Decade

[eldavojohn]

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 :-(

Half-Life 7?

[PriyanPhoenix]

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...

Re:Half-Life 7?

[Anonymous Coward]

HL7 is a "standard" for moving patient information from system to system. I call it a "standard" because the 1.x and 2.x versions were largely "advisory", with more MAY than MUST, with a huge amount of wiggle room... I've worked on 4 information exchange projects now, and all of them started from scratch because none of their HL7 "specs" are compatible.

Supposedly the new version 3 standard (which uses the "modeling approach") will be much more firm with the implementors, which will hopefully mean that every now and then one implementation will actually be compatible with another implementation. I've looked over their "models" and they've modelled a lot of the business use-case stuff for patient data, but not a lot of the actual data itself. Hopefully when it's done, it'll come out a bit better baked than previous versions.

Re:Half-Life 7?

[suggsjc]

You must be in the medical industry...

We run across the same problems for every interface we set up as well. But the reason usually isn't that the base format isn't different (although that does occur). It usually arises from one company wanting some arbitrary piece of data that the official "spec" didn't outline in all of its loosey-goosey glory.

We are hopeful that v3 is going to solve some of the minor issues, but they just better not get too overzealous and not leave room for the "unexpected." However, it is going to take some major players to adopt the new format before it picks up any steam since it is such a large departure from the previous two major versions. Small to medium sized businesses aren't going to spend the development/research time to implement it until it starts affecting bottom line. I'm guessing at least 3-5 years before that happens.

Why XML was successful

[Ant P.]

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

[MP3Chuck]

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

JSON?

Re:Why XML was successful

[porkThreeWays]

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

[CaptainPinko]

I keep hearing this and it sees foolish every time. If you just used {} how would you easily tell which tag you were closing? It would be too easy to mistake one brace for another, especially when there are several tags. Sure it'd be more efficient: but the idea was to have something that was equally readable by machines and humans. You take any non-trivial piece of XHTML or other XML and convert it to your new {} syntax. Then go try to add some more mark-up to it. And to non-technical users it would be even more confusing. At my work developers send XML for our business analysts to confirm the output. The only thing I have a qualm with in XML is the use of different >??< >!< tags.

And to another posters complaint about JEE and an over alliance: if you've got meta-data already and are going need a text file isn't it best to have a consist industry-standard mark-up between them? The whole point of meta-data is not to have content outside of code. If you don't want to have content outside of code then just avoid using those systems like Spring. In JEE aside from your web.xml you don't need any at all.

Re:Why XML was successful

[theodicey]

It would be too easy to mistake one brace for another, especially when there are several tags

I hack LISP, you insensitive clod!

Re:Why XML was successful

[Ant P.]

People seem to have coped fine reading code without closing tags for the past 30 years.

Re:Why XML was successful

[smallpaul]

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. 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".

Re:Why XML was successful

[binaryloc]

Agreed, alot of the new markup-oriented languages really get on my nerves. Worse is the dream weaver groupies who 'use' them

Re:Why XML was successful

[Anonymous Coward]

The problem with } to close nodes is that you can't see which element you're closing, which XML does specify.

Re:Why XML was successful

[Anonymous Coward]

And if anyone's under any illusion that JSON isn't try to reimplement XML I'd like to introduce you to JsonT... JSON Transformations.

Re:Why XML was successful

[Ankh]

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

[Anonymous Coward]

Separating out human-readableness is fine in theory, but in practice having the lowest-level data in an easy-to-read format proves invaluable from time to time.

Developing a widget that connects to another XML-spewing widget using an XML-reader is all well and good when everyone behaves. But more often than should happen, the other widget uses some syntax or formatting that's improper XML or your XML-reader-editor can't handle a particular case it uses. Yes, in a perfect world, both of these would follow the standard perfectly and you'd never have to look at the formatting, but when I'm getting paid to code, I often don't have the time or access to the source code to make everything else perfect, and just need to make my code work. If that means relying on notepad on a client's computer, XML's human readability becomes more valuable to me than any presentation-encoding separation.

-TheJorge, posting AC from a friend's computer because firefox saved my password long ago and I can't remember it...

Re:Why XML was successful

[thsths]

> 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.

Given my experience with users that have inadequate support in their editor for structured documents, having the redundancy actually does not help. Sure, you get an error message instead of accidentally specifying something you did not wont, but the error message does not help people all that much. So they still stare at the XML and don't get what is wrong.

Allowing comments within an element (for each attribute) would have been a huge contribution to legibility. Of course that depends on how you use it, but I think attributes get a lot of use exactly because they have less redundancy.

My conclusion is that in the end, you need structured tools for structured data. And so the format does not actually have to be easy to read. (And believe me, even the best of XML documents are not easy to read if the structure is reasonably complicated.)

Re:Why XML was successful

[Anonymous Coward]

So your argument is it is good that XML has a verbose and complex syntax, because sometimes you need to debug components that have trouble writing or reading such a verbose and complex syntax?

You don't think that perhaps if those components could communicate in a simpler syntax, you wouldn't need to debug them?

Re:Why XML was successful

[Carewolf]

You know there is an entire programming language designed to manipulate JSON datastructures, a language that quickly pentrating all of the web.

It is known as: JavaScript

Re:Why XML was successful

[Raenex]

What are the better alternatives?

Re:Why XML was successful

[master_p]

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.

WTF? So just because some users couldn't figure out how to turn on parenthesis or bracket matching in their products, you ended up with the mess that is XML?

There you have it people, straight for the horse's mouth: our civilization is actually based on random poorly thought-out decisions made by a few almost-ignorant fellows.

If we take into account how lame most of the software products are, (for example: how many holes there are in C-based apps, how lame XML is, how horrible WIN32 is, how bad socket APIs are, how complex J2EE is etc), then we ought to be ashamed of ourselves as humanity...and of course with such badly designed software, the sky is not the limit...

Re:Why XML was successful

[Anonymous Coward]

JSON datastructures... via XMLHttpRequest when all browsers have already parsed it into an XML Document. So basically what JSON gets you is object serialization/deserialization -- a nicer API to copy details out of. XML's equivalent is E4X, or any of the wrapper libraries that allow XPath to object hierarchy mapping, and they can be used for innerHTML and other uses unlike JSON. JSON is good for object mapping, but that's only a small part of AJAX/XMLHttpRequest

Re:Why XML was successful

[Decaff]

We have better alternatives today

Such as?

Re:Why XML was successful

[Decaff]

So your argument is it is good that XML has a verbose and complex syntax, because sometimes you need to debug components that have trouble writing or reading such a verbose and complex syntax?

"Complex and verbose?"

Verbose, yes, but "complex"? Are you kidding? XML is one of the easiest formats to read, and was designed as such.

Re:Why XML was successful

[Decaff]

Marketing to PHBs, mostly.

Yes, because only PHBs would be interested in portable data that can be easily transformed, and have new formats added without losing old data.

I mean, developers would never want that, would then?

Re:Why XML was successful

[Eivind Eklund]

XML is shitty to deal with because it separate "attributes" and "elements". Avoid attributes. They are an abomination unto Nuggan. Oh, and I'd also like back references and a simpler format - but then again, I'd end up with YAML and could just as well just ditch the XML.

Eivind.

Re:Why XML was successful

[Decaff]

Attributes are useful because they allow extremely varied information at the same 'level'. For example, properties of fonts in a paragraph. You could handle this all by nested tags, but it would be extremely verbose. Attributes also make searching for particular types of data using techniques such as XPATH far more concise and meaningful.

Also, attributes aren't compulsory. If you don't want to use them in your XML format, there is nothing making you.

YAML falls into exactly the kind of traps that XML was designed to avoid. Indentation is great for programming, but awful for data; compulsory whitespace leads to all kinds of issues such as having to handle different line terminators, and having to distinguish tabs from spaces. YAML is also not easily transformable: take out a section of a YAML file and it need changing before it can stand-alone - it has a level of embedding that indicates it came from elsewhere (this sounds trivial, but it indicates a lack of design). YAML is also clumsy for very large data sets.

XML is based on a huge amount of experience of what can go wrong with data formats. YAML is retrograde.

Re:Why XML was successful

[Eivind Eklund]

YAML does not allow tabs, and I've not found the end of line issue to be a real issue the last decade. It was a pain back in the early 90s. I can also never remember having had any benefit from the ability to cut out a piece of XML and use it outside its scope - so this doesn't seem to happen much in practice.

Next, your arguments around attributes seems to also be clutching at straws. Let me shoot them down for you:

(A) If I am to use XML where XML is appropriate - that is, for the interchange of data - I can't avoid attributes because *other people are using them*. (B) Your attempt at arguing about screwups with tabs/newlines are shot down by yourself, as you then argue in favour of the messups that come from distinguishing between elements and attributes,(C) The verbosity argument is void - this does NOT argue for attributes, only that elements should be possible to write as attribute syntax.

Do you happen to have a large investment in XML? If so, you should think carefully through how much you are letting that cloud your judgment - because it seems like it is. (I work with XML and also with other technologies, and I don't let my investment stop me from seeing the flaws. There are flaws in everything, yet XML is one of the worst of the bunch, IMO.)

Eivind.

Re:Why XML was successful

[Decaff]

I can also never remember having had any benefit from the ability to cut out a piece of XML and use it outside its scope - so this doesn't seem to happen much in practice.

Why extrapolate your experience to everyone else?

(A) If I am to use XML where XML is appropriate - that is, for the interchange of data

No, that is not the main point of XML. One of the driving purposes behind XML was to overcome a major problem in IT - legacy data becoming unusable. In the 90s, at the time when XML was invented, there were considerable problems with old undocumented text and binary data which became useless because the software that knew how to read it was either no longer available or would not run on current hardware and systems. XML adapted a document markup and archival format SGML, in order to allow easier processing by software and to improve human readability. In 20 years you will be able to open an XML file written now (such as OpenDocument format) and will be able to, at the very least, read what it means on paper. XML is designed to be a format for data storage and archival - using it only for data transfer is not seeing the 'main picture'.

- I can't avoid attributes because *other people are using them*.

Of course you can. XML is easily transformable - that is one of its major benefits. You can use XSLT to transfer your attribute-free format to one with attributes. You can also embed (if necessary) your format in other's formats with namespaces.

(B) Your attempt at arguing about screwups with tabs/newlines are shot down by yourself, as you then argue in favour of the messups that come from distinguishing between elements and attributes,

No, because they aren't the same issue. Tabs and newlines aren't appropriate as part of robust data format because you may need to embed (in a portable way) such whitespace. XML has this facility using CCDATA. Positional and white-spaced data formats should, by now, be ancient history. White space has no intrinsic meaning! Well written tag and attributes names do.

(C) The verbosity argument is void - this does NOT argue for attributes, only that elements should be possible to write as attribute syntax.

So you might as well use attributes.

Do you happen to have a large investment in XML? If so, you should think carefully through how much you are letting that cloud your judgment - because it seems like it is. (I work with XML and also with other technologies, and I don't let my investment stop me from seeing the flaws. There are flaws in everything, yet XML is one of the worst of the bunch, IMO.)

Ah right. So anyone who disagrees with you must either have a large investment in XML, and must have clouded judgement. Way to argue!

I don't have any particular investment in XML. What I do have is 30 years experience in IT, and I have come across all of the issues I have mentioned, and have spent considerable amounts of time dealing with 'yet another' data format. I could expound in detail the problems with different versions of Fortran data output and tracing bugs in Makefiles and so on... XML has been a major time-and-expense saver, not IMO, but FMAE (From My Actual Experience).

Re:Why XML was successful

[Decaff]

YAML does not allow tabs, and I've not found the end of line issue to be a real issue the last decade. It was a pain back in the early 90s. I can also never remember having had any benefit from the ability to cut out a piece of XML and use it outside its scope - so this doesn't seem to happen much in practice.

Let me give you some actual examples of when this is used. In many commercial production systems products have information associated with them as they progress through the various processes. For example, a piece of equipment may have material analyses and quality checks. The problem before XML is that all the different processes were used different manufacturers' equipment and software, each of which would produce their report in a different format - some binary, some CSV, some text. Managing this information can be a real problem.

Then, along comes XML. Each manufacturer supplies their information as a fragment of XML, with their own namespace. This means that the final report is a single XML document with all the different reports embedded. The entire report can be parsed, validated and processed using the same software, and easily transformed into different formats for printing (say RTF or PDF) using standard, even free, software.

XML is also great for document formats - embedded XML fragments can be ignored by the main document processor, but recognised by other software to help render things.

Re:Why XML was successful

[Eivind Eklund]

Ah right. So anyone who disagrees with you must either have a large investment in XML, and must have clouded judgement. Way to argue!;/i>

Your attempt at mindreading failed, another cloud. I am stating my evaluation of how you argue: With clouded judgment. I am guessing this clouded judgment comes from having spent significant time on XML, and thus having an investment in it. You are arguing that both ways: You claim to have no investment and then start trying to get authority by referring to your experience with it. (I've got about 5/6ths as much IT experience as you, BTW, and while I've come across all those problems, I have also come across various other solutions to the structured data problem than XML, including the very nice standardized formats on the Amiga.)

To keep cutting down your arguments (though I'm not sure why I bother - I don't think you're going to dare to pull away your investment and see the flaws in XML anyway):

Your examples of XML application does not argue for cut/paste at all; it's processing done by a machine. I am in favour of having a standard, structured text format we can process - I just think XML is a horrible choice. It's bloated, denormalized for a proper hierarchy by the utterly arbitrary inclusion of attributes, and then, to add insult to injury, it can't represent graphs.

An utter arbitrary decision where you obviously do not get the arguments against it, and assume that you are supposed to argue in favour rather than try to understand the arguments. The argument is very simple: This introduce random denormalizing garbage into the format, instead of having a simple hierarchy. This complicates data structure consumers and it complicates data structure generators (adding noise to them) without, as far as I can tell, any benefits.

As for "actual experience showing benefits", I've got actual experience with XML messing things up. Most of the places where I come across it, it's the wrong thing for that application. It is used for configuration files, programming languages, and serialization. None of which it is a good choice for.

And to just deal with the last thing: Of course you can. XML is easily transformable - that is one of its major benefits. You can use XSLT to transfer your attribute-free format to one with attributes. You can also embed (if necessary) your format in other's formats with namespaces.

Adding one more layer of indirection is usually just asking for trouble. Doing this because XML has flaws in its design is usually stupid, especially as you can't guarantee trivial transformations due to that brokenness. So, no, I cannot avoid the fallout from that design mistake. Either I take the fallout in the form of adding more indirection, implementing the code for that indreiction, not being able to use the present documentation, etc - or I take the fallout in the form of having to deal with arbitrary noise being thrown into the data formats.

And no matter where I stand, I often have to debug other people's code. Where they have NOT thought that clearly around this - which is obvious, given that even you, with 30 years of experience in various formats including XML, do not get the point on the first explanation. Hopefully, you got it now.

Eivind.

Re:Why XML was successful

[carpeweb]

Based on the discussion that followed, how is this flamebait??

Mod parent back up to at least normal and hopefully higher. And metamod the modder down!

Re:Why XML was successful

[Decaff]

You are arguing that both ways: You claim to have no investment and then start trying to get authority by referring to your experience with it.

Sorry, this makes no sense. Having experience in something does not mean I have investment in that thing. I have been using Microsoft products since the 70s, but I have no loyalty or investment in them! However, I certainly consider myself an authority on many of their products, because of my experience.

Adding one more layer of indirection is usually just asking for trouble. Doing this because XML has flaws in its design is usually stupid, especially as you can't guarantee trivial transformations due to that brokenness. So, no, I cannot avoid the fallout from that design mistake. Either I take the fallout in the form of adding more indirection, implementing the code for that indreiction, not being able to use the present documentation, etc - or I take the fallout in the form of having to deal with arbitrary noise being thrown into the data formats.

Indirection != transformation. It is a mapping. One of the great things about XML is the ability to filter out arbtrary noise or transform it to something less noisy.

And no matter where I stand, I often have to debug other people's code. Where they have NOT thought that clearly around this - which is obvious, given that even you, with 30 years of experience in various formats including XML, do not get the point on the first explanation. Hopefully, you got it now.

Well, I thank you for your time and patience in trying to make me 'get it'. Unfortunately, it seems not to have worked :)

I spend a significant amount of time debugging other people's code too, unfortunately. That is precisely why I am so keen on XML, because much of that debugging has involved reverse-engineering undocumented formats.

People will add indirection and mess up ANY data format. This is precisely why having a standard format which is easily transformable and parsable is so vital.

To keep cutting down your arguments (though I'm not sure why I bother - I don't think you're going to dare to pull away your investment and see the flaws in XML anyway):

One good rule about arguing is not to invent characteristics of those you are arguing against. Firstly, you can't tell, unless you have some amazing psychic ability: I know there are faults in XML. In particular the validation languages have been pretty awful (with DTDs being ghastly). But, I see so much discussion that indicates a complete lack of understanding of why XML was invented. Without such understanding the benefits, which hugely outweigh the awfulness, are often not recognised. Secondly, resorting to ad hominem attacks does not help either. Many consider that this in inself is a sign of someone who has significant investment themselves in the point of view they are trying to defend. At the very least, it is a distraction from what might well be good arguments *you* are putting forward.

Your examples of XML application does not argue for cut/paste at all; it's processing done by a machine.

Individuals can do exactly what those machines did in that example. I have seen it done with students inventing their own format for science work (such as molecular models) and embedding that within standard XML document formats, to allow embedded display. Works like a dream!

I am in favour of having a standard, structured text format we can process - I just think XML is a horrible choice. It's bloated, denormalized for a proper hierarchy by the utterly arbitrary inclusion of attributes, and then, to add insult to injury, it can't represent graphs.

(1) Then don't use attributes. You only have to write the XSTL to transform from your attribute-free format to an attribute-based format (or back the other way) once.

(2) Of course it can represent graphs. There are well-established techniques for doing this. RDFis a W3C standard which includes representation of graphs. It is pure XML.

(And I would love to see some major document format using YAML).

Re:Why XML was successful

[Ankh]

> 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

[oohshiny]

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.

If you're going to make claims about the usability of something like XML, you better be able to back them up with user studies. Of course, there are none. But, in fact, you don't even seem to be clear on the concept of what you were optimizing: error rates? user throughput? speed? user satisfaction?

But the popularity of XML shows we can't have done all that badly, really ;-)

Don't kid yourself: XML is popular because it's similar to HTML and because it was associated with some powerful organizations. If it had had to stand on its merits, it would have been laughed at.

Re:Why XML was successful

[Ankh]

Thank you for your kind words :-)

We weren't really aiming at HTML users.

I'm afraid the only useability studies of SGML tools that I saw were not released to the public. At the time I worked for a vendor of SGML-based software (e.g. including an editor, a viewer, a development environment) and it was a matter of great concern to us.

It's possible we could open up the archives of the XML Working Group, but it would mean getting the permission of several hundred people. I'll ask some people at the upcoming XML conference in Boston and try and get a feeling for how hard that would be.

I agree with you that the involvement of Sun, Microsoft, Netscape and others was very helpful. There are, however, other file formats that were around in the past and had similar backing but which failed. Remember ODA? There were also some attempts early on to move the Web to a dialect of RTF, which was also supported by big companies.

Best,

Liam

Re:Why XML was successful

[Anonymous Coward]

I don't do web development or Windows work, so I don't see a lot of "documents" in XML. However I do see XML misused in strange way. On embedded systems, where memory is scarce and processing is slow, XML may be used to store a mere list of file names, or a "key=value" list that is trivial to parse without the overhead of an XML library. I've seen XML used to store project configuration details that is not intended for interchange, is nearly unreadable by humans, and which is useless without the original app (contrary to what I believe was the intent of XML). I've also seen apps with more than one XML library linked in.

I believe there are just a lot of programmers out there for whom XML is their primary tool in their kit, and don't know how to use more appropriate tools when the situation demands it. They have a hammer and all programming tasks look like nails. Maybe this is all a symptom of the "computers are fast and memory is cheap" disease which encourages programmers to be sloppy.

Maybe part of the XML legacy is yet more proof that people will misuse tools they are given. XML has become a checkoff buzzword; an app needs to support XML to make project leaders happy, not because XML is needed.

Re:Why XML was successful

[nuzak]

> So basically what JSON gets you is object serialization/deserialization

Except since it has no concept of a reference type, shared references will be copied and circular references are impossible. JSON is a nice structured data format -- for object mapping, it's simply unsuitable.

Re:Why XML was successful

[nuzak]

> Don't kid yourself: XML is popular because it's similar to HTML

I find it amusing that you're lecturing one of the creators of XML about the finer points of its lineage. SGML was quite successful long before HTML had ever hit the scene. Perhaps you've heard of SGML and a little-known app called FrameMaker that output it? I sure bet he has.

Re:Why XML was successful

[jo42]

INI files you insensitive clod.

Re:Why XML was successful

[oohshiny]

I'm afraid the only useability studies of SGML tools that I saw were not released to the public.

I'm not talking about the usability of SGML tools, I'm talking about the usability of the syntax itself. You claimed that its cumbersome syntax was chosen because people would often have to use it without tools. In order to use that justification, you really need to compare multiple different kinds of syntactic choices experimentally, and you actually have to have some sound criteria to compare it on. Even your observations ("in practice, we learned") are hardly convincing, given that, in practice, people have had no obvious problems with anonymous end tags for the last 30 years, and they continue to be used in almost every new language design other than the XML/HTML/SGML family.

I honestly don't know whether XML is objectively a "good" or "bad" design. My point is: neither do you, since that would take (1) a clear statement of what you're optimizing, and (2) clear experimental evaluations. I think it would be good both for the designers and users of the standard (and most other standards), as well as future standards designers, to keep that in mind.

Anyway, I do appreciate you taking the time to respond; you probably have had more than one unhappy customer.

Re:Why XML was successful

[Ankh]

I should admit that our mandate was to put SGML on the Web, not to make an entirely new syntax; we really didn't expect people to be using what became called XML for anything other than predominantly textual documents. There are, in fact, problems with anonymous end tags for metadata: these are not in general problems for computer programming so much since you can test the code in a way that's often not possible with metadata interchange. Unfortunately, no, I can't give you references for studies that were done (and there were not many such studies that I can recall, although the number was certainly non-zero; the US DoD CALS initiative might have made some public, though, for a starting point if you want to search) in this precise area. As for what we were optimizing, it was pretty clear at the time, but the original central use cases of XML are not really so central these days, although of course they're still there. As I mentioned, much of that history is locked away in private mail archives right now.

At any rate, whether it could be better (it could certainly be improved) or whether it could be worse (that's easy to imagine too), it is what it is :-), changing it, as we discovered with XML 1.1, is next to impossible, and the single most important thing about XML is not what it looks like at all - it's that it's the same everywhere, it's that XML is widely deployed, it's that all general-purpose XML tools work on all XML, so that every new tool, evern new document, multiplies (by some factor only slightly above 1.00 usually) the value of all other XML documents and tools. The network effect.

Liam

Re:Why XML was successful

[Ankh]

:-) yes, you could say I've heard of FrameMaker, and of Author/Editor and of Adept (later Epic) and of DataLogics Pager and of Interleaf Publisher and of a great many other SGML tools. I was certainly among those who felt that the complexity of the SGML standard was a hindrance to adoption, and also that SoftQuad Panorama was a good demonstration (at the time) of where we wanted to go.

But I certainly don't mind being "lectured" -- we learn a lot by listening!

Best,

Liam

Unfortunately I'm a Java developer...

[d3ik]

... 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...

[ashultz]

That gets my goat too.

Nothing makes a set of code harder to deal with than taking half of it and writing it in a variety of XML config files and then scattering them throughout the distribution. That way you ensure that anyone doing something foolish like trying to understand it through javadoc or use their IDE to learn it gets nowhere.

I'm going to go cry now.

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

[dch24]

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...

[j. andrew rogers]

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.

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

[thesnide]

The only real advantage XML has is that it is (sort of) human readable

I'm all in favor of YAML, that's really human readable,

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

[master_p]

The only real advantage XML has is that it is (sort of) human readable.

Actually, it is not. Many people I know, and me, have trouble looking at XML config files that span more than a few rows. You need a tool that presents the XML document as a tree, so you can collapse some nodes in order to focus in the interesting ones.

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

[Anonymous Coward]

XML itself has no native support for it but obviously you could use a SAX parser and include tags or attributes to specific node content length. If you're going to complain about it's use as a protocol (eg XMPP) it's more the single root tag that makes it difficult.

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

[oyenstikker]

The company I work for has had a lot of success with XML, and are planning to move the internal data structure for our application from maps to XML. There is one simple reason for our sucess with it: XSLT. A customer asks for output in a specific format? Write a template. Want to display the data on a web page? Write a template that converts to HTML. Want to print to PDF? Write a template that converts to XSL, and use one of many available XSL->PDF processors. Want to use PDF forms to input data? Write a template to convert XFDF to our format. Want to import data from a competitor and steal their customer? You get the picture.

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

[Anonymous Coward]

There is a good reason why there is no free ASN.1 parsers available.

The reason is, of course, ASN.1 sucks big time.

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

[Kjella]

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.

There's no secret binary is faster. I imagine you can make a lot more compact datastructures with TLV encoding, and codes instead of actual tag names. Do I care? No. XML is brillient for everything I use it for, and if there's a better way to encode XML for some edge cases fine. If you want to go "maximum efficiency" I'm sure you can do even more compacted, fixed-offset formats than XER tho. If there's a problem, 95% of the software for 95% of the population hasn't noticed it.

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

[TheMCP]

Java? What is this "Java"? I program in XML.

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

[Pootie Tang]

* Easy to change the schema, don't have to convert old data.

This makes sense depending on what the alternative(s) were. How was data stored previously that didn't have an equivalent of change the schema?

* They didn't know exactly what XML was, so if I recommended it, ... (a.k.a. "gee whiz" factor?)

I found this very odd. The fact that the bosses didn't know much about XML was a plus? It seems to me that's usually a minus.

  * The other developers liked the idea

This itself is not a pro. The other developers must have had their reasons for liking it. What were they?

I'm not anti-XML or anything, just want more insight into how XML was helpful for you. I only understood 1/3 of the pros and even that wasn't entirely clear to me.

Just in time for the festive season

[Centurix]

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?

[elving]

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

Re:No mention of XML's creators?

[tbray]

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

Re:No mention of XML's creators?

[x2A]

you're too modest ;-)

Re:No mention of XML's creators?

[ravenlock]

I'd try to be modest too if people blamed me for XML :P

Re:No mention of XML's creators?

[x2A]

*lol* very good point! I'd probably try and deny it in as fewer characters with as little punctuation as possible, just to lend more credit to the idea that I wouldn't invent such a thing.

Re:No mention of XML's creators?

[smallpaul]

In addition, XML was never intended to be an "invention". It was a simpification. Some innovation slipped in, but the vast majority was just debating what aspects of SGML to strip out and how to fix some well-known flaws in it. The innovation primarily was about how to integrate modern standards like URLs and Unicode.

A decade of bloat.

[Anonymous Coward]

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:A decade of bloat.

[Anonymous Coward]

Keep in mind a lot of Ajax software actually uses JSON, which can mean much fewer bytes getting passed across the wire.

Anything storing data on disk though - yeah, probably best off using XML. At least it's standardized, easy to write up a DTD for most documents by hand (or by using a web-based DTD generator).

Re:A decade of bloat.

[EvanED]

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.

This article argues the other side of that point. I'm not sure how convincing it is, but there are at least some benefits to the XML approach. Where the balance falls, I don't know.

Re:A decade of bloat.

[master_p]

Here are some counterarguments:

The XML one defaults to treating random characters as text, not as markup.

Wrapping text up in double quotes is not a problem. In XML, text must be wrapped up in tags. In S-expressions, it must be a literal.

The XML one does not use standard human-punctuation characters as markup. It doesn't require quoting of apostrophes, double quotes or parentheses. The only characters XML cares about are angle-brackets and ampersands. The need to escape does not arise with most prose documents.

Using standard punctuation characters as markup is not a specification of S-expressions, it is a specification of LISP. Literals in S-expressions could use angle brackets too. Furthermore, it is not true that XML does not require escape characters. If I want to write an angle-bracket, for example as part of an equation, I need to use a special syntax.

Now imagine that you are a program required to find syntactic ("well-formedness") errors and report them to the user. In the XML one, it is possible to notice that the footnote should have ended before the para ended. In the S-expression version, the software does not know that there is a missing parenthesis until it gets to the end of the document. In a sufficiently long document, this bad error checking could cause major problems. Even where there are no errors, it can be tricky in less powerful text editors to know which parentheses match each other.

Not entirely true. You do not know where the footnote ends even in the XML document! In the example given, it is easy to see that the footnote must end before the 'para' tag is closed; but if there are other elements between the open footnote and the end of the 'para' tag, then you would have to check with a schema to know that the elements following the footnote are not children of the footnote, but siblings to it. Furthermore, in the S-expressions solution, if a parenthesis is missing, you simply put one at the end of the expression. You do not need to know the tag.

You cannot evaluate the hype around XML without incorporating all of these technologies into the evaluation. Cumulatively there are decades of person-effort embodied in those specifications!

XPointer, XQuery and XPath can also work with S-expressions. C, C++, Java and C# IDEs parse the relevant code with ease, doing the same work those XML tools do. I am mentioning these languages because they are structured in a similar way to S-expressions (replace curly brackets with parentheses and put the keywords inside the block and voila, S-expressions).

The central idea of the XML family of standards is to separate code from data. The cental idea of Lisp is that code and data are the same and should be represented the same. The Lisp community's idea of "Schema" would likely be "Lisp program". The Lisp community's idea of "addressing language" would likely be "Lisp program." The Lisp community's idea of "query language" would likely be "Lisp program."

The above argument is actually irrelevant to the discussion. What if LISP represents code as data and vice versa? it's simply a matter of interpretation. What we are discussing here is formats, not content. In order to be able to do something with an XML document, you have to know what it means. Same goes with a LISP program. Furthermore, what about programs written in XML? isn't then XML following LISP's paradigm?

Re:A decade of bloat.

[carpeweb]

Accepting your argument that XML requires bigger hard drives and more bandwidth:

You wouldn't have to save much time for developers or users to justify adding a whole lot of that, would you?

XML's Existing

[Inmatarian]

XML exists so that the "version" field in binary files doesn't spill over to the next byte, making it impossible for old software to interpret new features. But hey, lets give a round of applause for XML. It makes manual corrections a lot easier than wipping out a reference file and a hex editor.

Re:XML's Existing

[myrdred]

<?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>

news flash

[User 956]

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.

Re:news flash

[grcumb]

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.

Philistine. You just don't appreciate abstraction.

8^)

Re:news flash

[kfg]

This is a spec for structuring data

No, it's a spec for text markup.

Cultural Effects?

Rampant spec abuse. 10 years old and still looking for a problem to solve.

KFG

Re:news flash

[Anonymous Coward]

"No, it's a spec for text markup."

"First, in spite of it's name, XML is not a markup language; rather it's a toolkit for creating, shaping, and using markup languages."
[Source: ISBN:0-596-00046-4]

"Rampant spec abuse. 10 years old and still looking for a problem to solve."

Then don't use it. I'm certain your indian replacement will not have any such issues.

Re:news flash

[kfg]

"First, in spite of it's name, XML is not a markup language. . .

OK[delimiter],[/delimiter] so now it's a spec so bad they even named it wrong and a standard data exchange format with no standard[stop].[/stop] [sarcasm]Muuuch[/sarcasm] better[fullstop].[/fullstop]

I'm certain your indian replacement will . . .

. . .be a hell of a shock to my family.

KFG

KFG

Re:news flash

[macadamia_harold]

No, it's a spec for text markup.

Oh, so text isn't "data"?

idiot.

Re:news flash

[kfg]

It's also a binary format.

KFG

Re:news flash

[l0b0]

Maybe he was thinking about IT culture. XML sure has gotten rid of a lot of maintenance problems with regard to computer parsed files. Don't put the format description and instructions in a manual; blend it with the data!

Anyway, fundamental technological changes always have some impact on the rest of society. GUIs made computers accessible outside of academic circles, the Internet made the world talk, and using XML can be a small step towards more people understanding your data the same way you understand it.

Re:XML "Sucks"

[MyLongNickName]

When does a broken link constitute "Informative"?

Re:XML "Sucks"

[Bob54321]

This is slashdot. Nobody reads the links.

XML Decade?

[RealGrouchy]

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

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

I give up! Which decade was XML?

- RG>

Re:XML Decade?

[Werkhaus]

>I give up! Which decade was XML?

Sixties. Unfortunately, it was the 1060s.

Re:XML Decade?

[guruevi]

Converting XML to Decimal is 1060. Long time ago ;-)

Re:XML Decade?

[Anonymous Coward]

Actually, that would be 1040 -- 'X' (10) before 'M' (1000) = 990 + 'L' (50) = 1040

Re:XML Decade?

[Anonymous Coward]

Yes; 1060 would be MLX.

Re:XML Decade?

[Planetary]

> Sixties. Unfortunately, it was the 1060s.

That would be MLX, actually.

Re:XML Decade?

[clickclickdrone]

>Sixties. Unfortunately, it was the 1060s.
Not a good decade if you were a king called Harold. A good decade if you were after inspiration for that big tapestry you were itching to start work on.

Re:XML Decade?

[Chapter80]

No. 1040 is MXL.

XML is non-convertable.
It's as much 1040 as it is 1060 as it is -940 (MX = 990, which is before the L). All of which are wrong answers.
It's like the Roman "divide by nero error".

Re:XML Decade?

[ashitaka]

Romanus eunt domus!!!

Re:XML Decade?

[aibrahim]

To answer the joking question...

XML = 1040

Oh, those 40's were great too. Lots of good gossip. Macbeth killed Duncan. William the Conqueror took Normandy. There was that business with Zoe, Michael, Theodora and Constantine in the Eastern Roman Empire. Oh, and don't get me started on the Simonious Popes.

Re:XML Decade?

[mmalove]

Explanation:

x = 10
m = 1000
l = 50

x is to the left of a larger valued letter, so it's value is negative.

Therefore, 1000+50-10 = 1040

1040 is the main individual tax form. In other words, welcome to the tax decade!!

JSON itself is still quite bloated.

[Anonymous Coward]

JSON itself still suffers from much bloat, and aren't always easily readable by humans. That's why we have additional structured data formats, including YAML.

Re:JSON itself is still quite bloated.

[Duhavid]

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.

Re:JSON itself is still quite bloated.

[Anonymous Coward]

XML and JSON are typically sent via servers that understand GZIP compression, which means they're only bloated at either end of the wire (the server and the client). Clients have enough memory to store even 100KB of XML (and that's a ridiculous scenario -- few Ajax apps send that much and people send much more HTML than they do XML and no one complains about that). So then it comes down to server resources, and whether 100KB or whatever is going to matter to a server. IMO the complaints seem to be unwarranted (by all means though if someones got a good scenario let hear it).

Re:JSON itself is still quite bloated.

[giuntag]

Oh yeah... ...and then the flashy new app gets released to us, based on Oracle Mapviewer producing SVG files.
At one meg every file, do you think you can discard:
- the time spent gzipping it server-side
- the time spent dezipping it client-side
- the ungodly amount of RAM it chews up on every single client
- the sheer computing time the client needs to parse the xml into in-memory structures, render and blit them them to screen?
I tell you I cannot: the resulting interaction is slooooooow.
The sw developer is still undecided if we will have to upgrade our network to gigabit or replace every single client with workstation-class hardware with a fast video card.

BTW: oracle is moving fast out of SVG and into ajax-based UI, copying 100% of what google did a couple of years ago: jscript+png/jpeg...

A little while ago somebody did a speed comparison test on xml vs. binary format for speradhseet files. The result was: Office+xml is comparable to openoffice+xml, but the shit is beaten out of both by using the native binary format (2 megs file vs 11 meg once in memory or something like that)...

Re:JSON itself is still quite bloated.

[Kjella]

Not all XML is readable by humans.

Of course not... <foo>[10 billion chars of base64 junk</foo> is still valid XML. The point is that XML can be, in particular without having to write complex debugging functions. For an XML under 8192 chars (usually enough anyway):

qDebug() doc.toString();

That's it, done I have a debug function. Now write me one for that binary format or SGML or whatnot. XML is "developer-readable" if not "human-readable" by people at large. That is the simple reason it's popular. I wouldn't dream of using it if high throughput was key, but even in many server systems it is irrelevant unless you're simply a message-passing system. If you do anything significant work on the data, it's usually far greater than any XML inefficencies.

Re:JSON itself is still quite bloated.

[Kjella]

qDebug() doc.toString();

/* Previews are for whimps */
qDebug() << doc.toString();

Re:JSON itself is still quite bloated.

[Duhavid]

The formatting strings in the Janus controls are easily under 8192, and
are not base64 encoded garbage, but are not readable. It is just one
runon string. Like English without punctuation or spaces or new lines.

Anyway, my critisism was aimed at those who misuse XML, not at XML
itself. XML is an excellent way to represent data, and as a programmer,
I really appreciate what it brings to the table. It does not cure
cancer, or eliminate world hunger, and should be used when appropriate,
and in appropriate ways. I have seen it used, and it made some issues
fade away. I have seen it used and introduce issues.

Re:JSON itself is still quite bloated.

[Anonymous Coward]

My problem with XML is with people going way overboard with it.

It should not take 35-50 lines of xml to say, essentially, "item_id, qty1, qty2 are x, y, and z" when you are doing it for 50,000 line items. Yet some boneheads will manage to. They make it as verbose and abstract as possible: using non-english element codes to describe a <name>/<value> (name given in full english, describing what type the value--also full english--is going to be) to say that the what the next <element id="whatever"> with <name> and FINALLY the actual <value> is going to be. Data (not tags) has words, repeated no less than 4 times in my case, describing what an integer represents. None of the tags say <quantity> for example. This is an example of why XML is at the butt end of many jokes concerning excessive verbosity. (I appreciate the irony of my explanation also being verbose.)

Other groups use their own XML schemas that prefer "short form" tags that are all in [a-z][0-9]* format, no words in english (or any language for that matter.) So much for readability.

Businesses send XML files that are generated on the fly with their own in-house generating software, not using existing XML libraries. Often they don't check whether they actually parse as valid before sending them out. Why even bother?

Not everyone follows the XML ideals that the advocates pay lip-service to, and dern it I wish they did.

Re:JSON itself is still quite bloated.

[Duhavid]

This is true, but any good tool can be misused.

Why, just the other day my skull was bashed in by
a perfectly good hammer.

Re:Celebrate the XML Decade

[Duhavid]

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.

So where is this old chestnut?

[Cosmic Debris]

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.

Re:So where is this old chestnut?

[19thNervousBreakdown]

It flows better this way, and I think it originally referred to sex instead of XML:

XML is like violence. If it's not solving your problem, just use more.

Re:So where is this old chestnut?

[Anonymous Coward]

Seen a year-or-so ago:

--
XML is like violence: if it doesn't work, use more.
sig for timc on wwiionline.com, Sep 2004
--

950 AD

[Anonymous Coward]

XML == 950 10/1000/50 (low numbers, before high numbers subtract,--IV=4, IX-9, etc.)

Re:950 AD

[Anonymous Coward]

It would actually be 1040

10/1000/50 - 1000-10+50 = 1040.

Still, it's not standard; MXL would be the usual form.

XML is what it is

[mlwmohawk]

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

[Duncan3]

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.

Re:Stuck

[l0b0]

XML is for data interchange, nothing else.

Isn't all data interchanged? From client to server, from blogger to browser, from developer to developer, etc. Any data which is not interchanged is either useless or forgotten. And XML has shown its strength in all these areas: Ease of human and computer parsing.

Re:Stuck

[Eivind Eklund]

XML is horrible to human-parse. If you think XML is OK for human parsing it is because you've not seen real file formats. I've freakin' worked with structured *binary* formats that was usually easier to interpret than most XML (the IFF - interchange file format - for the Amiga).

Eivind.

Re:Stuck

[PinchDuck]

"Stuck" may be a good thing. From a historical perspective, XML has a huge benefit. We have data tapes going back 50 years, but don't know the format of the data. 50 years from now, when researchers want to read what data we're processing, they'll have a much easier time of it because of XML. It's not perfect, but they will be able to take a stab at what the data means just by looking at it.

As for a party, what the hell, any excuse is fine by me!

Re:Stuck

[theCoder]

Any moderately complicated XML document is very difficult for humans to parse. Sure, they can read it, but it's often hard to understand. See, for example, this post on this article.

Also, parsing XML isn't exactly easy for computers either. Especially because it is so flexible, the parser has to be written very generically. This has the benefit of only having to write one generic parser (which is good), but something still has to drive that parser to interpret the information, and that can get compilcated if the XML document structure is complicated.

If you want something that is easy for humans and computers to parse, look no further than the text configuration files in your /etc directory. Sure, there are some bad ones (like sendmail.cf), but most are easy for humans to read and edit, and most are pretty easy for the programs to read. Now, compare that to the XML junk in your ~/.gconf directory. That's much harder to read and modify.

Sure, XML is more flexible, but that flexibility makes it much harder to work with than simpler formats.

Re:Stuck

[l0b0]

The XML in the post you referred to is bad for several reasons:

• Not indented or color coded (any proper editor will do this for you). Because of this, you're missing lots of structural information.
• The information could have been represented with a lot less XML. E.g., you could have removed <relationships>, and just added that as an attribute on <participants>
• Creating nested elements (type/demeanour (sic)) when there's only one piece of information is unnecessary.
• You don't need @type when you're using namespaces.
• The data lives in a context, depending on the problem you're solving. That data should not be part of your XML.

Parsing XML is a whole lot easier than HTML and SGML, because it is less forgiving. At the same time, it's flexible enough to contain just about any information which you could contain in both the others.

Nothing has to "drive" the parser. Modern programming languages support XML very nicely. In any case, if you got "complicated" XML, it sounds like more of a design problem than anything else. The result always depends on both the tool and the user.

Sure variable_name=value is easy to read, but these kinds of files have their own problems:

• Trying to define relationships between variables (e.g., this variable depends on that one being defined, this value should always be less than that one) makes for messy manuals or guessing games. The tree structure of XML can take care of that.
• There are a huge number of formats like these, which differ subtly in their use of quotes, valid names, encodings, escape characters, line endings, single/multiple line comments, etc.

Nothing is a silver bullet. Use whatever fits the problem. It just so happens that XML fits a lot of problems, is supported by a lot of mature tools, and is generally a good compromise between readability, parseability, size, and information structure. You need more structure? Use a database. No structure? Use a plain text file. You need small size? Use gzipped whatever.

Re:Stuck

[Jesus_666]

It's also great when you want random documents to be easily reverse-engineerable. XML markup can't replace good documentation, but it can give pointers.

This occurrred to me when I had to reverse-engineer a format of concatenated ASCII lines mostly containing sets of small integers with strings intersparsed (ie. "1\n0\n22 12\nbrown\ngreen\n12 11 12 10 9 13 14\n5 5 6 3 3 2 3 3") and had to come up with an own format to store the data in. Just in case in the future someone has to write a replacement for my software each file (even though other kinds of storage would be more efficient) tells the user where a variable begins, where it ends and what name it has. That's one advantage of XML, at least when the tag names are informative.

Re:Stuck

[mcvos]

Isn't all data interchanged?

Well, what do yoou call data? There are quite a lot of XML-based languages, including programming languages, like XSLT. XSLT is basically the ultimate XML language, because it's in XML and it's made to operate on XML. So you could use XSLT to generate the XSLT you want to handle your data, or crazy stuff like that.

Re:Stuck

[Kent Recal]

XML is horrible to human-parse.

100% agree'd.
XML done "right" (with all the abstraction fluff that your eclipse-jockeys deem necessary)
quickly becomes totally unreadable.

And as if the brace and quotes soup wasn't bad enough the XML files that you meet in reality
are usually poorly indented, too.

This means that in practice you need a special XML viewer software (or editor support)
to make sense of a non-trivial XML document anyways.

So, why not just store the meat as well condensed binary blob
that can be sliced, diced and transferred without expensive serialization?
Well, because XML parsers are "standard" and "XBLOB" parsers are not...

Longevity

[scott_karana]

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

Re:Longevity

[HeroreV]

Then get to evangelizing. Fast Infoset is ready to go.

Re:Longevity

[jibjibjib]

WBXML perhaps?

Re:Longevity

[Anonymous Coward]

But then it wouldn't be XML anymore, so why call it that? All you need is a compact and easily processable format for representing trees with node attributes, right? (that is, a format that can represent all possible XML structures.) I'm pretty sure there already are formats like that.

Re:Celebrate the XML Decade

[Randolpho]

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>

just plain wrong

[mccoma]

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

a decade of ...

[The Pim]

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.

Re:a decade of ...

[operagost]

If a standard is used inappropriately, it's not a flaw in the the standard. It's a flaw in the PHBs we allow to make uninformed decisions.

Re:a decade of ...

[Anonymous Coward]

If you'd rather use SGML be my guest. XML solves the problem of beeing a simple to use subset of SGML very well.

Re:a decade of ...

[thechronic]

My understanding is that there isn't much to the standard, it's up to the application (such as SOAP) to define the "semantics". It's just a nice way to store and verify metadata.

Re:a decade of ...

[jibjibjib]

XML and all the stuff that goes with it (DTD, XSLT, XPath, ) could hardly be described as "simple". There's a lot of stuff to learn if you want to be using XML as effectively as possible.

Re:a decade of ...

[Anonymous Coward]

it's god's flaw for allowing us to make decisions at all.

Re:Celebrate the XML Decade

[Anonymous Coward]

<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.

XML Debacle is more like it ;)

[FooAtWFU]

Actually, I was looking at the title and I did a double-take, since the first time I saw it I thought it said "Celebrate the XML Debacle". Oop. I thought, surely it's not that bad...

Eh, what do I know? Maybe it is that bad. =)

Are you autistic?

[Anonymous Coward]

Uncyclopedia needs more editors like you.

XML for English, S-Expressions for Data

[Anonymous Coward]

The argument was that English text looks better in XML than in S-Expressions, and few would deny that. But XML has since grown to be the universal data encoding format, and there S-Expressions are far better. Compare:

        (list 1 3 5 7 9)

        <list>
                <element type="integer">1</element>
                <element type="integer">3</element>
                <element type="integer">5</element>
                <element type="integer">7</element>
                <element type="integer">9</element>
        </list>

So if one format is to be chosen for everything, XML is a poor choice. (BTW, XML is ambigous about the semantics of the extra whitespace the the list presentation above.)

Re:XML for English, S-Expressions for Data

[Anonymous Coward]

XML is not ambiguous in the slightest about whitespace -- whitespace is always a text node. And the XML you've given has more structure than the S-Expressions (interger casting, proper field delimiters). Your S-Expressions don't have any delimiters other than the space character so they obviously cannot contain lists of strings with spaces. This means that the XML equivalent to this would be 1 3 5 7 9 ... however you chose to make the XML format more powerful than the S-Expressions by giving proper field delimiters that can contain any data and with integer casting. Thanks for showing why XML is better than inflexible S-Expressions.

Re:XML for English, S-Expressions for Data

[Anonymous Coward]

XML is not ambiguous in the slightest about whitespace -- whitespace is always a text node.

So was I wrong in separating the elements with these text nodes? If not, what is their natural interpretation?

Your S-Expressions don't have any delimiters other than the space character so they obviously cannot contain lists of strings with spaces.

S-Expressions specify a handful of types; integers are among them. You can also have a list of strings:

        (list "a" "b" "c")

or a list of lists:

        (list (list 1 2 3)
                    (list "a" "b" "c"))

or, more simply:

        '((1 2 3) ("a" "b" "c"))

Don't feel too bad, Tim

[jlowery]

Al Gore declaims the same every anniversary of the Internet.

Human readable & writable does matter

[Geof]

We didn't need a human accessible format. . . . we can . . . write applications to edit and display it in any way that the humans want. To make XML human readable is to mix presentation layer issues, with encoding issues. . . . We should have just used Lisp syntax, since then we would have had parsers for it in 5 mins of coding.

You know, I like Lisp S-expressions better too. They sure are easier to parse. But, to echo your argument, we have libraries for that, right?

Decades of experience have shown the benefits of human-readable (and writable) formats, for programmers and non-programmers alike. I'll focus on the non-programmers, because in the end they're the ones creating the documents that are the object of the whole exercise.

Non-programmers author XML all the time. They do it because hand-authoring offers flexibility and power beyond what their applications offer them. They do it because they don't have the applications, or they can't afford them. They do it because innovation comes first, the tools come after. They do it because they're hacking FOAF or RSS or a Creative Commons license onto their web site. They will increasingly do it because when the application is obsolete, the data isn't.

If Mr Quin is right (I don't know, I haven't seen the research), your proposal exchanges long-term access for document authors with a bit of up-front convenience for library developers. In my opinion, that's exactly the wrong trade-off to make.

Re:Human readable & writable does matter

[jibjibjib]

when the application is obsolete, the data isn't.

<sarcasm>Yes, because of course by the time your application is obsolete we will have an uber-cool AI that can automagically work out what all your tags meant and convert your XML document to the latest format.</sarcasm>

It's not like just because something's in XML that automatically makes it easily usable with new applications. Converting an old XML format to a new XML format can be just as hard as converting an old binary format to a new one.

Re:Human readable & writable does matter

[zeromorph]

It's not like just because something's in XML that automatically makes it easily usable with new applications.

Ok, but suppose you have to convert a text file into a semantically structured file.
Please choose your preferred source format:

[ ] unstructured ASCII text file

[ ] XML-file

[ ] MSWord .doc

Re:Human readable & writable does matter

[Decaff]

It's not like just because something's in XML that automatically makes it easily usable with new applications. Converting an old XML format to a new XML format can be just as hard as converting an old binary format to a new one.

As someone who has been involved in having to convert old binary formats, can I say..... this is way out.

Given an undocumented text format with readable markup which can be transformed with a standard mechanism (XSLT) and in any of hundreds of tools, or an undocumented binary format.

I know which I would choose.

Re:Human readable & writable does matter

[MORB]

XML is a terrible format for manual editing.

Code, XML or otherwise, have to be both writable and _readable_ by humans. You cannot work properly on code that is difficult to read.

What I essentially dislike with XML is that people keep using it for task where it is just terrible.

Storing large amount of data in XML? Doesn't scale. You can't access the data randomly, unless you keep an index on the side with offsets into the file for particular pieces of data, but then it's not longer xml. It's XML-with-some-redundant-data-on-the-side-to-overco me-the-shortcomings-of-xml.
And don't come up with xml databases, because they're just database that store trees and interface with the application using xml.

Using XML so you don't have to bother writing a parser? You still need to parse SAX events or a DOM to construct something actually useful for your application. You just moved parsing to a higher level of abstraction, but you still need parsing.

Using XML to store large amounts of data? It cannot efficiently store large amount of structured data, so you end up with stupid things like svg using long strings containing a structured, but non xml format (that you will have to parse manually in addition of parsing the sax or dom).

Want to store an array of floating point numbers, or integer values in hexadecimal? Too bad, xml doesn't standardize the representation of such data types. You'll have to decide how to translate them to ascii, and parse them back when reading.
"don't write a parser ever again". Yeah, right.

Want to store a huge array of small structured objects containing for instance several attributes in xml? Again, throw scalability out the window because of the redundant tags, or store them in a non structured way (which is kind of a failure for a format intended to store structured data)

I'd much rather use JSON, which has a clean, non uselessly noisy syntax, includes the ability to define arrays, and specifies numerical types.

Re:Human readable & writable does matter

[Geof]

XML is a terrible format for manual editing.

I agree with you that XML is ugly, that it's harder to work with than it should be. DTDs are a mistake. Namespaces could be cleaner. The wall-to-wall brackets and quotes in some XML formats drive me nuts.

That said, I'd sure rather work with a web page as XHTML than as JSON. XML is better at some things than at others; as you say, "people keep using it for task where it is just terrible". Some, for example, treat it like a database or object store. They even produce standards based on those assumptions (XML Schema *cough*).

You have certainly produced a list of poor uses for XML. It's not good for random access, nor for dense numerical data. It makes a terrible database - either object or relational. XML is a document (meta) format. It's designed for storage, for interchange, for reading and editing. The last thing you want it to do is echo your in-memory data structures. That's how Microsoft ended up storing random chunks of data from memory in their Word documents.

A good document format shouldn't be tied to the application, or to the particular version of the data. It should reflect the nature and semantics of the data, not the details of processing or implementation. It should be forward- and backward- looking: usually it should be extensible and backward compatible. That's why XML is only semi structured - your format can make tags and attributes optional, it can ignore what it doesn't understand or pass it through untouched. It should be self-documenting (which is probably a pipe dream, but the tags and attributes do help); it should be robust and unambiguous. If it's redundant, that's ok; if it's big it can be compressed; if it's slow, faster's better - but it's not the top priority.

Once you have a good format, it can be used for many different things. Then you start to gain real semantics, standard libraries, and people who really understand the format. These are huge wins. This is what has happened with HTML; it's what the Atom folks are trying to replicate. If you think these things don't matter, look at how long it took to really figure out how to use HTML to produce clear, concise, and flexible documents, or how long it took for microformats to emerge.

When the tools are there, of course, it becomes convenient to use XML for other things. With DOM and XPath it starts to look like a cheap database. XSLT, with its zero side-effects, can even be efficient about processing the stuff. Hey, I admit it: I've used XML as an internal format, with XSLT as an embedded scripting language. It worked great. But I'm not gnashing my teeth because it was a bit slow and a bit ugly. I knew I was abusing the technology. If you're using XML as your internal format for data processing, and you're concerned about efficiency or scalability, you're missing the point.

Re:Human readable & writable does matter

[MORB]

Yes, for a web page, I agree that XML is more appropriate than JSON. But I think that's because XML is too "rich text document" oriented.

As for abstracting implementation and data format, I sort of agree. But I don't see how XML not allowing arrays or including specifications for numerical types help. Those things are basic data structure just like objects and properties are. You find them in every language.

The only reason I can think of is that XML was originally designed to store rich text documents.
The concept of document can be applied to about anything, however. Take a 3d scene graph, for instance. You seldom need text in there.

You do need, however, arrays and numerical values. You also need to be able to represent more general graphs than just a tree, but you have to create your own way for an object to reference another in other ways than an implicit parent/child relation (not that JSON is better on that aspect as far as I know)

I think that the main problem is binding classes and objects from the programming language to a storage format (xml or otherwise). The issue of making the format independent of the implementation is simply an issue of cleanly separating the classes that form the document from the presentation/edition/etc. layer.

I don't see how XML actually help you to make a more implementation independent format, anyway. Any language or format flexible enough to be useful allows an infinite number of bad approachs for each good one.

When does a buzz word unbuzz

[cnlohfin3109]

Does this mean XML is no longer a buzz word? or is it still a way for self-important elitist 30 year old c programmers to feel superior by placing everything not used by them into a box so they can avoid change? does this make me a troll? I guess after 5 hours of applying the pumping lemma on theory of comp homework left me grumpy.

My apologies; I went off on a slight tangent there

[kfg]

A more accurate answer to your question would be:

lkajt;oq iuj4 tylkmeafngm/lahtoi[quypitjnqw;lkrgejq;lk

KFG

Re:Celebrate the XML Decade

[Dahamma]

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.

Obligatory link

[frenchbedroom]

To the Parable of the Languages

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)

Re:Celebrate the XML Decade

[gbobeck]

I started this morning by talking to everyone in XML.

Care to share the DTD and schema you used for that?

I think this...

[tonicblue]

...would have been a more appropriate exert:

As they puzzled and wondered, the bushes at the end parted and XML walked into the light.
XML! Exclaimed C++. What are you doing here? You're not a programming language.
Tell that to the people who use me, said XML.

notice too late

[Tribbin]

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.

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

[trezor]

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:Celebrate the XML Decade

[zootm]

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.

Significant technical victory

[gborland]

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!

there IS binary XML, and just zip (like ODF)

[Anonymous Coward]

how efficient something is to the user (or developer) is usually really more important than how efficient it is in cycles to burn

Ten years of XML ...

[Louis Guerin]

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

L

Why his imagination wasn't successful

[Anonymous Coward]

"What are the better alternatives?"

His imagination. Shame it's not a cross-platform solution.

Re:XML "Sucks"

[PriyanPhoenix]

The Slashdot effect is now largely psychological. The server, knowing it has been linked to by Slashdot, pre-emptively dies irrespective of the fact no one is actually reading it.

Re:Celebrate the XML Decade

[menkhaura]

That would be me, but I ripped it from some AC comment.

Re:Celebrate the XML Decade

[rograndom]

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.

You're his co-worker, aren't you? Glad to see you've calmed down a bit.

Re:Celebrate the XML Decade

[Anonymous Coward]

> > Hello, fellow coworker type dude!

> 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.

<?xml version="1.0" encoding="UTF-8"?>
<rebutal xmlns:rb="http://www.w3.org/2006/slashdot-rebutal" >
    <reason type="syntactic" subtype="validation">
          I won't even listen to you until you use the proper &quot;disagree&quot; XML schema (http://www.w3.org/2006/slashdot-disagreement)
    </reason>
</rebutal>

XML: the CSV of Y2K

[DulcetTone]

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

Re:Celebrate the XML Decade

[Duhavid]

It's still a great sig. I laughed like the dickens when
I first saw it, especially since I was working for a place
that seemed to apply that theory liberally. You just could
not read the code and know what would happen, it was all
driven by the XML fed into it.

Re:Celebrate the XML Decade

[lukateake]

menkhaura, I just have to say that I, too, love your signature! I've used it in several presentations to much critical acclaim.

YAML

[cliveholloway]

Take a look at YAML. That looks programmer friendly.

Can someone explain why I should care?

[defile]

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?

Nice story, but it's false.

[Grendel Drago]

The story about the space shuttle and the horse's ass you linked to? Urban legend.

Celebrate?

[zizzo]

We must not be thinking of the same XML.

Re:Celebrate the XML Decade

[Anonymous Coward]

It's Friday, isn't it? No wonder you have the time to type all that! Your his co-worker, right???

BTW I liked the "Divorce" reference! Reminded me of my own pending divorce. I might recover from being reminded of it some time tomorrow...

XML is Lisp in drag (n/t)

[VP]

n/t

ASN.1

[SanityInAnarchy]

But seeing as someone else on this thread has already mentioned something else, you see the problem. XML wins because Worse Is Better. I hate it, but there's not much we can do about it.

XML is a nescessary evil...

[GWBasic]

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 "Sucks"

[Cow Herd (Anonymous)]

Here is a more accessible opinion about XML.

Re:Celebrate the XML Decade

[zootm]

I'm not his co-worker, but yeah, Friday is the reason I had the time to type all of that. Also I've been writing XML schema all week so I needed some release. :)

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

[FlyingGuy]

Nope not trolling in the least!

From the WC3...
"Extensible Markup Language (XML) is a simple, very flexible text format derived from SGML (ISO 8879). Originally designed to meet the challenges of large-scale electronic publishing, XML is also playing an increasingly important role in the exchange of a wide variety of data on the Web and elsewhere."

Hmmm moving data...., I guess I am not far off the mark.

Lets see and there is this which goes on at length about whay its a cool way to, wait for it..... Move Data!

But wait, there's more! You guessed it ladies and gentlement, the WC3 goes to great pains to tell you that only XML is X-Platform and is an excellent way to store, manipulate and transmit data! I would site this as a major push for XML to do exactly what I said it was trying to do.

As to you, fucktard, I was moving data between systems, more then likely, while the best part of you was running down your momma's leg. So shut your fucking cakehole and READ up.