Eating the XML dogfood

Sean McGrath speaks to the dark side of XML tagging in this cogent article. He's right. When the people who are making the dogfood don't have to eat it, there's bound to be trouble.

Every time a developer writes an XPath expression, a SAX handler, or weaves a DOM NodeList, he or she is contributing to the XML tags' cost of ownership. Every time a developer backs off from cutting code because of the sheer complexity of the XML structure being manipulated, you are accumulating costs.

In XML land, not only are the equivalent of "global variables" created with wild abandon, but their creators often see fit to invoice based on the number they create for you. An unfortunate schism exists in XML software development between the team that develops the schema and the team processing the XML that conforms to the schema. Too often, these are not the same teams.

I remember an example of lateral thinking in a book by Edward De Bono. A company suspected of water pollution applied for permission to draw fresh water from the same stream it was pumping effluent into. Permission was granted on condition that the water in-take occur down- stream from the effluent discharge.

Stretching the analogy to its breaking point, those who wish to create schemas must work at a software development level with the XML they themselves have modeled. That will teach them the real cost of XML tagging. The real cost of XML tags ( [ IBM DeveloperWorks: XML News ]

Last night, I had dinner with Dale Dougherty, who has been around the track a few times when it comes to processing structured text. (Dale wrote the 1990 classic, sed and awk.) What bugs him lately? Overly complex XML schemas. Less is more, he has concluded.

Former URL: