Strong error handling translates into more reliable applications. When you load an XML document, it is best to catch errors early, before they have a chance to damage other data. I have noticed that many companies and developers make the same mistakes when they adopt XML technology. Learn how to avoid common XML coding errors when you design and implement error handling in XML applications.
… is to not use XML.
“The essence of XML is this: the problem it solves is not hard,
and it does not solve the problem well.” — Phil Wadler
XML is hard to parse, XML is hard to read, XML is hard to edit, XML is full of ambiguities.
Just say no to XML, there are always better alternatives, from
key=value pairs, to S-Expressions, passing by CSV. No file format
works well for all data, use one that fits best your needs, XML
does a bad job for all problems.
(And I know what I’m talking about, I have used XML since late
1998, it was painful then, but thanks to things like XML-Schema
and SOAP now it’s even worse)
Actually XML is very very easy to use in .NET. Just this week I wrote a quick C# app to grab the contents of a table on a remote mssql server db into a DataSet object, which I fed to an XSLT translator with a XSL stylesheet and produced an excel spreadsheet (which was XML). Very few lines of code to do this, and the XSL stylesheet was very easy to figure out and make, and makes it very flexible to change.
Most .NET things have the ability to read XML or write it, making it easy to use.
Granted, XML has always been overhyped and overused, but it is useful at times. In fact, before this week, I had never found a use for it. I thought it was hard to use as well, until I really started digging into .NET.
And some advocate JSON.
http://www.crockford.com/JSON/index.html
Yes, the bad old days of an ADODB.Recordset as an argument to an Excel.Range object’s CopyFromRecordset method were truly a testament to the horror that was COM, and teach us to thank Redmond for the blessings of .Net and XML.
Amen.
“Just say no to XML, there are always better alternatives, from key=value pairs, to S-Expressions, passing by CSV.”
[XML is not S-Expressions]
http://www.prescod.net/xml/sexprs.html
The problem with XML is that it is a collection of committee efforts, and those committees are sprawling, multi-industry, multi-year affairs with no strong personality at the head in most cases. The only way to win approval is to add everyone’s pet feature. So we get monstrosities like XML Schema and CSS which nobody really likes.
People say, “you’re not supposed to read the XML document, you’re supposed to feed it a tool that’s been tested and debugged.” I thought that was a big selling point of XML in the first place – that docs were human readable and editable using “Notepad”.
Paul G
“The problem with XML is that it is a collection of committee efforts, and those committees are sprawling, multi-industry, multi-year affairs with no strong personality at the head in most cases.”
Better known as the “endorse Microsoft” plea
The only way to win approval is to add everyone’s pet feature. So we get monstrosities like XML Schema and CSS which nobody really likes. ”
The only one who seems to be having a problem with CSS is…MS.
I agree with you for the most part. I think XML has a place, but its place is very small.
Probably 95% of the projects I’ve been forced to use XML on could have been done much more efficiently some other way.
The problem is that people making decisions often make them based on market hype. To give an example, when I worked at Novell, one of the managers went to an XML conference and came back and informed the team that we were going to do all future development in XML. He asked one guy to research and find the best XML IDE out there.
This is extreme, but I think a lot of project suffer from XML due to this same level of insight.
“XML is hard to parse, XML is hard to read, XML is hard to edit, XML is full of ambiguities.”
Obviously you have never learned how to use bison and flex.
Also you forgot that simplistic format gconf/debconf uses, I believe it’s similar to the RFCed email header format.
Just say no to XML…[and use alternatives such as] passing by CSV.
You must be joking, right? Have you used CSV? From different programs? CSV is confused, with programs rarely agreeing upon things such as quoting and escape characters.
So you’d want to replace XML, with fairly well defined semantics and quoting mechanisms, with CSV which has no well defined semantics or agreed upon quoting mechanisms.
You’re out of your mind.
I’ll admit that XML isn’t ideal, and XML data can be bloated, but it is not a “bad job for all problems.”
I’m also not sure why you dislike XML-Schema — it’s intended to remove ambiguity. Does an XML document meet the XML-Schema requirements? Yes or no — no ambiguity there. The alternative is to have an assumed set of semantics which cannot be checked for, and code all programs for the possibly vague semantics. CSV anyone?
The most common problem I see is people using xml like a string, either by avoiding a genuine XML parser and instead parsing with regexps, or producing xml by concating strings.
The former can’t understand hierarchy and so extracting tables from a structure like [table][tr][td][table][/table][/td][/tr][/table] … might end up with invalid xml like [table][tr][td][table][/table].
Follow IBM’s advice and use an XML parser.
…when you see a NEED to use XML. XML is not evil, nor on the contrary, is it the savior of electronic comunication. In fact, I think it is best when used minimally, but it can save you a huge amount of time and resources when used correctly and has the ability to give you an elegant solution to the ancient problem of communication between two or more objects that don’t speak the same language. I purchased an XML book back in 2000 and it sat on my shelf for about 4 years. I recently came across a project in which each of the systems that needed to share data had different file, object, and data requirements. The one thing all systems had in common was the ability to parse XML and process it. I’ve never used XML for a one-to-one web project unless the system I was talking to specifically required it. If you can’t think of a really good reason to use XML in your project, don’t use it. When you need it…you’ll know. It’ll be obvious.
> an elegant solution to the ancient problem of communication between two or more objects that don’t speak the same language
And I thought Unix had solved this 30 years ago…
“Write programs to handle text streams, because that is a universal interface.” — Doug McIlroy
Note that XML is _not_ a proper text stream because it can’t be parsed without an insanely huge and complex XML parser. There are many languages that don’t have XML parsers(and there are many devices that don’t have enough resources to run a standard XML parser), there are very few languages and systems that can’t do string/text manipulation.
And I thought Unix had solved this 30 years ago…
“Write programs to handle text streams, because that is a universal interface.” — Doug McIlroy
Yeah text is really ^M
universal, there are ^M
no cœmpatibility problems at all.
Note that XML is _not_ a proper text stream because it can’t be parsed without an insanely huge and complex XML parser.
Yeah you’re right, XML parsers are HUGE!!!
http://expat.sourceforge.net/ (~300K source code)
There are many languages that don’t have XML parsers(and there are many devices that don’t have enough resources to run a standard XML parser), there are very few languages and systems that can’t do string/text manipulation.
Yeah, there’s lots of programming languages that can’t interface with C libraries.
Well, I’m off to write a program that dumps binary search trees off my company’s mainframe to a text stream for access on my graphing calculator…toodles.
Yeah you’re right, XML parsers are HUGE!!!
http://expat.sourceforge.net/ (~300K source code)
I think he is talking about the ratio of code to resulting work that comes out the other end; that doesn’t include the fact that when XML data starts to become big; it is overly verbose and bloated – hence a whole new industry based around XML compression/Binary-XML.
Couple that with the problems that SOAP have in regards to scalability, one wonders whether SOAP and XML are merely pathetic attempts by Microsoft to adopt technologies simply because they have no heritage to SUN or anything from the ‘old world’ – it seems to me they’d rather have a poorly scalable SOAP than using CORBA which has been rigourously tested for many years.
>>Note that XML is _not_ a proper text stream because it >>can’t be parsed without an insanely huge and complex XML >>parser.
>Yeah you’re right, XML parsers are HUGE!!!
>http://expat.sourceforge.net/ (~300K source code)
Ehh, are you trying to be sarcastic? 300K *is* huge.
images aren’t text.
images are binary data.
xml can contain binary data.
– Jesse McNelis
I wrote my own “insanely high and complex” SAX2 parser in 1349 lines of C++ code (29KB total). Yes, it only handle basic features (ie. no DTD, XML schema, XInclude, XPath, etc.), but it’s good enough for our purposes (we have been using it for 2.5 years in our client- and server-side applications).
However, I agree that XML is too bloated. I’d have loved to write a full compliant XML parser, but it’s just too much. I remeber to have seen an effort to simplify the XML specification that stripped down the bloat of XML. Can’t remember the name of the project.
All I need is a simple XML parser, XSLT transformer, Relag NG schema validation, XPath and a memory efficient DOM implementation.
XML, over-hyped but definitely with its uses… of course if you insist in trying to fit square pegs into round holes it’s going to look silly, but it has it’s place.
There have been attempts at a universal file format for years now (anyone remember IFF?) and at least XML has widespread support, but there is no such thing as a universal file format.
It is (or should be) fairly self-describing (though name=value or similar type files can do that too) and supports hierarchical and sparse data well. But whilst that covers a large subset of all data, it is just a subset.
And yes, .NET makes working with XML very easy (even if it does mean loading a 1.27Mb DLL
)
There have been attempts at a universal file format for years now (anyone remember IFF?)
I like(d) IFF. The most interesting part is that MPEG, AVI and QuickTime transport layer are very close to IFF. I think IFF is a good format but that the NIH syndrom prevented it to spread. Each programmer/compagny created its own version of IFF.
To understand when to use XML, and why, you have to understand that the XML standard is more then the syntax spec named XML 1.0 (1.1)
XML is the platform on top of which a horde of standards is based and deployed. URI, XLink, XInclude, XSLT, RDF, Owl, XML Namespaces, XML Schema, DTD, CSS, XPath, XQuery, XForms, XML-FO to name a few
Without theese XML would just be an arcane syntax.
XSLT being the coolest in my opinion.
Great as a templating system for anything outputting HTML or other XML
XSLT is also totally unreadable.
What is funny is that before I thought that Lisp wasnot readable too, but everything’s relative apparently..
If you need a functionnal language to process XML why not select a *good* one?
o.O
XSLT was unreadable to me too. Then I checked out a quick tutorial, played around with it, and it become much easier to read as I understood it. This all took less than 2 hours.