Tim Bray on the Birth of XML, 10 Years Later

lazyguyuk writes "Tim Bray posts a lengthy blog on the birth of XML, formalized as 1.0 in Feb 1998. 'XML is ten years old today. It feels like yesterday, or a lifetime. I wrote this that year (1998). It's really long. The title was originally Good Luck and Internet Plumbing but the filename was "XML-People" and I decided I liked that better. I never got around to publishing it, so why not now?'"

Comments

Classic

[Gothmolly]

Young Buck: Hey, we have a data exchange problem between two systems, lets use XML !
Greybeard: Ok, but now you have 2 problems.

Re:Classic

[smittyoneeach]

In defense of XML, the parsing problem is handled.
Best wishes on solving the semantic snarls.
XML, like all good approaches, handles mechanism, not policy.

Re:Classic

[fireboy1919]

In defense of XML, the parsing problem is handled.

To me that says that XML handles a problem that wasn't there. Parsing problem for pretty much everything is almost universally solved by regex...

I don't really care about the XML format. Personally, I'd be happier if it were stored in binary. The thing I like is the DOM tree as a data construct, XPath as a means of addressing, and XQuery as a means of getting parts out of it. (XSLT is okay, but from my experience, it's a lot clearer to represent a transformation as a series of productions than it is to use XSLT...perhaps a production-oriented approach that used XPath addressing?)

With those, you've got a good mechanism for serializing, reading, and deserializing objects, classes, and all manner of other things.

There are only a few problems with this:
1) Non-ancestor relationships and references (i.e., having the same node as multiple locations in the XML document) are not covered by XML, but are possible with objects.

2) Attributes in XML have no obvious mapping to objects...so what do you do with them?

I wish we could use something like XML (in that it could use DTDs as schemas, and had support for DOM methods along with XQuery and XPath), but with a more effecient format (binary), and with the ability to encode references.

That would be just about perfect.

Re:Classic

[oyenstikker]

There are only a few problems with this:
1) Non-ancestor relationships and references (i.e., having the same node as multiple locations in the XML document) are not covered by XML, but are possible with objects.

You can with refids and keys.

but with a more effecient format (binary)

It is wonderful to be able to easily read and edit the data in a text editor. If you want it more compact for storage and transmission, compress it. I understand that a binary format could lead to more efficient processing and parsing, but I think the benefits of readable text outweigh the efficiency.

Re:Classic

[Flambergius]

To me that says that XML handles a problem that wasn't there. Parsing problem for pretty much everything is almost universally solved by regex...

XML doesn't handle parsing. XML makes parsing easier; in fact so easy that parsing XML isn't a problem anymore.

For an expert, I think XML and regex are complementary techniques. For anyone other than an expert regex are way too brittle. Ordinary people need to be able to operate on their data, it can't require voodoo. (Not that XML in all its arcane application is anything close to plain English, but it's much better than custom data formats and regex.)

Re:10 Years and still waiting

[CRCulver]

Do you maintain a website? XML has been a godsend for those who want to maintain web and print output side by side. By keeping your data in an XML format, you can use simple XSL stylesheets to generate multiple types of output. See e.g. O'Reilly's XSLT Cookbook for dozens of very real-world examples (it's probably in your library).

That's just one example of how XML technology has made coding easier. Others I'm sure will point out others.

If you aren't a developer, then I'm not sure XML was supposed to directly revolutionize your end-user experience.

Java and XML, bad tastes that are worse together

[Omnifarious]

I've recently taken a job at a primarily Java shop. After seeing XML used and abused for ant, maven and various other things I've grown even more disenchanted with it. And now I've also gotten the chance to see that not only does Java represent a poor trade off between the annoyances of a strongly typed language and the speed of a dynamic interpreted one, it has a horrible mess of dependency issues that nobody really solves besides.

I'm much more hopeful about technologies like Thrift and/or D-Bus than I ever was about such abysmal abominations as SOAP, or the only slightly better XML-RPC.

The Java XML world seems like this little closed ecology of mutual masturbators who all come up with more Java and XML 'solutions' to problems that never existed before they started using Java and XML.

I see the value of XML for long-lived documents that don't spend a lot of their life on the wire. And possibly for config files, though IMHO it is too ugly and unreadable for those. But as a general tool for Internet plumbing it's awful.

Re:IVE BEEN WAITING SINCE 1998

[halivar]

Looks like you're going to have to wait a little longer. Try holding your breath, this time.

Oblig

[mariuszbi]

XML is like violence.. when it doesn't work, use some more!

Re:XML and Interfaces

[MBCook]

Here are some of the "fun" things I have run across in other people's (almost certainly custom) XML interpreters/producers:

• Tags must be upper case
• Tags can't be upper case
• You must put line breaks between elements
• There can't be any whitespace between elements
• It's import to URL encode the XML before it gets sent from them to me
• You don't need CDATA blocks, just put the ampersands and >s right in there, it'll be OK
• Your XML should all be inside a CDATA block in container XML
• No tags can self-close
• Self closed tags need a space between the slash and bracket
• Self closed tags can't have a space between the slash and bracket

That's just what I can think of off the top of my head. We've seen quite a bit of crazy stuff. If everyone would just use one of the already written XML producers or parsers (the big ones, the ones that work) life would be much easier around here from time to time.

Java and XML - Addendum

[Omnifarious]

And, of course, my post is incomplete with reference to my little rant on why CORBA and other forms of RPC are bad. Both Thrift and D-BUS are pretty close to the ideal solution I describe later. They focus on message content over semantics and are extremely easy to parse. SOAP and XML-RPC fail on both of those counts. They are about semantics (you are making a remote function call that does some specific thing, not sending a hunk of data that has some particular content) over content and they are a huge pain to parse.

Re:Java and XML - Addendum

[cjonslashdot]

CORBA uses IDL for interface definition. Therefore, you don't even have to write code to parse it: the parsing code is generated automatically. So the arguments about parsing are non issues. With regard to content, one can define content in IDL very easily. I have not used the APIs you refer to (e.g., Thrift), so I cannot comment on those. I will say this though: when I used to write apps 10 years ago using CORBA, it took me so little time to throw a system-to-system interface together that I almost didn't even think about it. The same with EJB, except that persistent EJBs were flawed and so EJBs lost credibility even though the API model (similar to CORBA) was (and is) extremely easy to use. Then people started wanting to communicate across firewalls, and OMG didn't get its act together and make IIOP capable of traversing firewalls before people got hooked on hand-coding HTTP messaging, which then led to XML messages and SOAP and Web services. The right answer was to fix the OMG spec for pushing IIOP through firewalls in a standard way. Nowadays, whenever I have to create an inter-system interface and the options involve SOAP or Web services or some other XML-based interface, I groan and it takes me ten times as long to get the interface built and reliable. That is not progress. I will look at Thrift and the other API that you mention, and we may disagree on some thing (e.g., the value of type safety), but I agree with you that XML-based messaging has been a huge, huge step backwards.

Re:Java and XML - Addendum

[Omnifarious]

CORBA is a minor pain to parse. From what I could tell you could just sit down with a spec and code up your own parser for ye-old random language in a day or two. But that's not my major issue with it.

My major issue with it was that it promotes designing distributed systems that focus on the semantic roles of the participants instead of the data moving around. In fact it discourages programmers using it from even thinking of what they're doing as sending messages to some system many milliseconds away. Among other evils this leads to all kinds of interesting issues with threading and concurrency that didn't even have to exist.

Re:10 Years and still waiting

[CRCulver]

Just like LaTeX! Reinvention is a wonderful thing.

LaTeX is restricted to certain types of print output. It emphatically cannot output HTML easily. Just look at the umpteen thousand threads on comp.text.tex where someone complains that

latex2html</ecore> can't handle anything more than a handful of quasi-default LaTeX packages. Plus, Unicode support in LaTeX has been shoehorned in and is still incomplete (though xetex is making strides), while at least XML was designed around Unicode. And then there is the fact that XML encourages semantic markup, while LaTeX contains non-semantic tags like <ecode>\textit

.

Re:Java and XML, bad tastes that are worse togethe

[GodfatherofSoul]

Yay! Nothing like the combination of XML and Java to bring out the haters. Incompetent use of a language/API doesn't equate to a bad language/API. I can show you plenty of crappy C/C++ code freely browsable in some open source libraries. Does that mean C++ sucks? Hell no.

My experience with Java+XML you ask? OFX servers for financial institutions. Without name dropping, check out the list of banks, brokerages, tax services, and credit card providers (Quicken) out there successfully serving up client data. I guess we're all circle jerking while you're downloading your account information into Quicken or Money.

Some good uses for XML:

• Ephemeral representations of atomic, structured data; usually for transport.
• Config files. More verbose and the syntax is far better at keeping you from fat fingering a setting and blowing up your app. If you can't clearly read XML, you need glasses.

Some bad uses for XML:

• High volume, rapid response data streams; like say an on-line multiplayer game (though I've never benchmarked this)
• Unbounded data streams; e.g. streaming media
• Databases

I have to admit, I'm clueless about your Java dependency issues. The only way I can see that ever happening is if you're dumping all of your classes into the default top-level package; and that's major user error if you are.

Here, let me fix that for you ...

[trolltalk.com]

If everyone would just use one of the already written XML producers or parsers (the big ones, the ones that work) life would be much easier around here from time to time.

If everyone would just went back to using simple delimited ascii text life would be much easier around here.

Re:Here, let me fix that for you ...

[kyz]

I have, and I can tell you that it's a waste of time.

It amazes me how something that looks so simple can have so many corner cases, and how they can be solved so differently by different implementations.

CSV is fine if you want to store data that has no quote marks, commas, carriage returns or linefeeds. For everything else, please use a better specified format, preferably one that has a formal definition. Like XML, for example.

Re:Here, let me fix that for you ...

[thrillseeker]

I knew we would (d)evolve to punch cards eventually.

Re:Here, let me fix that for you ...

[CaptainPinko]

ASCII doesn't even support the letters needed by the majority of the world's language.

Re:Java and XML, bad tastes that are worse togethe

[bckrispi]

I'll take an Ant XML build file over an "is that a tab or a space" Makefile any day...

Re:10 Years and still waiting

[EMN13]

I use it in web development constantly, and have for about 8 years. It's great for documents mostly since it's much easier to process than a home-grown set up.

You want to transform the document, you can use any of a number of techniques, and trivially guarantee that the resulting document is at least syntactically valid. If you use a home-grown format (or HTML), you'll need to resort to regular expressions, or a custom parser - which works fine up to a point. Regex's are error prone (it's quite difficult, for instance, to make an untrusted HTML document safe with regex'es), and parsing is difficult, and doesn't solve the transformation step very elegantly - wheras XPath and others are absolutely brilliant for quickly distilling the stuff you need from a document.

But on the parsing side... take a look at ANTLR, it's just great :-).

Your comments seem tainted with inexperience.

[sidragon.net]

In general, if you have data to be structured and serialized, XML is one way to do it. If you think XML a poor choice, then could you suggest an alternative? Incidentally, that suggestion should not imply that everyone reinvent their own formats (again).

[N]ot only does Java represent a poor trade off between the annoyances of a strongly typed language and the speed of a dynamic interpreted one ...

Would you provide evidence aside from personal anecdotes, and possibly consider evidence to the contrary?

[Java] has a horrible mess of dependency issues that nobody really solves besides.

Perhaps you meant “modern software” instead. Any complex application these days relies on dozens of libraries and services to perform tasks. Not quite sure where exactly you are having difficulties, so I cannot elaborate further.

[XML] is too ugly and unreadable ... But as a general tool for Internet plumbing it's awful.

XML is intended for consumption by machines first, people second. You might also argue that in-memory data structures are ugly and unreadable.

Re:XML was formalized?

[Jerf]

Yes. XML was formalized. It is strictly defined and easy to check for compliance (with the right tools). Only a little bit of the definition has passed out of common usage, mostly focused around DTDs.

If you encounter a file that claims to be XML, but does not meet the XML standard, then it is not the XML standard that is to blame. The claim is wrong and the file is not XML.

XML is not a fuzzy-wuzzy adjective that can be applied willy-nilly to anything and magically turn it into "XML". It is not a marketing term or English Professor term. It is a rigidly specified engineer term for a document format, and a given document is XML if and only if it meets that format.

If someone wants to hack together a half-assed parser or emitter of any language, they will. I've seen half-assed XML parsers, I've seen half-assed JSON parsers, I've seen half-assed HTML parsers, I've seen half-assed YAML parsers, I've seen ... you get the idea. If a standard can't solve the problem, you can't count the lack of solution against it.

Re:YAML and JSON

[cliveholloway]

<reply xmlns="Slashdot:Comment">
    <paragraph>
        <sentence>What?</sentence>
        <sentence>Are you telling me that this isn't the preferred way of presenting data?</sentence>
        <sentence>Honestly, this &amp; SOAP are two technologies that have made my life so much more &quot;interesting&quot; as a developer.</sentence>
        <sentence>Fucking XML...</sentence>
    </paragraph>
</reply>

Re:10 Years and still waiting

[iamacat]

Here is another obvious rules: If a computer, at any time at all, has to parse or generate XML in large amounts, you are doing it wrong. There is really no need to resend the same string 100000 times, encode multi-megabyte binary data as BASE64 or lose floating point precision by encoding to or from strings. If need be, an efficient binary format can represent the data with an arbitrary schema. Communicating parties can exchange their schemas at runtime and avoid sending attributes that the other end is not going to use.

Re:10 Years and still waiting

[TheRaven64]

Does anyone still use latex2html? All of the TeX users I know who care about HTML output switched to tex4ht years ago. It produces a variety of XML formats, including XHTML (with MathML) and OpenDocument.

Re:Regex

[TheRaven64]

You fail Computer Science 101. Regular expressions are exactly as expressive as finite automata. A finite automaton is incapable of solving the matching brackets problem, since that requires a potentially infinite number of states in order to keep track of the number of open brackets in an input stream. Because of this, a regular expression can not be used to parse any XML schema that allows an arbitrary depth of nesting, since parsing such a form with would require counting the open and close tags to make sure they match, which is not possible with a regular expression.

This is why regular expressions are typically used for lexical analysis (tokenisation) not syntactic analysis (parsing).

Re:Java and XML, bad tastes that are worse togethe

[CoughDropAddict]

So you're the guy who shits tabs in random places in source files, because you haven't figured out how to set up your editor to show you the difference. Please stop doing that. Tabs and spaces are different characters, even if the language you're using today treats them the same. If you're a VIM user, please learn to use "list" and "listchars."