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

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.

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.

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

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