In response to planet's reply:

In a discussion thread, a response may seem vague and ill-directed unless the thread is followed in its entirety. Moreover, nickmalik's article was written in direct counter-point to dcpeterson's. The thread there too must be read. In addition, certainly some degree of civility should be maintained; I concur. However, within the discussion threads in response to both articles, there seems to be more than a fair share of hostility directed towards the opposing view, with the viewpoint holders included, i.e., that XML is definitely bad for any want-to-be RDBMS, and potential bad for communication transfer.

However, for my thin-skinned proponents of XML's virtues, you are correct that my profane remarks have directed attention away from the meat of my comments; thus, doing myself and our respective readers a serious disservice.

So, allow me to readdress the article.

First, nickmalik states, “To make it work, XML had to be stateless, scalable, and yet easy to describe and understand. Therein lies its advantage.” I say, therein lies XML’s disadvantage.

"Stateless:

A stateless server is one which treats each request as an independent transaction, unrelated to any previous request. This simplifies the server design because it does not need to allocate storage to deal with conversations in progress or worry about freeing it if a client dies in mid-transaction. A disadvantage is that it may be necessary to include more information in each request and this extra information will need to be interpreted by the server each time."

The concern here, as others have stated, is that XML is bloated. It is also highly dependent upon the hierarchical structure imposed upon it. It may answer one question quite nicely. However, how often does a business unit ask only a single question? This “stateless” and fixed structure nature impose quite a high resource demand and is in direct conflict with the author’s second purported “advantage.”

"Scalability:

It is the ability of a computer application or product (hardware or software) to continue to function well when it (or its context) is changed in size or volume in order to meet a user need."

I claim XML does neither: XML does NOT scale-well with the increase of data transmission nor does it scale-well when we wish to transform it to ask new questions (context). Given the necessity to reproduce the structure imposed upon the document, whenever there is sparse data, not only do we have the encumbrance of all of those tags, we must reproduce them at every iteration, even when the structure contains very little information. Moreover, given the rigidity of the hierarchy, serving multiple users all with varying questions, a particular document quickly becomes useless to all but a very few requestors.

Perhaps as a transfer mechanism, XML could play some part—but I doubt it given its size in-scalability. However, as a means to structure, organize, and store related information, XML can neither protect, enhance, nor address the myriad unforeseen requests by the users. It fails badly for any attempt at data management. Therefore, its use as a storage mechanism is whole ill-thought.

Shall I continue? Let’s.

Our author recommends XML as a superior descriptor of related tables, far and above CSV or EDI. Hogwash. Whether a single CSV file with all of the information contained in each record, or as multiple files, one for each relation, CSV is much more efficient. Ah, but the proponents would say that it is not descriptive. But, neither is XML. You must still transmit that information between transmitter and receiver prior to understanding the intent of the information. How is XML superior in this respect?

Our author states, “Parsers for XML are free, widely available, and FAST.” So are a myriad of other “parsers” for many other formats, CSV included. Now, this is not an advocation of CSV in particular, only that XML holds no special relevance or superiority in this regard. Moreover, we must contend with the resource over-utilization given XML bloat.

Point 3: “Any system can be augmented to read and write XML.” Can we be any more general? Please; if agreed upon, any technology can be “augmented to read and write” that technology. The question is, “Why should we choose XML over other formats?”

Point 4:

“So many software vendors and application architects have seen the value of XML that an entire industry has developed around providing tools for reading, parsing, translating, routing, and managing XML documents. With so many tools available, a developer faced with the need to transfer data from one application to another would be foolish to consider spending time and effort to write components that produced or consumed data in any other format. It's just not productive to write code that someone has already written and tested, which both the developer and customer already have, and which is likely to be supported into the foreseeable future.”

Let’s all get in line. Big brother is watching. So what that there are existing tools. There are many tools out there; we have a choice. It is our responsibility to examine and DEFEND those choices.

Finally, I’ve made my arguments for not storing XML in the DBMS. Re-read them. Or, at least, refute them. Some of you have said the author is only expressing to database external recommendations for the use of XML. That XML “probably” is a bad idea for the DBMS. Oh? What did the author write?

“OK, so XML has its place. But what about inside SQL Server? Why did Microsoft add XML capabilities to their flagship RDBMS system? It was the right thing to do.”

Sounds like the DBMS has it too. Hmmm, no one advocating this position? Problem is, no one is DEFENDING this position. Can I get a witness?!

Edited by - iapetus on 10/27/2003 12:22:32 PM