Extensible Markup Language (XML) is a double-edged sword for application designers. XML has become the ultimate data bridge for joining disparate applications. But like actual makeshift bridges that are flexible enough to work in jungle terrain, XML can be somewhat precarious.

There are times to let your creativity flow and push XML’s flexibility to the limit. There are other times when it’s better to pull back and stay with what you know works.

XML’s soft underbelly
In examining the areas of XML application that inspire caution, a good first step is to consider the weaknesses of XML in general. It should be noted that most of these weaknesses are consequences of XML’s tender age and that some of the shortcomings are the result of the fact that the technology’s rapid growth on the Web has outpaced its development. Undoubtedly, we’ll have something better in the near future. For now, the play-it-safe rules are directed by the following realities:

The nature of distributed systems: XML enables distributed systems, and distributed systems tend to be ungainly, inelegant structures that are often cumbersome, inflexible, and lacking in fault-tolerance and robustness.

Complexity piles up rapidly in XML: A big reason XML exists is to accommodate data portability between platforms. As such, it is extremely flexible, even a bit vague, with respect to functional standards. Distributed systems, on the other hand, are extremely rigid and sensitive. The more complex a distributed system, the greater the consequences of errors that would cause relatively few problems in a stand-alone system. It is easy to see that these two characteristics are at odds. XML’s flexibility makes it a great bridge but makes it less manageable as complexity increases.

The need to automate the Web: We want to pull people out of the loop wherever we can. And in most Web apps, we put them in the loop in the first place with browser-based interfaces. It’s difficult to automate such systems because HTML and its derivations are not easily digested by most automation platforms.

Great platform flexibility leads to inflexible apps: A flexible platform gives you more customization options when creating your apps. And the more customized the apps, the less flexible they ultimately tend to be. This catch-22 has produced a Web cluttered with servers and services that are pretty much fixed and rigid.

This context suggests several rules of thumb:

  • If system complexity is a threat, then at the functional code level, simpler is better.
  • Overdoing the internal flexibility of an app can make it less generalizable.
  • Write with automation in mind, even if it isn’t yet in place.
  • The overcustomized nature of Web apps suggests that a trend toward standard, reusable code is prudent.

Below are some suggestions for applying these rules, by pushing forward or pulling back your innovative impulses when using XML.

Push remapping to the limit
Passing data between apps is where the flexibility of XML can really pay off. XML is able to accommodate just about anything a sending app throws at it and can itself accommodate in turn just about any receiving application. Your innovations in this area are safe because XML can preserve them not only locally to your app but also as classes. In essence, as long as your data typing/handling is functional and robust, it is application-safe in both directions. You won’t mess up a foreign app and probably won’t mess up a future maintenance programmer by getting creative here.

Document type definitions (DTDs) are another safety hedge for XML creativity. DTDs communicate with the XML processor to reference an external subset of declarations, in essence making any document that is defined correctly for your application’s purposes fully accessible to any other app. Innovate to your heart’s content, and the foreign XML processor doesn’t care. This is a crude form of the kind of modularity we someday hope will truly exist at the nuts-and-bolts level on the Web.

Respect the browsers
There’s a time to go nuts and a time to play it safe. The time to play it safe is when your application runs in the real world, on dozens of different versions of different browsers. XML applications are, ideally, platform-independent, but this is another point where diverging evolutionary paths run afoul. XML enables increasingly complex document processing, but consistent complex document processing requires more standardization among the browsers than presently exists.

The fix for this is general browser libraries, which have some distance yet to go to be fully functional. Areas in particular where such common tools are useful in XML processing across browsers include parsing and data trees. You may need to make use of these to be as browser-portable as required. So bend as far as you can in their direction.

The power of OOP in an interpreter universe
One of the greatest things about XML technology is that processors permit you to bring the full power of object-oriented concepts into the down-and-dirty world of Web programming. This is one place to let innovation run free.

Your ability to create classes for document handling compensates in no small measure for the general lack of modularity in Web application coding. The dexterity of XML processing in this realm is an unappreciated miracle. You can create a document-handling system and basically extend it at your leisure. You can generate a set of classes and subclasses describing a particular document and cluster them into a tree, extending the document system with one tree perhaps becoming many (a grove). You can now exercise DTD management within your app or a family of apps with minimal redundancy.

And the beauty of this strategy is that you can conveniently add additional structures without compromising what you’ve already built.

The advantage here is not only incredible efficiency on a platform that isn’t inherently very efficient, it is also the reusability of what you’ve created and the ease with which you can adapt it without hacking it to pieces.