So what's the big deal with XML?
- A standardized format for data files. (heavily oriented towards tree-like formats)
- A system for specifying the structure of files. (XScheme/DTD's)
- A system for transforming one document into different formats. (XSL)
- A syntax for navigating trees. (XPath)
- API's for manipulating XML documents. (DOM/SAX)
- More on the way for sure...
This is all well and good, but was it really necessary to invent such an elaborate structure? My biggest complaint is
that it's just so dammed hard to read. I've never been a big fan of the
<tag> stuff </tag>
format to begin with. Perhaps it was largely intended for data interchange between programs only but now it's everywhere.
Even the venerable
utility is being usurped by
you to specify builds with XML. By the way, I've heard that the C# language implements javadoc-like functionality with XML (!). Maybe in the future
you'll be allowed to write code in any language you like, as long as it looks like XML.
XML is also growing. Here are some recent additions to the language:
- XQuery. Here's the an abstract from a W3C document:
XML is a versatile markup language, capable of labeling the information content of diverse data sources including structured and semi-structured documents,
relational databases, and object repositories. A query language that uses the structure of XML intelligently can express queries across all these
kinds of data, whether physically stored in XML or viewed as XML via middleware. This specification describes a query language called XQuery, which is
designed to be broadly applicable across many types of XML data sources.
This passage is a poster child for lack of focus and mis/over-applied generality (I guess that I shouldn't be surprised that an "abstract" has
these two properties though). The single word "XQuery" tells me more about XQuery than this abstract does.
- XML Protocol - as if the passage above isn't bad enough, here's a very abstract abstract:
This document describes an Abstract Model of XML Protocol.
The challenge of crafting a protocol specification is to create a description of behaviour that is not tied to any particular approach to implementation.
There is a need to abstract away from some of the messy implementation details of buffer management, data representation and specific APIs. However,
in order to describe the behaviour of a protocol one has to establish a set of (useful) concepts that can be used in that description. An
abstract model is one way to establish a consistent set of concepts. An abstract model is a tool for the description of complex behaviour – it is not a
template for an implementation... although it should not stray so far away from reality that it is impossible to recognise how the required behaviours
would be implemented.
This is getting too far out of hand. A person could spend the next four years studying XML. And for what? A standardized data file format?
It's far too late now, but perhaps a different approch would have been better. Let me step away from XML for a moment to explain what I have in mind.
I'm in the middle of developing a game for the PocketPC right now. I needed some type of tool that I can use to build maps with and I didn't want to
spend the time writing an elaborate GUI for map-building. My only other choices left were:
- Use an existing tool (e.g. 3d Studio Max) augmented with some macros or plugins or something like that
- Specify levels in text files which could then be run through an existing macroprocessor (giving a kind of programmabilty) and then fed into my program
I choose option 2. Now at this point, I'm sure that some of you would have been salivating at yet another
opportunity to sneak XML into something.
Now, having a decent macro processor was a definite requirement as the raw data file format was primitive. I wanted to use macros to build complex game objects
(structures) out of simpler ones and macros would make this possible.
So now I had to find a macroprocessor. I considered
but rejected it for one reason: the only conditionals allowed are string comparisons, and
the only comparison allowed is equality. Getting
to play tricks like finding out if a particular number is less than another would probably
suck badly. What about cpp? Well, I ruled out
because it has no looping constructs, which were also a definite requirement.
So I decided to use
. Levels would be given as inline files like:
$txt = << "END_LEVEL"
...level text goes here...
print macro_expand($txt) . "\n";
on any piece of text between hash marks. so there, now I
have a sort of "executable data file", macros, complete programmability and access to tons of libraries etc. So I had a kind of "executable data file".
It didn't end there though. Later on I hit on the idea of embedding the levels as backquoted lists in a
program. That way macroexpansion
would be free (just use the
operators) and my "macros" could manipulate complex data structures (which PERL sucks at)
(actually the data structures wern't all that complex, but PERL still sucked at manipulating them all the same)
So you say: "Big deal, he's using a scripting language with embedded data. So what?" And you're right, it isn't a big deal. Neither is XML for that matter.
I believe that LISP, with it's excellent handling of tree-like structures, would have been a much better format for data files than XML. Think about it: XPath,
XQuery, document transformations and schema validation could all be implemented as libraries of LISP code. And
you'd get a level of programmibility that just
isn't available in XML. As long as every implemented that same LISP and used the same libraries it would be a much better replacement for XML. And if people object
to LISP syntax, then another scripting language could be used.
I guess my point that XML is 1/10 of a programming language already. Why not take a big leap (backwards) and augment something that's already widely-used?
XML will prevail though, encrusted with more "working drafts", "working groups" and
standards as it lumbers "forward" it will someday be recognized for the shallow and overhyped monstrosity that it really is.