Slashdot Mirror
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?'"
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.
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.
Comment forecast: Bits of genius surrounded by a sea of mediocrity.
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
.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
As you say, YAML is a specialized markup-language (data-centric, almost human-readable) and not a good choice for many use-cases (document-centric languages like XHTML and DocBook, combining languages with XML namespaces). In other words, it can not replace XML, it's just another syntax to learn. It needs a completely new infrastructure: new parsers, new editors, new schema description language, new translation languages and so on. Is that really worth it, only to make editing files with a simple text editor easier?
Java is clearly moving away from the massive over-use of XML in everything from configuration to messaging. From Java 5 onwards, annotations are rapidly becoming the configuration mechanism of choice, where infrastructure configuration is placed in the source code directly, in a way thats significantly less obtrusive than writing code to manage things like persistence and transactions yourself, and significantly easier to follow than placing it in many XML files. Anyone who has migrated from EJB 2.1 to 3.0 for example should be much happier now that the various XML files needed to get it to run are going the way of the dodo. This use of annotations to replace XML is an emerging trend popular in many frameworks, from EE 5 through to Hibernate and Spring. On the messaging side there are a slew of code generation tools and XML-to-POJO (annotation-based) mappings that keep you away from raw XML - yes its another layer of abstraction but it keeps you away from the coding horrors of SAX, DOM, and yes even the comparative simplicity of JDOM.
Regex are not a solution to everything, and most certainly not to writing fast parsers!
(Not that XML is easy to parse fast, but that's another story. You still don't write a JSON parser using regex.)
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.
I am TheRaven on Soylent News
"Ever tried parsing CSV?"
All the time. Its not that hard. Also, if you're worried about such things as quoting, etc., you can always use fixed-width fields - makes indexing, looking up, and modifying values REAL FAST. Compare that to the mess of xml.
Kevin Smith on Prince
This is why regular expressions are typically used for lexical analysis (tokenisation) not syntactic analysis (parsing).
I am TheRaven on Soylent News
No, you cannot with a regex. If you can, it's not really a regex, it's something different.
Please, for the good of Humanity, vote Obama.
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."
If you think XML a poor choice, then could you suggest an alternative?
Depends on the problem you're trying to solve.
A hell of a lot of the stuff I'm seeing in XML these days would be better off as token-separated self-describing tables (tables where the column names are the first row), or a modestly extended token-separated format like CSV.
For binary data something derived from Electronic Arts semi-self-describing interchange file format is good, examples in current use are MIDI File Format and Portable Network Graphics...
For arbitrary self-describing data there's always ASN.1.
For tagged arbitrary chunks of data descendants of RFC-822 are common.
For shallow-nested keyword-value data there's Microsoft's INI files.
And, of course, Lisp S-Expressions do absolutely everything XML does, more compactly, and are easier to parse.
Incidentally, that suggestion should not imply that everyone reinvent their own formats (again).
But XML doesn't solve that problem. I've found that the amount of code it takes to extract data from an arbitrary XML file even with an XML parser at hand is not significantly less than the amount of code it takes to parse and extract data from any other self-describing format.
Wrong - the special null delimiter is needed only for variable-length (and zero-length) fields and records. For fixed-length fields and records, no delimiter is needed.
For example: First Name\0x00Last Name\0x00Age0x00\0x00
Joe\0x00Blow\0x0042\0x00\0x00
Mary\0x00Doe\0x0024\0x00\0x00
\0x00Cowboyneal\0x00\0x00\0x00
In the above example, Cowboyneal has no first name and no age.
What's so hard to understand about that? For a fixed-length field?recordset, just include a header ...
FirstName:10:LastName:10:Age:3\n
Joe_______Blow_______42\n
Mary______Doe_______24\n
__________Cowboyneal___\n
Both are human-readable, both are easy and intuitive to parse out, the second one is self-documenting and fully supports random access, etc (and neither one is new - the first is used on most *nixes, with either a : or | instead of a null, databases have been using the latter format for decades).
By contrast, xml is an abortion. Heck, I'll go further - xml is the ultimate triumph of navel-gazing over real-world experience.
Kevin Smith on Prince