From: MR

To:  Editor

 

I wanted to comment briefly on Mr. Pascal’s latest (and very good, I might add) article on the folly of XML.

 

Although I am in full agreement on many of Fabian’s points, namely that XML is *almost* wholly worthless, I will say that we’ve been able to use it successfully in a single area -- data gathering from disparate sources. The issue is the assumption that one has ‘agreed upon’ data -­ we’re performing automated data exports from customers' systems which may contain more or less data than we need (and in different formats: DBMS, flat-file, etc.).  Since it is automated, we can simply push XML Schema documents (XSDs) to the automated clients (or have the client pull them from the server), the client then runs some SQL (if we have data that lives in a SQL DBMS, for example), generates XML based upon the schema, zips it up, then sends it to the server.

 

Why do we send XSD docs to the clients?  Well, one of the applications’ requirements was that it had to be a ‘write once, run anywhere’ type system -- the last thing we wanted was to develop a custom application for each customer.  Depending on the customers' data source, we have different data requirements ­ so the XSD allows us to request different data on a customer-by-customer basis.  Since we occasionally change what data we need, we also needed the ability to request different data from an existing client.  So, we can make a few tweaks to the XSD, give it to the client, and let the new data come flowing in.

 

Of course, we could accomplish the exact same thing with delimited (or other flat) files ­ the issue we found was in rolling our own, proprietary definition format (to replace the XSD) and then writing our own libraries to take our raw data and massage it into the format specified by the format document.  We’d be perfectly happy sending the data without using XML (and perhaps better off without the bloat), but the tools out there make it available to very easily write code to perform what we need.

So, there's no real inherent superiority in XML over other flat-file methods -- vendor support and a standards-body make it 'useful'.

 

I will agree completely that XML has *no place* as a storage mechanism/model, but it may have a use (or two) as a transmission mechanism.

 

 

From: Fabian Pascal

To: MR

 

Which article you read? In the last one I submitted, I demonstrated that it is a poor choice for data transmission too.

 

 

From: MR

 

Correct, it is almost always bad.  In my first email I gave a situation in which we found it advantageous to use XML as a transmission mechanism, not for any inherent superiority of XML over something like a CVS file, but simply because it was the easiest to code due to our specific situation and the already-coded libraries provided in the host language.

 

If we were forced to code everything by hand (a validation scheme, et al) we'd have gone the CVS method in a second!

 

 

From: Fabian Pascal

 

Yes, but only because it was already there. Had there been a better [more efficient] format, you could have used that better.

 

Once there is agreement on a format, then there would be no need to code anything [it would be generated by systems.] That would hold for any format, not just XML. It's the agreement that counts.

 

 

From: MR

 

Exactly.

 

Yup; the issue with our system was that the format changed with some frequency, and rather than hard-code output formats we read it in from an XML Schema Document -- the XML Schema Document is the only thing that changes, not the output/input routines.  Again, I am not saying XML is better than CSV (it's worse as you pointed out), it just happened to fit our needs.

 

 

From: Fabian Pascal

 

Since most practitioners do not understand fundamentals, if I were you I would never defend XML publicly for any reason. You are going to be misinterpreted.

 

 

From: MR

 

Hm, I'm not sure if that's a good thing or a bad thing, but I do know I dislike XML enough to never defend it.

I hope my email didn't come across as an endorsement (it certainly isn't a ringing one if that!), just a use of XML that, albeit somewhat successful, has nothing really to do with the technical merits of XML.

 

 

From: Fabian Pascal

 

What I am saying is that if you express what you wrote me publicly, it most certainly would be interpreted as an endorsement and if that is not what you mean, then don't.

 

Posted 03/21/03

 

 

 

[ABOUT] [QUOTES] [LINKS]