Page 2 of 2   « previous page

Using Rules to Enforce Document Validity
To guarantee that an XML document references a DTD or schema, development teams can adopt a rule-based system that can detect and prevent errors within the XML code. Developers can create rules that impose constraints on XML documents to verify validity. For example, a rule can be created that enforces an XML document to contain the sample schema header:

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

Human-Readable or Ambiguous Code?
As seen in the sample XML document, XML is human-readable. In other words, XML is created in plain text and utilizes actual words or phrases that have specific meanings to developers. However, even though XML can be read and written by humans, it does not necessarily mean that humans can understand XML - developers can still create unreadable XML code. An element that has a specific meaning to one developer may be of no use, or make no sense, to another developer.

For instance, developers can create XML that is completely unintelligible to one another - consider XML tags that are written in Polish or Japanese. Code doesn't need be written in another country to be ambiguous either - ambiguous code written in the same tongue that is to be shared between companies can be quite cryptic as well. For example, the element <Trans> can mean anything from transform, transaction, or Trans-Am, depending on the developer and the application.

Establishing Team-Naming Conventions
To prevent ambiguous XML code, development teams must mutually agree upon a standard XML vocabulary. With a standard language in place, developers within a team will be more likely to understand each other's code.

Naming conventions can be established that verify whether code follows rules that verify anything from W3C guidelines for a specific language, to team-naming standards, to project-specific design requirements, to the proper usage of custom XML tags.

Chaos of Standards
Although the W3C has made an effort to establish a common language, vocabulary, and protocol for XML, these standards are still in development and are constantly changing. Companies that adhere to proposed standards that are not yet fully mature must be prepared to keep up with any changes of the standard in the future. For example, a standard that is in existence today may not exist six months from now. Without any stability in XML standards, developers are forced to either keep up with the rapid changes, or fall behind.

WS-I Basic Profile to the Rescue
In spite of the chaos of standards that may exist for XML development, the release of Basic Profile provides some guidance to developers seeking a widely used XML standard. The Web Services Interoperability Organization (WS-I) Basic Profile standard consists of specifications that establish a baseline for interoperable Web services. These specifications include guidelines that cover XML 1.0.

Developers can now depend on Basic Profile as a common framework for implementing XML and building integration projects. There are more than 25 WS-I member companies that support Basic Profile. Therefore, developers can be confident that the XML standards they use will not be privy to constant flux and change.

Summary
Although XML is meant to be a flexible, easy to use, and fully portable solution for Web applications and integration projects, it is not the cure-all that many once thought it to be. The inefficiency of XML is well known among enterprise developers, but it remains ignored in exchange for the perceived advantages of XML such as flexibility, ease of use, and portability. However, the reality of the issue is that XML has a number of drawbacks that enterprise developers should be leery of when creating integration systems.

The key to successfully using XML in an integration project is to first understand the inefficiencies that may cause poorly written XML, and then utilize the proper techniques that verify correctness at each level of the implementation.

Page 2 of 2   « previous page