SQLServerCentral / Discuss Content Posted by Don Peterson / Article Discussions / Article Discussions by Author / Is XML the Answer? / Latest Posts

RE: Is XML the Answer?

Richard.Halter — Wed, 14 May 2008 20:48:35 GMT

By creating an incredibly bigoted paper, you lost your credibility. When one chooses only that which supports their predetermined conclusion, they do an injustice to a good analysis.If one properly chooses selected components of RDBMS, one can make exactly the same kind of claims. For example a RDBMS is not a good way to send information across the internet. Talk about a large footprint. If this is all one considers, one could conclude that RDBMS is something one should avoid.BTW do you use Vista? If so then you are heavily invested in XML as it provides the underlying communications for Vista. I don't see a performance penalty. Vista appears to work pretty well.You have some good points but you've selectively chosen those things at which XML is not good and reinterpreted others to fit your conclusion.I'm amazed this article was printed twice.So something so bad performs extremely well in proper real use.

RE: Is XML the Answer?

Anders Pedersen — Mon, 05 May 2008 11:49:22 GMT

The place I work now use XML, a LOT. And a lot of the time in the wrong ways. Luckily we have finally agreed on a standard: Relational data in the database and as results, unless it can be proven that XML is the right/best way to do it. I.e. it is up to the developer in question to convince us during peer design reviews that he needs to use XML.

RE: Is XML the Answer?

Stephen Hirsch — Fri, 02 May 2008 16:21:14 GMT

Sure, in Unix it does. I meant lexically, like in human languages.If you're putting Unix commands into the data, then yes, you'd have to find something else. I don't think that that would occur very often, though.

RE: Is XML the Answer?

Wayne West — Fri, 02 May 2008 16:17:15 GMT

[quote][b]Stephen Hirsch (5/2/2008)[/b][hr]..."I've never heard of the grave character. I'm going to look into it. I'm sure my peers in the other agency would appreciate an alternative to reading my XML files."Sure. It's the lowercase key next to the "1" on US keyboards (other keyboards, YMMV)[/quote]It's also the unshifted tilde (~), unshifted it's the accent grave. IIRC, it's used in *nix BASH scripting, but I don't remember what for, but apparently it has quite a number of computer uses: [url]http://en.wikipedia.org/wiki/Grave_accent#Computer-related[/url]. :P

RE: Is XML the Answer?

Stephen Hirsch — Fri, 02 May 2008 16:06:40 GMT

Klaar Chris, klaar. My point of view exactly.In English "mark up" is something you do to documents, not databases.

RE: Is XML the Answer?

Christian Buettner-167247 — Fri, 02 May 2008 15:44:22 GMT

From my experience, XML is more or less document-centric.It allows easy validation and "ETL" from a document using XSLT.If a "document" is only rows & columns, then XML is probably overkill.But if it is hierarchical or at least more complex than rows & columns, itcan be beneficial. I also think that the main benefit is not in the database, it is in the handling of the data within an application (ever tried parsing a complextext file?). Extending XML to the database is just a natural evolution.Why not store such documents directly in the database? You need toconsider performance, that's true, but is this really the key factor for your specific application? It always depends.What I don't consider a use of XML is data exchange in the form of "batch" ETLfrom sytem to system. In contrast, for "document centric" ETL I would considerthe use of XML but considering doesn't mean also using it in the end.

RE: Is XML the Answer?

JJ B — Fri, 02 May 2008 13:32:53 GMT

Stephen: Thanks for the additional clarification. That helps.

RE: Is XML the Answer?

Stephen Hirsch — Fri, 02 May 2008 13:04:53 GMT

"If I understand you correctly, you are suggesting that I could create a delimited text file, but instead of using a comma, I could use the grave character? "Yes."Or maybe you are saying this: the narrative should be in its own file where each narrative record/table row is separated by the grave character?"Not quite. Maybe the narrative could be in a file structured like PK`Narrative?"I've never heard of the grave character. I'm going to look into it. I'm sure my peers in the other agency would appreciate an alternative to reading my XML files."Sure. It's the lowercase key next to the "1" on US keyboards (other keyboards, YMMV)"My biggest concern for using the grave technique would be: I know that most database products know how to easily read CSV files."Most DB products will let you select your own delimiter. Just select ` instead of , ; | etc."Similarly, there are standard methods for reading XML files, even if it is a pain. Would a database product have built-in (or at least easy coding) support for reading a file where "rows" are separated by the grave character? If lots of special code had to be written to read grave files, I'm not sure the grave solution would any better than the XML files."If it's at all decent, then yes.

RE: Is XML the Answer?

JJ B — Fri, 02 May 2008 12:29:18 GMT

Stephan: Thanks for the reply. If I understand you correctly, you are suggesting that I could create a delimited text file, but instead of using a comma, I could use the grave character? Or maybe you are saying this: the narrative should be in its own file where each narrative record/table row is separated by the grave character?I've never heard of the grave character. I'm going to look into it. I'm sure my peers in the other agency would appreciate an alternative to reading my XML files. My biggest concern for using the grave technique would be: I know that most database products know how to easily read CSV files. Similarly, there are standard methods for reading XML files, even if it is a pain. Would a database product have built-in (or at least easy coding) support for reading a file where "rows" are separated by the grave character? If lots of special code had to be written to read grave files, I'm not sure the grave solution would any better than the XML files. Just some thoughts. Thanks for your thought.

RE: Is XML the Answer?

dfalso — Fri, 02 May 2008 12:23:31 GMT

[quote][b]JJ B (5/2/2008)[/b][hr]I certainly would rather use CSV for transfering data/communicating between databases/servers any time just because it is a million times easier and faster to create, human-read, and code-read.So, I use CSV when I can. [u][b]BUT[/b] how would you solve the following problem without XML?[/u]............You have to send data to another agency. The data is not only completely outside your domain, but will be put into another database tool (Sybase). Most of the data would work great for a CSV format. However, one of the fields is a Varchar(MAX) field. Data in this field ranges anywhere from 1 page to 20 pages of text, all fully punctuated with every imaginable type of character.Could you really use CSV for this? What else would you use? I considered creating a separate text file for each row of each Varchar(MAX) field, but the programming effort of managing all those files seemed to be a lot more than the programming effort of XML, which seemed to easily handle this requirement.What would you do? (Honest question.)[/quote]As someone who deals with this every day, I can tell you that XML is almost there in ease of use, but when it gets there, it'll be a wonderful solution to my problems.I agree and disagree with the author here. Is it bloated compared to other ways of storing data? Yes. Is it trying to do too much, be all things to all people? Maybe. But please don't discount what it does do, because it does do it well. My department of my company is a data shop. We get data in, analyze it, and send it out all the time. Most of the time we get flat files (CSV or other delimited), and let me tell you, finding the rogue commas in data fields to fix data import is no fun task. Also, as the above author wrote, how do you then send carriage returns, commas, pipes, etc? Big deal for us. (and don't forget cross-platform issues)The other wonderful thing about XML is it basically forces a level of metadata documentation. If you don't think that's a a big deal, you haven't worked at a small company at the mercy of a larger company for data feeds. A large data feed shop really could care less if they lose our business, but we absolutely need theirs. So if we complain too much about needing more information, they either a) ignore it, or b) label us too much trouble and walk away. But with XML, I know that at least I'm getting field names and a relationship representation also. I've only found one situation where I used an XML field type purposefully in an application situation (describing metadata; it worked well), but one application that maybe you haven't considered is archival. If I send a 3rd-party an XML file, I can keep an archive of it in an XML field in a table. Yes, I could just store that in a folder on the network, but this way, I can easily query it from SQL Server directly to run stats of what we've submitted. Very useful.

RE: Is XML the Answer?

babu.sivaprakasam — Fri, 02 May 2008 12:21:12 GMT

The article and the discussion is really interesting.I am not expert on this.Silly Question : When we have just flat file instead XML, Don't we stuck with Deliminator like comma or # or any character.. Or fixed length, We should be very cautious during parsing. XML avoid that am i right? Please Answer

RE: Is XML the Answer?

Stephen Hirsch — Fri, 02 May 2008 12:16:19 GMT

"BUT how would you solve the following problem without XML?............You have to send data to another agency. The data is not only completely outside your domain, but will be put into another database tool (Sybase). Most of the data would work great for a CSV format. However, one of the fields is a Varchar(MAX) field. Data in this field ranges anywhere from 1 page to 20 pages of text, all fully punctuated with every imaginable type of character."The first thing would be to create two transmissions by putting that huge field into a separate file.Second, if that's not possible, the ` (grave) character, by itself, has no lexical value in any language. It's 7 bit ASCII, which makes it the ideal delimiter.

RE: Is XML the Answer?

Stephen Hirsch — Fri, 02 May 2008 12:14:00 GMT

"Is there an Object-oriented database that persists methods within each object? (loaded question)"Yes. Oracle."The alternative to an XML schema would be either:1) flatfile definitions with a shelf full of written documentation2) DDL for a full relational database"You say that like it's a bad thing! :PSeriously, there's no substitute for clearly written English (or other human) language documentation.And I find both 1 and 2 much easier to read than a DTD or (horrors!) an XSD.

RE: Is XML the Answer?

timothyawiseman — Fri, 02 May 2008 11:50:36 GMT

I partially agree with you. XML is definitely highly over used and sold to do far more than it really can. With that said, it certain does have certain niches as a standard way for certain types of genuinely hierarchical data. I think that in most cases XML does not belong in a database, but there are a [b]few[/b] exceptions even there and plenty of places outside of relational databases that are useful.

RE: Is XML the Answer?

DCPeterson — Fri, 02 May 2008 11:44:33 GMT

[quote][b]Sir Slicendice (5/2/2008)[/b][hr]Interesting article, but I think you (and to be fair, lots of others) have missed one of the most valuable benefits of XML:The standardized hierarchical nature makes it very, very easy to transfer set-oriented data without having to invent and process ad-hoc keying systems.To store or transfer set-oriented data that spans more than one table, you need a keying system; in XML, hierarchial arrangement eliminates the need for any keying when the schema can be presented as a DAG. This is a vitally important benefit, and likely the single largest reason XML has been widely adopted -- yet it is somehow almost always overlooked!Set theory as being superior somehow superior to graph theory? Methinks someone needs a bit more exposure to these subjucts to understand what they said. And you really need to do more thinking about the OO-graph theory criticism, versus the relational set theory accolade....As for MISMO, as a former member of a MISMO committee (one of many, both committees and members), I feel your pain! But a key thing to keep in mind about MISMO and all other XML standards: these standards embody full data schemas for their respective businesses, including data relationship, coding, and validation rules, as well as integrity constraints. The alternative to an XML schema would be either:1) flatfile definitions with a shelf full of written documentation2) DDL for a full relational database[/quote]Just a couple of things...I never said that Predicate logic and set therory were inherently superior to graph theory, that would be a very ignorant thing to say... There isn't a question that they have proven superior methods for developing data management systems because they are vastly simpler to implement and manage, while being sufficient for the task.I'm not unaware that XML does have some benefits conferred by its hierarchical nature and being accepted as a standard, but I do maintain that the costs GENERALLY outweigh the benefits, particularly when it comes to data management.

RE: Is XML the Answer?

cs_troyk — Fri, 02 May 2008 11:31:41 GMT

Have read this article a few times now since it was originally published. Still as relevant today as 5 years ago. I hope Steve will continue to bump this one at least once a year!Good job, Don.TroyK

RE: Is XML the Answer?

Sir Slicendice — Fri, 02 May 2008 10:57:32 GMT

Interesting article, but I think you (and to be fair, lots of others) have missed one of the most valuable benefits of XML:The standardized hierarchical nature makes it very, very easy to transfer set-oriented data without having to invent and process ad-hoc keying systems.To store or transfer set-oriented data that spans more than one table, you need a keying system; in XML, hierarchial arrangement eliminates the need for any keying when the schema can be presented as a DAG. This is a vitally important benefit, and likely the single largest reason XML has been widely adopted -- yet it is somehow almost always overlooked!Set theory as being superior somehow superior to graph theory? Methinks someone needs a bit more exposure to these subjucts to understand what they said. And you really need to do more thinking about the OO-graph theory criticism, versus the relational set theory accolade....As for MISMO, as a former member of a MISMO committee (one of many, both committees and members), I feel your pain! But a key thing to keep in mind about MISMO and all other XML standards: these standards embody full data schemas for their respective businesses, including data relationship, coding, and validation rules, as well as integrity constraints. The alternative to an XML schema would be either:1) flatfile definitions with a shelf full of written documentation2) DDL for a full relational database

RE: Is XML the Answer?

JJ B — Fri, 02 May 2008 10:45:58 GMT

I certainly would rather use CSV for transfering data/communicating between databases/servers any time just because it is a million times easier and faster to create, human-read, and code-read.So, I use CSV when I can. [u][b]BUT[/b] how would you solve the following problem without XML?[/u]............You have to send data to another agency. The data is not only completely outside your domain, but will be put into another database tool (Sybase). Most of the data would work great for a CSV format. However, one of the fields is a Varchar(MAX) field. Data in this field ranges anywhere from 1 page to 20 pages of text, all fully punctuated with every imaginable type of character.Could you really use CSV for this? What else would you use? I considered creating a separate text file for each row of each Varchar(MAX) field, but the programming effort of managing all those files seemed to be a lot more than the programming effort of XML, which seemed to easily handle this requirement.What would you do? (Honest question.)

RE: Is XML the Answer?

DCPeterson — Fri, 02 May 2008 10:34:58 GMT

Thanks for thinking! That was my main goal, to get people to THINK instead of just accepting what vendors were feeding us. One quick correction if I may: Yes, there is a differnece between interfacing and storage, but a datbase is NOT for data storage, it's all about data MANAGEMENT, or at least should be...

RE: Is XML the Answer?

Someguy — Fri, 02 May 2008 10:31:28 GMT

Well, yes I did read the 12 pages and my comments still stand.Of course, it may be that I'm a little lazy, too. Just this morning I had to open a configuration file for an errant program that I wanted to learn more about. I was happy to see that it was written in XML. So, I could understand it. Without XML, it would have been written in someone's proprietary format which would have made perfect sense to them, but little sense to anyone else. I'm happy that whoever wrote that file took the time to be familiar with XML. It saved me the hard work of spending all morning jumping around the internet trying to find some hint of what a mysterious file format might contain. I'm happy that the writer didn't say "Oh, XML is just a gimmick. I'm so smart that I'll write something that's much more efficient". I consider such a person to be pig-headed and lazy. They only want to do what's comfortable for themselves with the rationalization that they're smarter than the rest of us. Because I'm a little lazy myself, I prefer to work with developers who keep up with modern standards.Consider the VISA commercials where everyone runs through a store and swipes their credit card through a reader. They're happy because they get out fast. The vendor is happy because he gets his money faster. Then someone whips out a checkbook and throws the whole line out of whack. Are checkbooks evil or wrong? No, they're just inefficient compared to other ways of payment. Is VISA the answer to everything? No, but if everyone used one when appropriate, things would go a lot faster. XML is like that - if people would use it (when appropriate) life could be a lot easier for all of us. Flat files are like the checkbook. They made sense 20 years ago and maybe today in some specialized situations, but little sense today.Hey, if you want to create job security for yourself by re-negotiating standards for every new application, and your managers are stupid enough to put up with it, create all the flat files you want!

RE: Is XML the Answer?

marklegosz — Fri, 02 May 2008 10:08:56 GMT

I just want to thank the author. I have limited exposure to XML, and as a result have never really thought about it.I think in the future I will make the distinction between interfacing and storage. XML for transportation and interfacing, definately not for storing.Thanks for getting me thinking about XML!

RE: Is XML the Answer?

Frederick Goodrum — Fri, 02 May 2008 09:53:19 GMT

Mr. Peterson, thank you for putting a smile on my face this morning. (why, oh whydid I flag this thread). You, curmudgeon you.This current rebirth is classic 5 blind men and an elephant.Dynamic data? Business needs vs. IT engineering? intersystems communication?I get the feeling that this thread is off the rails a bit.But I want to thank all for the good laugh this morning. It was sorely needed.Here's something new for those have obviosuly have time. Is there an Object-oriented database that persists methods within each object? (loaded question)The XML debate is rather moot as it has been pointed out earlier. We'll go along like good little sheep as we did when 3GL languages became the rage and relational db's forced old COBOL programmers to retirement, and so on and so on.Meanwhile newbies can sit and pine for the next new messiah-like technology to eliminate the need to think and understand.Hey, I know, Let's go back to the Software engineering wars. Oh, sorry, all that required was listening to you customers and responding to their needs. what tool the engineer uses is of no concern to anyone.:hehe:

RE: Is XML the Answer?

DCPeterson — Fri, 02 May 2008 09:06:11 GMT

[quote][b]Someguy (5/2/2008)[/b][hr]Hmnn...By the time I'm getting here, we're on 12 pages of replies. Admitting that only a handful of people will read this far, I might as well throw in my 2 cents.(As a note to the publishers, when you re-print an article, don't mindlessly include all of the original comments - you make new comments almost worthless)This article is everything that is wrong about the computer field and a few things that are right.Right: XML is not the answer to everything. Nothing is. It is a tool to be used when it's useful. Yes, it's a shame that simple tools get raised to the level of messianic proportion by novices and greedy vendors. And storing XML in a relational database just makes the business of managing the database more complex while adding dubious value.Wrong: The things for which XML is useful are make it VERY useful. It provides a standard for inter-system communication that allows developers to avoid re-inventing the wheel for every new customer. The failure of people like the author to miss this point amounts to nothing more than just plain laziness and pig-headedness. Nuff said...[/quote]Mindlessness...Laziness...Pig headedness... traits all very evident in your post. On the positive side, I did get a good chuckle out of it though...Yes, XML has become a defacto standard, and enjoys many of the benefits that any standard does, but objectively, it is a stupid standard as standards go.The failure of readers like you to grasp points that are made in the article and that have been amplified, clarified, and reiterated in the subsequent discussion "amounts to nothing more than just plain laziness and pig-headedness" and I might add it's tiresome and boring.

RE: Is XML the Answer?

John Mitchell-245523 — Fri, 02 May 2008 08:51:19 GMT

[quote][b]Someguy (5/2/2008)[/b]Wrong: The things for which XML is useful are make it VERY useful. It provides a standard for inter-system communication that allows developers to avoid re-inventing the wheel for every new customer. The failure of people like the author to miss this point amounts to nothing more than just plain laziness and pig-headedness. [/quote]Hmnn indeed. I don't know whether you've had a chance to read through those 12 pages (which I'm glad were included at the re-publication otherwise we'd need all those comments to be made a second time), but Don does cover this point off several times. Even if he did miss the point, I wouldn't call that lazy or pig-headed - I'd call it a mistake on his part or a disagreement on yours. Either way, not sufficient grounds for hurling insults. This shows why it is important not just to read an article, but to read the feedback as well.John

RE: Is XML the Answer?

David Atherton — Fri, 02 May 2008 07:59:40 GMT

First, Great article...fairly objective (more neg than positive but realistic).Just chiming in on my experiences dealing with XML in a DB aspect.- MS has gone so far as to create a datatype around XML (XML datatype in SQL Server 2005 -> 2008) so it's here to stay from an MS aspect (at least for these versions of SQL Server). This could have been just a response to "industry" but enough people must have said "we want it"- Advantage of XML datatype that I've found? The jury is still out. The experiments I've done so far are based on search requirements. Instead of building "dynamic" sql for search needs, thought I could use XML representation of data to search on and ,literally, have my egss in all on basket but a) XML is case sensitive...searching on is not a big deal but try displaying data all in lower case :oP, b) Full Text Search ignores tags so you just might as well search a text file, c) (Newbie) on same vein as a), trying to use xquery to search on the data caused me more headaches than solutions and performance was dismal and d) storage requirements, at least so far I've noticed, have reduced with the use of xml datatype for the set of data.- With todays user requirements of "customization" needs, xml in an RDBMS model, I beleive, is a possible answer to how to manage/store user specific configurations/customizations that a "fixed" data model may have trouble managing. Again, I'm still in experimental mode but instead of having fixed models (restricts user to number of items if stored in single table (1024/8KB for us MS guys) / dynamic creation of tables (Oh my, how many tables :oP)), I'm leaning towards having the xml store the custom fields but also requires me to store the resulting data collected from these fields in a related XML format...I could be shooting my self in the foot but again...experimentingWith all that said, I've always toted xml as a data transfer tool, it may be bloated but it's cross-platform and if done right, opens more communications doors than closes but with all my other experiences, be very wary and experiment. A couple of weeks worth of hard core run throughs with real world data can save you years of hacks and torment.Dave

RE: Is XML the Answer?

Wyatt Eurich — Fri, 02 May 2008 07:45:06 GMT

I have to feel that the article is short sighted and reactionary.I used to shy away from XML for the same reasons the author stated, however over the years I have had a change in heart.Definitely, if all your interested in is efficiency than XML is not the right choice. At the enterprise level, often there is a need to combine similar, but different sets of data together to make something more useful. XML is a more flexible approach to the problem, and can speed a project to market more quickly. I am continually amazed how often doing the right thing from a IT perspective is often the wrong thing from a business perspective. If a project takes too long to come to market because the engineers took the long way around, the business opportunity can be lost. XML can be a fast way to your end goals, but certainly not the most CPU cycle efficient.Too, continually I see opportunities and the need for data structure to be more flexible, as Michael Taylor points out in his post. Reality is that most of the data stored on computers is unstructured or at least not structure enough to fit with a DBMS model, but we would still like to relate to it with set theory. Can a DBMS help? Certainly, and tools that facilitate that should be welcomed. We all love a smooth running well designed perfectly relational databases, but sometimes we have other needs and goals that are more important. We should not fear what is outside our box.That said, I do look forward to XML's successor and it's possibilities.

RE: Is XML the Answer?

Mike Yeager — Fri, 02 May 2008 07:41:39 GMT

I have very limited use for XML *in* the database. I have used it for tracking changes to records so that I can store old vale/new value of only the columns that have changed, but that's about it.On the other hand, I think XML is a BIG step forward for things like configuration files. One of the big things about XML is that you can have a schema - a defintion that can programmaticaly be validated against. How does one easily validate a delimited file? The schema can also provide intellisense in an editor. It is these schemas - not the tags themselves that are the big deal in describing and validating the contents of the files.Great article - some well-made points!

RE: Is XML the Answer?

Michael Taylor-482354 — Fri, 02 May 2008 07:08:25 GMT

While I agree with the author that using XML in the DB (or anywhere) shouldn't be done haphazardly I disagree with their opinion that the "expert" at the roundtable who said it made updates easier was crazy. Imagine for a second a dynamically changing database schema. For example an issue tracking system where admins could add new columns based upon their specific project needs. XML (especially with builtin SQL support) would be a good solution as the core DB schema wouldn't change but you could still extend it. Does this happen often, no. But it can. Which is the worse of two evils: XML containing dynamic columns or lookup tables that map dynamic columns to their values. Performance wise I'd say XML would win and would be more managable. I guess you could also generate DDL statements and update everything but that just seems dangerous to me.As far as the statement that you should have one column and one value to follow the rules of DB design, we don't do that today anyway. Many of the newer types being added to .NET are CLR types. These don't follow the rules of one value. There can be several related values in a single value. It depends upon how you define a value.I do agree that XML is being overused for no apparent gain. I worked at a company once that dealt with large blocks of data. To make it portable (although there was never a need) we used XML. Yet the XML files were 40-50GB in size because of all the redundant XML elements. Don't even get into the time it takes to load this data without writing a custom parser because the standard XML object model can't handle it. It makes more sense, in my opinion, to import/export data to XML when needed but otherwise use a more appropriate format. Of course binary is always the fastest file format.So, in summary, I agree with the author in context. I disagree with their arguments. IMHO.

RE: Is XML the Answer?

Someguy — Fri, 02 May 2008 06:24:21 GMT

Hmnn...By the time I'm getting here, we're on 12 pages of replies. Admitting that only a handful of people will read this far, I might as well throw in my 2 cents.(As a note to the publishers, when you re-print an article, don't mindlessly include all of the original comments - you make new comments almost worthless)This article is everything that is wrong about the computer field and a few things that are right.Right: XML is not the answer to everything. Nothing is. It is a tool to be used when it's useful. Yes, it's a shame that simple tools get raised to the level of messianic proportion by novices and greedy vendors. And storing XML in a relational database just makes the business of managing the database more complex while adding dubious value.Wrong: The things for which XML is useful are make it VERY useful. It provides a standard for inter-system communication that allows developers to avoid re-inventing the wheel for every new customer. The failure of people like the author to miss this point amounts to nothing more than just plain laziness and pig-headedness. Nuff said...

RE: Is XML the Answer?

Jim Russell-390299 — Fri, 02 May 2008 05:47:17 GMT

You deserve at least a dozen ataboys!OK, I am reacting to the title(!), although a brief read seems to confirm your insights, and I promise to read the whole thing more carefully.(More"thread mode" Wiki discussions and links at http://www.c2.com/cgi/wiki?XmlSucks.) I didn't find there the document I had remembered from 6 or 7 years ago, which opened my eyes about the shortcomings of misused XML.

RE: Is XML the Answer?

icocks — Fri, 02 May 2008 05:29:59 GMT

[quote][b]RyanRandall (5/2/2008)[/b][hr]Laziness is the mother of invention :w00t:[/quote]Good reply :) Still, I don't think web apps are the right solution, but that's a whole different topic (not to mention a whole different forum).Ian

RE: Is XML the Answer?

Anipaul — Fri, 02 May 2008 04:15:43 GMT

The article was good. But XML has become more popular than the time when this was was published first. XML has it merits and demerits. The type of work my company does requires lot of XML database. And we also found it is very very useful. :)

RE: Is XML the Answer?

RyanRandall — Fri, 02 May 2008 03:57:56 GMT

[quote][b]icocks (5/2/2008)[/b][hr]can't be botheredIan[/quote]Laziness is the mother of invention :w00t:

RE: Is XML the Answer?

icocks — Fri, 02 May 2008 03:45:06 GMT

Great article, I've been struggling to see for some time exactly why anyone would need xml for datafiles & this answers it perfectly. I too had been thinking I was just being thick & inflexible in not seeing the bigger picture.Now if only I can find someone who agrees with me that web apps are generally dreadful, slow, poorly featured cousins of proper client apps & the main demand seems to be from IT depts who really can't be bothered with managing software updates...Ian

RE: Is XML the Answer?

Patrick.I — Thu, 01 May 2008 23:42:57 GMT

Don't totally agree with Don.But i agree wit the last post.Use XML when you need it.No doubt about it XML is good.

RE: Is XML the Answer?

mdiaz-515908 — Wed, 17 Oct 2007 12:03:53 GMT

I look at XML as the bridge between data and presentation layer, with a simple tweak of some xml files that define my presentation and a data structure I get an entirely new representation of my data. And now with SQL 2005, having the ability to parse them within the application, i can create an endpoint and have it spit out the data in the format I define for it. Never mind creating a view and views on the fly. Although I am bypassing Create View secuirty methods, I still get the same results with less overhead.Another great use for XML is to cross platform data, but I have to agree with most to retrieve millions of records with a select statement that has for XML , AUTO at the end would create havoc to the recieving end. It is definalty the the final answer, but a stepping stone the the next question.

RE: Is XML the Answer?

Stephen Hirsch — Tue, 10 Jul 2007 11:02:00 GMT

I've had in mind to write an article on the proper uses of XML languages: to mark up text. They are very good at things like DocBook, etc., where you really mark up text. They are lousy databases, lousy data transmission formats, lousy .ini formats, etc.My advice to you, Frederick, is to pick a useful subset of the data model, perhaps 80% or so, and create a relational model to store it. Then, create a "Save As" function to output in the XML language.I know what DC is talking about. I get so tired of saying "using 'XML' is like eating a cookie cutter."Whenever I hear someone say that XML separates description from content, I would like them to see a schema where the nodes are in, say, Czech. I wonder how much description they would be able to extract.

RE: Is XML the Answer?

Frederick Goodrum — Tue, 10 Jul 2007 08:44:00 GMT

Thanks for the response. I guess I am officially a curmudgeon. I'm sitting here stirring up trouble while I wait for the UPS man to deliver a book on SQL Server Service Broker. Perhaps that will be my saving grace for the week.

Yes, yes that's what I need. A new distraction! No more XML! To the batcave.

RE: Is XML the Answer?

DCPeterson — Tue, 10 Jul 2007 08:26:00 GMT

My position has both hardened and softened somewhat over the past few years.

I still think that XML is “a stupid answer to all the wrong questions”, and that the computing world would be better off without it. However, out of self-preservation, I have given up any quixotic delusions that I could actually stop programmers from using it... It just became a huge drain and distraction and I found myself becoming more and more acerbic (kind of like Fabian Pascal) as I endlessly tried to explain the simplest of concepts to those who were unwilling to learn.

I don’t want to end up as a total curmudgeon who cannot have a civil conversation with anyone unless they agree with me, and who spends a lifetime arguing with people so I have chosen to take a more laissez-faire attitude towards XML. I’m happy to discuss the subject with anyone who is willing to learn, but I have more important things to do than argue.

I'm glad that you found the article and subsequent discussion useful.

RE: Is XML the Answer?

Frederick Goodrum — Tue, 10 Jul 2007 08:25:00 GMT

Stephen, what you're saying makes perfect sense. I'm am going to chance my stance. It is not that XML is a bad thing. It is the use. Just to clarify, The 4 years was directed towards this thread. This thread indicates to me the very debates I had at the same period (2003 or so) when WalMart mandated we change all our EDI infrastructure in 2 months so that we could sell our Compact Flash cards.

Back to point, I agree that the modelers of the MISMO standard went whacky-woo. I use them as an example because it is the industry of my current project. Second, It is a very large industry and this is the standard that many are in the process of adopting. I believe you've helped me focus my true concern. 'Data Modellers Gone Wild' and the sequel 'Architects Gone Wild' will give XML a bad name. I would generalize that IT managers will follow the design and development suggestions of their architects.

It now strikes me that history does repeat itself. The result is technology that may look to be evoling, but is genuinely stagnant.

This is going to require a new thread. I've jacked it enough.