Here's some good news, at least IMO. I think the future of VRSN is in it's ecommerce directory listing of their clients. The competition is XML and it don't look good for them dudes. I mean, suppliers need to find customers, and where else to look for them than a listing of all web sites who have a verising certificate? Would you look at a Yahoo search of XML queries that could be weeks old? I prefer real time datter.
Master Builder: The Truth About XML
(10/15/99)
I love XML. The notion of a platform- and language-neutral way to move data between otherwise incompatible applications is a long-held dream in the technology universe. But with all of the hype surrounding it, some Web builders have misunderstood what XML is all about.
First, the basics: Extensible Markup Language is a "a method for putting structured data in a text file," created by the World Wide Web Consortium (W3C). The W3C has provided a very clear (if not entirely unbiased) explanation of XML's salient features and purposes.
Used for its primary purpose, data exchange, XML is a wonderful idea with marvelous implementation. Unfortunately, it's not perfect. It was, after all, designed by humans--a committee of them. Nonetheless, XML has shown a remarkable ability to thwart the usual committee tendency to bloat and compromise. The result is an easy-to-understand markup language so vastly superior to its predecessor, SGML, that its roots are barely even detectable.
The problem is that I've seen far too much evidence of two huge misapplications of XML. I'm concerned that this will not only confuse the populace, but also pull XML in the wrong direction.
What are these inappropriate directions?
Read on.
Back to top
I've seen numerous books, articles, and discussion group posts indicating that XML is an application tool of some sort or is a replacement database. Neither of these uses is appropriate, and I strongly encourage you to resist any attempt to convince yourself otherwise.
XML is not amenable to an application development tool, and it can't possibly be used as one. Why? It contains no procedural or functional capabilities at all. None. Nada. Zip. XML is designed solely for the text-based storage of structured data. It doesn't even understand the notion of doing something with or to that data.
On a recent trip to my favorite bookstore, I picked up a book purporting to teach me how to build XML applications because I wondered what it could possibly contain. It turned out the book was actually about building Java applications that use XML data. I suppose you could stretch the definition of an application to emphasize the underlying data rather than the programming language, but that seems a tad disingenuous. This book wasn't shelved with the 3,879 (estimated) other Java titles, which probably gave it a marketing edge of sorts (unless, of course, you happened to be looking for a book about how to write Java apps using XML). But there's no such thing as an XML application. There never will be.
The other inappropriate use I've read about for XML is as a replacement for databases. This is a little different from the application misuse (which isn't even possible) because you can in fact use XML as a replacement database. You can also probably figure out how to write all the applications necessary to run a small business and stuff them into a PalmPilot, but that won't necessarily be a good solution, let alone the best use of technology.
XML is not appropriate as a database language for two principal reasons: its verbosity as a markup language and the need for customized data-parsing routines.
Am I criticizing XML's verbosity? Not at all.
Read on.
Back to top
The verbosity of XML is a good thing in many respects. But I recently took a 300K database file using a popular database application, wrote an XML DTD (description) for it, and then saved it using the XML format. The resulting file was 6MB. And I tried to make my custom tags relatively sparse but still understandable. For example, I didn't use <STREET_ADDRESS> for that database entry but rather <STREET>. I did, however, opt for the more verbose open-close tag syntax. In other words, I used <STREET>123 Elm</STREET> rather than the equally valid <STREET value="123 Elm">. I find the latter (referred to in XML documents as an "empty" tag) more difficult to parse in code, because you either have to know in advance how many attribute-value pairs you'll encounter or write a fairly complex generic routine which will be slow to execute.
This explosion of file size should be enough to discourage you from treating XML as a database replacement. But to add fuel to the fire, the need to write custom and sometimes quite complex data parsing routines to deal with each new type of data represented in an XML file should really give you pause. Coding parsers for exception handling, variant record structures, and other fairly common business issues would be cumbersome indeed.
By all means, adopt XML. But use it for its intended purpose: textual representation and storage of structured data so that it can be transferred between otherwise incompatible applications.
Do you have an example of a really bad use of XML? Or, can you give me an example that proves one of my points wrong? Just have a different opinion? Sound off by posting your comments
|
