SQLServerCentral / Discuss Content Posted by Stephen Hirsch / Article Discussions / Article Discussions by Author / What is XML? / Latest Posts

RE: What is XML?

Ninja's_RGR'us — Mon, 15 Jan 2007 13:03:00 GMT

"The second one reads "Mustang for sale: $100.000. 5% Discount if you pay with dimes". My point is that the "Why would I want to?" part can have a lot of explanations. But it's still up to us to choose one. In this particular case, I would put $5.000 against my laziness to gather the dimes. Tuff call... "

Actually it would be a very simple thing to do. You write up a check for 94999.80$ and say here's the balance : and give out 2 dimes . Now you just have to make sure you have proof of the promotion ad and they can't do anything but give you the discount .

RE: What is XML?

Martin Bastable — Fri, 28 Jul 2006 08:40:00 GMT

a developer friend of mine works for a very large company

they spent a long time and much money converting all of their systems and data handling to use xml instead of their custom methods

6 months later, and at great expense, they got rid of xml and went back to the old way of doing it

If I remember, the main reason was performance!

martin

RE: What is XML?

NicholasBritton — Wed, 26 Jul 2006 03:48:00 GMT

Very good article. For some time I have been trying to look beyond the hype about XML to see where it can be truly useful and where to avoid it. This article helps me to make those decisions. I am truly surprised at how many developers use XML for flat data structures (address lists for example) where a database table or even a delimited text file would be simpler, faster, and would take up less space. Moreover, the data is often simply for display and could be hard coded in HTML without the use of an XML file at all. I think some programmers are too quick to jump on the XML bandwagon without stopping to consider these kinds of issues. It reminds me a little of when JAVA was apparently going to take over the world. Like many technologies, the hype settles down eventually and we use them where appropriate instead of trying to use them everywhere.

RE: What is XML?

Umesh Bhavsar — Wed, 26 Jul 2006 01:23:00 GMT

This is really a detailed explanation of XML. I found it very much easier to understand as the examples used are quite self-explanatory.

Thanks,

Umesh.

RE: What is XML?

Joe Landau — Tue, 25 Jul 2006 10:47:00 GMT

Sam C,Sounds like XML would be helpful to me--I also process data on health care providers and fees from several sources. What are the tools or frameworks I should become familiar with? (I use SQL Server and Powerbuilder, but could use scripting languages, too).

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 17:01:00 GMT

Just remember: XML is not a format. It is a format format, akin to a cookie cutter. Cookie cutters usually don't taste very good .

I'd say that the costs of XML languages come in two places: one, lots of people, myself included, find it incredibly difficult to debug, particularly when the data model contains several layers of hierarchy. Two, it is a space hog. In an app I designed, I found that there was a 43x increase in data transmission size over a CSV equivalent file. That killed it right there.

That said, if you've got it to work well, then Mazel Tov! Again, the article was mostly a rant against hype. The kind of hype that gets the management types to insist on requiring XML without a clue as to what they are going to do with it once they've got it.

RE: What is XML?

Sam C — Mon, 24 Jul 2006 16:05:00 GMT

"Let me give you an XML<=>XML nightmare. Let's say you need to convert Tbook to Docbook. You can write XSL to do that, but it would be an onerous task. The fact that both are XML isn't much help.Unless, of course, someone has already built it for you."

What's your point? Name ANY technology, past present or even future, and I will show you a situation where using that technology would be an absolute nightmare. Of course there are situations where XML is not appropriate. But there are many where it's just what the doctor ordered.

"From what I gather from your response, you do have to do a lot of recoding when the schema changes. You've standardized on a data transfer format, which is good, but you still have lots of work to do. Using XML saved you some, I guess."

And that's exactly my point. The amount of recoding was reduced substantially by moving to XML.

"I did something similar with SAS Version 5 XPT format datasets. The absolute worst data format in the world. However, there were many parsing and conversion tools already written, which also made the conversion/parsing tasks trivial. In other words, you don't need XML to accomplish that."

Nobody is claiming that you need XML for EVERYTHING. But you must admit that for a large number of tasks XML makes life easier for everybody. The same way you used existing tools to make the conversion/parsing trivial, a lot of people are using xml tools in a way that makes their programs a lot easier than before, sometimes trivial. You are ignoring the great advantage that comes from adopting a format that's shared by many. Could it be better? maybe, but that's not the point, the fact is: XML has been adopted by many and it works, so why not use it? Do you have an alternative? What do you suggest we use to exchange information? Say you came up with a clever data model and an amazingly powerful compression algorithm to send data over the net. Who would consume your data? You would have to provide API's for different platforms in order to enable others to manipulate your new format programatically. And of course, you would have to convince everybody that your way is "better", existing programs would have to be modified, there would be a need for specialized tools to handle special cases, etc, etc. That was the situation when XML came out, and it won hands down over other alternatives, why do you think that happened? Because the majority of programmers saw the utility of the new format and adopted it. Until someone comes up with a better way (and someone will, for sure), XML is here to stay.

"And XML costs alot."

I don't know what you mean. Does it cost a lot in terms of development time? bandwith? learning curve? For each of these, the answer is, as usual: depends on what you want to achieve. It's the same with hardware: A $500 graphics card by itself is neither cheap nor expensive, it depends on what you want it for: if it's for your grandma's computer so she can use aol, you are paying too much, but if its for your latest and greatest gaming rig, it may be the best part of your system.

RE: What is XML?

David.Poole — Mon, 24 Jul 2006 15:28:00 GMT

Consuming XML isn't hard, it's digesting it and it makes my eyes water to parse it.I've used it for what it is supposed to be used for. Separating content from presentation.When it is used for what it was originally intended it works.I'm just waiting for a gently lobbed D.C.Peterson handgrenade.

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 15:14:00 GMT

"Actually, that statement is true when the data model agreed upon is XML, because once that's done, the data processing is very simple."

Data models are independent of their representation. When you create an XML language (remember, XML itself is nothing), then you have access to parsing tools and format conversion tools. That's not nothing, but nothing to write home about, IMHO.

"In some cases though, if the data model is not XML, the complexitiy of processing the data may take a big chunk out of the developing time. For an extreme example, think about a Java shop receiving Excel files from a Microsoft shop. Regardless of this, however, my main point is that by adopting XML as a standard, everybody concentrates on the data itself and the processing is left to the already highly optimized (and free) tools that are available in all platforms. It's a win win situation."

Let me give you an XML<=>XML nightmare. Let's say you need to convert Tbook to Docbook. You can write XSL to do that, but it would be an onerous task. The fact that both are XML isn't much help.

Unless, of course, someone has already built it for you.

"I use XML to process information we receive from several vendors on health care providers and fees. The data models are very simple, nothing fancy here, but we were having a hell of a hard time trying to adapt to all the different formats the vendors were using (csv, excel, access, fixed width text files, etc). We convinced most of the vendors (not all, it never works that way) to switch to XML and it's been great for the most part: Our code can detect if a new field was added or deleted from the schema. If deleted, it will be ignored, if added, a new column willl be added to the appropriate table with the appropriate data type, and then the file will be imported. Of course, we know that the changes to the schema are never too large, it's usually a couple of fields added or deleted, I'm not claiming this is something that can be used to handle ANY schema regardless (it would result in a rather ugly looking database table). Most of the effort goes into changing existing stored procs and reports to add the new column where appropriate (or delete it if necessary). But the main point is that we seldom have to deal with the data directly. Before XML, changes to a file's layout usually required recoding of our applications AND our stored procs/reports."

From what I gather from your response, you do have to do a lot of recoding when the schema changes. You've standardized on a data transfer format, which is good, but you still have lots of work to do. Using XML saved you some, I guess.

"I don't know what you mean exactly by a dynamic data model, but we are not doing anything fancy. The files we get come with their own schemas, but we first validate agains the old schema. If the validation succeeds, we move to the next stage to process the data, if not we determine the differences by comparing the new and old schemas and proceed as explained above. If this sound too simple, it's because it really is, and that's exactly my point, by using XML this type of tasks have become rather mundane."

I did something similar with SAS Version 5 XPT format datasets. The absolute worst data format in the world. However, there were many parsing and conversion tools already written, which also made the conversion/parsing tasks trivial.

In other words, you don't need XML to accomplish that. And XML costs alot.

RE: What is XML?

Sam C — Mon, 24 Jul 2006 14:49:00 GMT

>> If you agree on a data model, that's 95% of the effort.

Actually, that statement is true when the data model agreed upon is XML, because once that's done, the data processing is very simple. In some cases though, if the data model is not XML, the complexitiy of processing the data may take a big chunk out of the developing time. For an extreme example, think about a Java shop receiving Excel files from a Microsoft shop. Regardless of this, however, my main point is that by adopting XML as a standard, everybody concentrates on the data itself and the processing is left to the already highly optimized (and free) tools that are available in all platforms. It's a win win situation.

>>Sam, may I ask, what are you using XML languages for? How complicated are your data models?

I use XML to process information we receive from several vendors on health care providers and fees. The data models are very simple, nothing fancy here, but we were having a hell of a hard time trying to adapt to all the different formats the vendors were using (csv, excel, access, fixed width text files, etc). We convinced most of the vendors (not all, it never works that way) to switch to XML and it's been great for the most part: Our code can detect if a new field was added or deleted from the schema. If deleted, it will be ignored, if added, a new column willl be added to the appropriate table with the appropriate data type, and then the file will be imported. Of course, we know that the changes to the schema are never too large, it's usually a couple of fields added or deleted, I'm not claiming this is something that can be used to handle ANY schema regardless (it would result in a rather ugly looking database table). Most of the effort goes into changing existing stored procs and reports to add the new column where appropriate (or delete it if necessary). But the main point is that we seldom have to deal with the data directly. Before XML, changes to a file's layout usually required recoding of our applications AND our stored procs/reports.

>>BTW, how in the world do you do dynamic data models in XML? Inquiring minds wanna know!

I don't know what you mean exactly by a dynamic data model, but we are not doing anything fancy. The files we get come with their own schemas, but we first validate agains the old schema. If the validation succeeds, we move to the next stage to process the data, if not we determine the differences by comparing the new and old schemas and proceed as explained above. If this sound too simple, it's because it really is, and that's exactly my point, by using XML this type of tasks have become rather mundane.

Not to say that everything XML is simple or that everything non-XML is more complicated than it should be, but there is definitely a reason for all the XML hype.

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 13:51:00 GMT

"This article is primarily complaining about the hardness of certain problems and then castigating XML for not magically solving them."

That was precisely the point of the article. XML is (often) sold as magic, when it is anything but. I go into a few of the problems with XML in the article, but it is mostly a rant against the hype.

I wrote (in 1999):

"Data transfer standards are fine, and XML is as good a choice as any. Just don't think that it won't take its pound of flesh, just like every other technology known. My guess is that it will be one of those technologies of the future that always remain so."

I leave it to you whether I was a prophet .

RE: What is XML?

Robert Rossney — Mon, 24 Jul 2006 12:49:00 GMT

I am underwhelmed by this article, and not just because it's dated. (DTDs?) Most of the problems the author attributes to XML are in fact problems associated with the application domain that he's trying to apply XML to. It's hard to get the pharmaceutical industry to define and adopt a common data model? That has *nothing to do* with XML.Similarly, the complaint that XML isn't inherently readable, and that you have to write XSLT to convert it to HTML for presentation, is muddle-headed. What format for representing structured data in a transportable form *would* be human-readable? CSV? JSON? The complaint that XML is hierarchical is also bogus. It's perfectly straightforward to represent data relationally in an XML document, if you have to. It's just that for most uses of XML, where an XML document is a concise and transportable bag of information that can be parsed into an object model, representing relationships hierarchically is easier. Since object models represent hierarchies, and they represent them because the hierarchies actually exist in the real world that the objects are modeling, a far more apposite complaint would be that relational databases do a poor job of modeling hierarchies. If you're going to get into this at all, which you shouldn't. This article is primarily complaining about the hardness of certain problems and then castigating XML for not magically solving them. A *good* article about XML would have addressed the simple question that kagemaru asked:> In most of cases, they will state together what will be the > XML structure to have their program running well : So, what > is the difference with a csv file ?Well, what *are* the differences between representing data in XML instead of CSV? Here's a couple off the top of my head:- XML provides a good way of representing hierarchies. CSV doesn't.- XML documents can be reliably parsed into an object model that can be programmatically manipulated; this object model is implemented in a standard way on many different platforms. Not so for CSV.- A powerful (if daunting to learn) platform-independent language for searching through XML-based object models exists. Not so for CSV.- Standard, platform-independent tools for defining the format and organization of XML doucuments and validating that a given document contains what it's supposed to contain exist. Not so for CSV.- Standard, platform-independent (are you detecting a theme?) tools for transforming data in XML documents into other formats (in particular, into HTML, for presentation) exist. Not so for CSV.- There's a consistent way of programmatically verifying that the data in an XML document hasn't been corrupted or truncated in transit. Not so for CSV.- XML documents tell you their character encoding. CSV documents don't.Now XML has plenty of drawbacks. Above all, it's not terse. This drives people crazy: all those redundant closing tags and repeated attribute tags. That's part of the cost that you pay for representing your data in a transportable form that can be programmatically validated and transformed by platform-independent tools. If you don't need those things, you shouldn't be using XML.Also, namespaces and CDATA are hard to understand. I'd contend that if you're using XML and you don't understand namespaces, you probably don't really understand what XML is yet and you probably shouldn't be using it.Finally, since any clown can write an XML document, lots of clowns do. It's a general-purpose format for representing data, and as such, it lets you make all kinds of stupid mistakes if you don't know what you're doing. Pick up just about any "introducing XML" book and you'll find an inadvertent compendium of worst practices.XML is a technology that addresses a lot of hard problems better than any other technology we have. If you don't need those problems solved (as the author of this article clearly doesn't think he does), you shouldn't be using XML. Robert Rossneyrbr@well.com

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 12:45:00 GMT

"Compare that with the XML solution: once you agree on a particular schema (including a DTD), all the grunt work is already coded in most XML frameworks, you only worry about processing the data."

If you agree on a data model, that's 95% of the effort . Sam, may I ask, what are you using XML languages for? How complicated are your data models? There's no question that with enough effort, you can get XML to work; it's just, can you get it to work well?

BTW, how in the world do you do dynamic data models in XML? Inquiring minds wanna know!

RE: What is XML?

Sam C — Mon, 24 Jul 2006 12:20:00 GMT

>>I have not see any developer using DTD to handle dynamically different document formats.

Just beause you haven't seen it doesn't mean it's not good or it's not being used by others. In fact I have used it in a way that makes maintenance of my applications a lot easier than before. I process data from multiple vendors and they of course change their formats frequently. Having code that will dynamically adjust to a change in the XML schema has been great for me. But of course, beauty is in the eye of the beholder, so I'm not claiming everyone should be doing that. In the end XML is one more tool that happens to work for many of us.

RE: What is XML?

Taconvino — Mon, 24 Jul 2006 12:08:00 GMT

"No argument there. My point is that XML languages (I feel like the GNU/Linux guy) don't do anything but markup text well. I can buy a car with dimes. Why would I want to?"

That's a good point. But still, a tool is a tool, and as such, you can't expect it to do the work for you, nor it will make it better if you don't use it properly. Think of it as two different car dealers. Each of them has a sign out front. The first one reads: "Mustang for sale: $100.000". The second one reads "Mustang for sale: $100.000. 5% Discount if you pay with dimes". My point is that the "Why would I want to?" part can have a lot of explanations. But it's still up to us to choose one. In this particular case, I would put $5.000 against my laziness to gather the dimes. Tuff call...

Yes, XML does nothing more than formatting text well. But, if that's what I need, it just might worth the shot. Why not? Everyone else seems be using it! (just kidding... )

RE: What is XML?

Sam C — Mon, 24 Jul 2006 12:06:00 GMT

Just to throw some balance to the discussion, let me be the lonely voice of dissent.

What the author says about XML could be said about almost any other technology available to store/share data. There is no universal solution that can be adapted to every case. For simple cases, an old fashioned text file is more than enough, but as the complexity increases so does the solution. Files used by a single application can be whatever a programmer wants and they usually work fine, but as applications begin to interact with one another the simple solutions show their limitations. Interaction implies well defined interfaces, and XML provides an great way to describe and publish an interface. Not the only way, for sure, but it has distinctive advantages over other ways like COM, IDL, header files or EDI. If you program in an isolated environment this is a non issue, but if you need to write programs that consume data from vastly different sources, you need some standard. Enter XML. The wide adoption of this format has made it the de-facto standard, and that's something GOOD if you are in the business of data publishing/consumption.

By claiming that XML is overly complex, the author is ignoring one of its key features, which is the fact that there is a standard, and this fact has made possible the development of many tools and language constructs (most of them freely available) designed specifically to deal with all the complexities of XML. This is what makes XML a good choice for many projects (notice I don't say "for every project"). As an example, compare with the still popular comma delimited file: If you are processing information sent in that format, you either trust each line has the same number of fields or write code to deal with exceptions. Same for the actual data: if the third field has to be a date, you have to write your own code to check for it. In general, you end up writing code that is custom made for a particular file, and if the the file format changes, you usually need to change your code. Compare that with the XML solution: once you agree on a particular schema (including a DTD), all the grunt work is already coded in most XML frameworks, you only worry about processing the data.

Maybe in the old days XML had to be manually processed and validated, but we've come a long way, and nowadays most XML traveling the net is never seen directly by any user, it's just processed by highly optimized code that works precisely because for once we have a format with almost universal acceptance. I don't see anything wrong with that.

If you don't like XML, you are free to use whatever format you like, but if you need to interchange information with the rest of the world, don't expect everyone to adapt to your own format. In fact, just about everybody already adapted to XML, so why not use that to your advantage?.

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 11:46:00 GMT

"How do you create or consume XML from within your programs?"

First of all, let's ban the word "consume" from any discussion of data . That includes "web services"

Oracle has very nice conversion functionality between XML and its relational model. I'd look there first.

"XML is a markup language technology (as it's name clearly states), and as such, it can be used for anything we want (yes, including data storage/transfer/formatting/etc... just as HTML)"

No argument there. My point is that XML languages (I feel like the GNU/Linux guy) don't do anything but markup text well. I can buy a car with dimes. Why would I want to?

RE: What is XML?

kagemaru — Mon, 24 Jul 2006 11:44:00 GMT

Hello,I have not waited XML to put a word document between two ###VERYLONGDOCUMENT### and tell my remote client to use these tags to decode. XML is an xtremely marketed language (add some XML stuff in your resume), I can not still see where the revolution is.I have not see any developer using DTD to handle dynamically different document formats. In most of cases, they will state together what will be the XML structure to have their program running well : So, what is the difference with a csv file ?

RE: What is XML?

Taconvino — Mon, 24 Jul 2006 11:36:00 GMT

Very good article! Although there's a point I don't agree with: XML is a markup language technology (as it's name clearly states), and as such, it can be used for anything we want (yes, including data storage/transfer/formatting/etc... just as HTML).

XML is not the problem. The real problem begin with us (developers), trying to use it for everything. As an old saying goes: "With a hammer in my hand, every problem looks like a nail".

IMO, XML has its place somewhere... it's up to us to find such place, that is most likely different for each one of us. Try to see if the nail has some markings on its head before you start hammering away. Yes, a hammer will drive the screw in any way, but maybe a screwdriver can get the job done faster and without so much effort.

RE: What is XML?

Joe Landau — Mon, 24 Jul 2006 10:58:00 GMT

A good article; thanks. If you ever get the urge to do another, I've long been looking for the answer to: How do you create or consume XML from within your programs?

RE: What is XML?

Stephen Hirsch — Mon, 24 Jul 2006 10:53:00 GMT

Thanks for all your kind words. A few thoughts.

As it says in the heading in italics, I originally wrote this 7 years ago. I couldn't get it published then, because it was (and still is, really) counter to the current orthodoxy. I really don't understand the allure of what is essentially a failed idea.

What are XML languages good for? A major clue is in their name: markup languages. Markup languages are created for marking up text. They're not created for, nor are they good at, data transfer or data storage.

Finally, if you do use XML for whatever reason, I strongly recommend sticking with DTD's, as opposed to the far cooler XML Schemas. In my opinion, the extra you get from schemas is not worth the extra obfuscation; in addition, schema processing is still pretty immature. During my time trying to implement the SPL project for the FDA, the official schema compiled in XMLSpy (as an XML file) but didn't compile in another tool (as a schema). What do you do in that case?

RE: What is XML?

DavidSimpson — Mon, 24 Jul 2006 10:45:00 GMT

Good article. Unfortunately we are stuck with a vendor that thinks XML is the best and only solution to data transfers, yet they have not idea how to properly format the XML and don't believe in a DTD's or schemas. Basically all they deliver is a text file with tags and all we get is a bunch of headaches. I still believe XML has it’s place but after being forced to use it, I'm starting to think that it’s just a buzz-word used by management and resumes.

David

RE: What is XML?

A.J. Wilbur — Mon, 24 Jul 2006 10:02:00 GMT

Awesome article. You said what we were all thinking. "Who actually uses this crap?"

RE: What is XML?

peter-258331 — Mon, 24 Jul 2006 09:50:00 GMT

Just plain out of date.

RE: What is XML?

Steve Lackey — Mon, 24 Jul 2006 09:48:00 GMT

I'm not sure that XML was intended to be a language to fully encode reality between the angle brackets. Nor is every use case possible to capture. But for the really dull ones, like exchanging business documents, the world will not miss the hours p-ed away manually coding flat ASCII mappings between EDI, Some Guy's Clever Markup Scheme, and your RDBMS. What it offers is a lot more reuse. It's not very good as a primary data store, but it makes the transfer of complex data easier, and using standardized parsers for manipulating it are easier than writing your own. It's just one tool among many, though a useful one.

RE: What is XML?

Timothy Blank — Mon, 24 Jul 2006 09:41:00 GMT

THANK YOU THANK YOU THANK YOU especially for pointing out that XML is heirarchical -- I've been fighting very frustrating battles with people who believe in the next silver bullet but have no appreciation for data modeling. The hard fact that people need to get is that data modeling has nothing to do with any particular technology and and everything to do with understanding the business.

RE: What is XML?

JJ B — Mon, 24 Jul 2006 09:38:00 GMT

I appreciate this article for it's objective voice. I've long felt the same way, but it feels like nice vindication when someone else posts similar thoughts.For most of my data transfers, I still feel that a the good-old comma delimited text file is peachy-keen. However, if I have to transfer long narratives/text fields, it seems like XML is the way to go. What do other programmers use when you have to transfer large text fields?

RE: What is XML?

Stewart Joslyn — Mon, 24 Jul 2006 09:06:00 GMT

Note that even .NET uses binary internally - not everything is XML.I agree wholeheartedly with the article. The systems at each end still need to know the schema so its no different to a binary struct - just bigger. The only advantage that I can see for XML - and it can be a big one - is that its human-readable which makes debugging and investigation a lot easier. ... but then you can write a simple decoder for any other structure.

RE: What is XML?

YSLGuru — Mon, 24 Jul 2006 07:47:00 GMT

Thank you sooo much for writing an article that is an honest look at XML and not one that’s nothing but another praise of XML and how XML is the second coming in the programming world. I’m so fed up with hearing how XML will solve every known computer related problem. Personally I have no issue with Microsoft integrating XML into dotNET or even into SQL Server 2005 but I do have issue with them selling XML as the end all in development and making it sound like as if everything needs to be converted to XML as soon as possible.

XML is just another tool in a developer’s toolbox and anyone who sees it as anything else is fooling themselves. I have seen many am articles and related pieces on the net and in print talking about how developers who want to stay in demand need to jump on the XML bandwagon ASAP, leaving everything else behind. IN a few years, after a sizeable number of companies and users have tried to ‘do it all in XML’ have been thru the process and realized the folly of substituting everything else for XML, things will swing back to normal like they are now and XML will be viewed as no more then what it is, another method, option or tool for working with software.

The smart developer will learn how and when not to use XML as well as how to use it.

RE: What is XML?

Jeff Gray — Mon, 24 Jul 2006 07:42:00 GMT

Every time you use XML, God kills a kitten.

RE: What is XML?

SuperDBA-207096 — Mon, 24 Jul 2006 05:52:00 GMT

Stephen,

Nice article! Finally a simple explanation of XML!

Mark

RE: What is XML?

Brett Anthony — Mon, 24 Jul 2006 00:19:00 GMT

Yes the hype is crazy, I thought it would have died down by now but its still going strong!

As my Dad once said to me "Horse's for coarse's".

A great saying, and it simply means this, XML isnt the only way of transporting data, it's just ONE of the many ways you can transport data! If size is a problem, then use something else. No one has a gun to anyone's head telling them they must use XML, use it when it fits best. For some applications it works great, as a data store, Im sure there are other better formats. There was some huge debate over SQL2005 handling XML data types. I couldnt see the fuss, if it doesnt work for you then dont use it, and if you want to use it, its always there as an OPTION! Dont limit yourself, you only cage yourself in. Ide prefer to have a toolbox full of tools for every occasion, I dont have to use them all, buts its always good to have it just in case?

Also dont forget that DTDs are being phased out over the "Schema", basically XML describing itsself.

Good article dude, keep it up.

RE: What is XML?

pete callaghan — Sun, 23 Jul 2006 22:20:00 GMT

At last sanity!. XML is just another technical solution in search of a problem.

Many years ago a user said "We have a problem sending our orders to xyz co. ltd - their system doesnt understand our systems data format". A passing techy thought "I could fix that!" and suggested xml. Therby missing the point completely.

The real issue when communicating data twixt diferent systems is not that system B does not know which field holds system A's stock code, its that a stock code on system A is "00123" but on system B its "WIDGET01". XML doesnt begin to address this.

Good data storage mediums are simple, efficient and transparent to applications. XML is complex, massively wasteful of storage and computationally an open ended black hole. It is fundamentally inappropriate as a data storage medium, and a poor choice for data transfer.

Cage rattled ?

What is XML?

Stephen Hirsch — Thu, 22 Jun 2006 13:45:00 GMT

Comments posted to this topic are about the content posted at http://www.sqlservercentral.com/columnists/shirsch/whatisxml.asp