Is XML the Answer?
-
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.
Kindest Regards,Frederick Goodrum
-
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.
/*****************
If most people are not willing to see the difficulty, this is mainly because, consciously or unconsciously, they assume that it will be they who will settle these questions for the others, and because they are convinced of their own capacity to do this. -Friedrich August von Hayek
*****************/
-
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.
Kindest Regards,Frederick Goodrum
-
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.
-
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.
-
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.
-
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
-
icocks (5/2/2008)
can't be botheredIan
Laziness is the mother of invention :w00t:
Ryan Randall
Solutions are easy. Understanding the problem, now, that's the hard part.
-
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. 🙂
-
RyanRandall (5/2/2008)
Laziness is the mother of invention :w00t: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
-
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.
-
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...
___________________________________________________
“Politicians are like diapers. They both need changing regularly and for the same reason.” -
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.
-
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!
-
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.
Viewing 15 posts - 106 through 120 (of 144 total)
You must be logged in to reply to this topic. Login to reply