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.

Oblig

[mariuszbi]

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

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.

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