Applications for XML

The use of XML is still being investigated, with companies being somewhat reluctant to charge full-steam ahead on development of projects using XML. However, there are some applications that are good candidates for XML:

Applications that use data with repeating text fields
Applications whose persisting data includes a variable number of repeating (nested) textual fields should use XML. This is an obvious XML application, and one that has suitable tools in place. An XML processor, such as XML4J or XML4C or Xerces which provides a DOM API, allows your program to create or read this kind of document. Also, the document can be stored in repositories, such as IBM DB2 with XML Extender, where queries can retrieve documents regardless of which repeating field contains the data used in the query.

Applications that need Unicode
Applications for multilingual or multinational audience that use textual names of people, enterprises, and geographic places need the flexibility to display the names in the correct local language and character set. Use XML for such applications because XML uses Unicode by default, which allows end users to encode names in their preferred language and character set.

Applications that exchange data between enterprises
Another obvious use for data exchange formatting is an application that exchanges data between enterprises, using software produced and configured by more than one enterprise. The benefit of XML here is debugging, because the data interchange is at least somewhat readable when done with XML tags. Messages structured in readable HTTP, NNTP, FTP, and so on, made it possible for independent programmers to debug their interactions with software from others whose source code they did not have during the formative years for Internet software of the 1980s and 1990s. XML serves the same purpose, but the ability to define your own document types means all programs can use readable data interchange (and with more bandwidth available, they can afford to), and XML’s ability to nest and mix (using namespaces) is an important advance.

Route-and-flow applications
Route-and-flow applications differ from conventional applications: they do not have one program active for an entire transaction, waiting in real-time for subsystems to complete their portion of the work. Instead they use independent subsystems that examine or augment the data and then pass it on to one or more other subsystems, which can work asynchronously, using some type of queued data pipe. XML is particularly apt right now for those route-and-flow applications that do not have real-time transaction confirmation requirements. The IBM MQSeries Integrator can be especially valuable in building these applications by allowing the routing logic separate from the business processing logic. TIBCO and others also make route-and-flow middleware, and the Java Messaging Framework and the Open Applications Group now specify common APIs.

Applications that produce microcode data reports
XML's structured repetition and programming language independence mean new generations of server code can evolve to collect data from embedded sensors without changing the embedded-device microcode. Because many embedded sensors are programmed with microcode to send cumulative data reports back to a server, this could be an important XML application for developers working with embedded systems.
Older forms of XML cumulative data reports could be converted to newer forms using XSLT, using programs like LotusXSL or Xalan, so that the server business logic that reads the reports does not become littered with case statements. And there will be older forms: for example, each generation of electric meters will capture more information than the previous generation did, but there will be no worldwide replacement of the older meters in the field.

Applications that display results on various devices
As ubiquitous computing takes hold, more and more applications must present data to end users on many varied devices. That’s a natural use of XML: the applications present status to end users as an XML document. Transcoding would alter the data for optimal rendering on the end user’s current access device, whether handheld computer, Web browser, pager, audio phone, smart cellular phone, or other.
XML and transcoding also address the end users’ limitations (for example, limited eyesight) using alternative renderings.
An added benefit of reporting status as an XML document is that filters can determine if the status is highly unusual or urgent, and route filtered messages through additional channels to additional end users.

Source: Schloss, B. (2000). Ten best bets for XML applications.
http://www-4.ibm.com/software/developer/library/tenxmlapps/index.html