Since its inception XML has at times been seen as the cure-all for every problem related to Web applications and integration projects. However, poorly written XML can either slow down an integration project, or worse, cause the integration project to collapse.

When developing integration systems such as Web services or any other business-to-business function, developers may encounter the following problems when writing XML:

• Non-verifiable code - XML is supposed to be easily validated by use of Document Type Definitions (DTDs) or schemas. Frequently however, DTDs and schemas may be invalid themselves, too complicated for XML documents to reference, or even insufficient for most businesses. Therefore, there is no way to really guarantee that a certain XML file is valid if it does not reference a valid DTD or schema.
• Human-readable, yet ambiguous code - Although human readability can be seen as an advantage of XML, it can also be viewed as a problem. Human-readable code isn't always readable by humans. For example, an element that has a specific meaning to one developer may be of no use, or make no sense, to another developer. Also, human-readable does not necessarily mean machine-readable. If XML code is written strictly for machine consumption, then there is no reason for having code that makes sense to humans but has no meaning to a machine.
• Versioning problems - Maintaining multiple versions of a single document can be very difficult. Developers can either maintain a full version of the code to understand each XML format, or they can reference different DTDs for each format. Both options are possible but each requires a lot of time and effort.
• Vogue attitude toward XML - Many developers turn to XML simply because it is the popular language of the moment and they do not consider whether or not it is the right solution. More often than not, XML introduces more complexities than needed where a simpler text file would have sufficed.
• Chaos of standards - XML standards are still in development and are constantly shifting. Without any stability in XML standards, developers are forced to either keep up with the rapid changes, or fall behind.

Understanding XML
The Extensible Markup Language (XML) is a family of technologies that describe structured data. By using XML companies can create common information formats and share this information on the World Wide Web. For example, a company can create an XML document to exchange information about its products over the Internet. For a simple example of an XML document, see Listing 1.

XML and Its Inefficiencies
Although the example XML document in Listing 1 appears to be written correctly, how can developers be completely sure that the code is valid and well-formed, is comprehensible to other developers, and adheres to specific standards? The answer to this question lies in a rule-based system that can establish team policies and practices to prevent poorly written XML.

The following sections will outline some of the inefficiencies that can lead to problematic XML, and will address how a rule-based system can prevent the use of poorly written XML in integration projects. After all, system performance is only as good as the data received and the instructions given. If errors are contained in the XML, it is more likely than not that the system will crash.

Validating XML
One of the main benefits of XML is that it provides mechanisms for verifying document validity. There are two basic mechanisms for verifying document validity: DTD and XML Schema. For example, when creating an XML document developers can reference either of these mechanisms from within the document itself. The DTD or schema that is referenced will specify exactly how the XML document is to be processed, which elements and attributes are contained in the document, and the order in which these elements and attributes should be listed.

Defining DTDs
The following is an example of a simple DTD that can be referenced by an XML document:

<!-- ProductList DTD -->
<!ELEMENT ProductList (Product)*>
<!ELEMENT Product (#PCDATA)>
<!ATTLIST Product color
  (red|green|yellow|weird) #REQUIRED
         file CDATA #REQUIRED
         id CDATA #REQUIRED
         isFruit (true|false) 'true'>

<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE ProductList PUBLIC "-
  //OnlineGrocer//ProductList//EN" "ProductList.dtd">

Defining Schemas
For an example of a simple schema that can be referenced by an XML document, see Listing 2. To reference this schema from an XML document, the attribute in the element can be specified with the following header:

<ProductList xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="ProductList.xsd">

An XML schema, like a DTD, defines a set of legal elements, attributes, and attribute values. However, XML schemas provide a more robust verification for XML documents. XML schemas are namespace-aware and also cover data types, data bounds, schema class inheritance, and context-sensitive data values - all of which are not covered by DTDs.

Lack of DTD/Schema Enforcement
While referencing DTDs or schemas can guarantee the validity of XML documents, there is no requirement that developers will use headers to reference DTDs or schemas at all. In fact, developers need only to follow simple syntax rules in order for an XML document to be "well-formed." However, a well-formed document is not necessarily a valid document. Without referencing either a DTD or a schema, there is no way to verify whether the XML document is valid or not. Therefore, measures must be taken to ensure that XML documents do, in fact, reference a DTD or schema.