Buyer beware: XML and eForms come in various flavors. (Internet).

If your eForm vendor claims support for XML, it's probably not exactly true. Keep in mind that their implementation is most likely a proprietary one, since no standard for XML presentation has yet been finalized. For organizations that are looking to implement an eForm solution or use XML as a data interchange format, it is important to understand that one version of XML-based products may not be compatible with another.

XML offers a valuable technology for data collection, as it can easily collect data from HTML and PDF forms and share that data with other applications. XML data does not need to go to an intermediary repository, like a database. Instead, data can be put to work instantly by connecting the form directly to the application.

Just supporting XML isn't enough, however--companies and organizations must agree on what the data should look like to achieve true compatibility within the framework of XML. Some entities have formed consortia to define XML data syntax, or schema so that applications can cooperate. Others have teamed one-on-one to solve these issues.

This article will discuss what differentiates one flavor of XML from another and the standardization efforts leading the way toward universal XML formats that can be used across various eForm business applications.

Open Architecture for eForms and XML

XML for Data Interchange--Yes! Because XML is an international standard produced by the World Wide Web Consortium (W3C) and consists of ordinary, readable text, many developers have started using it to share data between applications over the network. Nearly 99% of the XML use today is for this purpose. Applications that need to export or import data expect to see it in a specific way, and XML provides the mechanism to make sure this happens. As a result, data exported from document capture products in XML can easily be adapted as input data for any application that supports XML import.

XML and Form Design--Not Yet: Some companies have introduced XML-based forms solutions that they claim to be standards-based. In fact, as of Autumn 2002, they are all proprietary forms solutions that happen to be based on XML. For example, at least two eForms vendors have attempted to deliver their proprietary products as "standard" XML eForms products. To accomplish this, they each created a proprietary browser plug-in that "plays" their version of XML forms. This means that users have to install the vendor's plug-in. Worse, the plug-in and XML forms from one vendor are completely incompatible with the version from the other vendor. In nightmare scenarios, users would need multiple plug-ins, multiple form design tools, and multiple server products to support what were advertised as "standard" XML forms. These proprietary implementations provide the best proof of why an organization should not choose an XML forms presentation product today. Despite using XML, these products aren't compatible with each other or with developing standards. Moreover, XML forms presentation products require installation of a proprietary "XML" plug-in on each client that uses the product, and each has a different plug-in that is a wrapper around their historical Visual Basic/C++ proprietary forms products.

XML and Web Page Design--Not Yet: Generic XML is not widely used as a Web page presentation format for many reasons, the first being incompatible browser support. Anything that is displayed in a browser must be able to be translated by the browser. HTML was the first language that supported this function. For example, by typing "<b> bold </b>," the browser reads the tag and converts it into "bold." For browsers to understand XML as a presentation language, Microsoft and Netscape have added XML support to their browsers--however, the implementations are different and frustratingly incompatible with each other.

A second reason for the limited usage of XML-based Web page presentation is the lack of design tools for XML. The most common Web page authoring applications create Web pages in HTML and do not have support for saving a Web page as XML. Since HTML does a good-enough job for page layout, and browsers do not support XML presentation, there is no rush to create XML authoring tools.

A third reason centers on the enormous time and effort IT personnel would have to undertake in order to convert Web pages to XML. There are millions of Web pages written in HTML, and Webmasters will not redesign these pages as XML unless there is an overriding reason to do so. Currently no such rationale exists.

Coming Standards for eForms

The W3C is in the final steps of completing a new specification called "XForms", to describe Web, voice, handheld, and even paper forms. Once completed, this standard will finally make it possible to have standards-based eForms solutions. Even if browser support comes along slowly, and the first generation of XForms products requires plug-ins, customers will still benefit from having an interoperable standard and freedom from vendor lock-in. Eventually, browsers will support XForms natively, and even plug-ins won't be necessary. Closely associated with XForms is XHTML version 2, which combines the familiarity with HTML with the benefits of XML. Like XForms, this specification goes to great lengths to separate the content of documents from how it is rendered on the screen. XHTML will be a consolidating force in putting XML on map for Web designers. The final piece of the puzzle is that XForms facilitates data exchange by working with any flavor of XML form data. This provides both an opportunity and a challeng e.

Schemas--Present and Future

The fact remains that since it is extensible, XML comes in many flavors, often differentiated from another by document type definitions, also called DTDs. These allow for formal description of a specific flavor of XML in a machine-readable format. However, DTD syntax differs from standard XML and is limited in expressiveness. Because of inherent limitations of DTDs, there is great interest in a more effective technique called "XML Schemas", another W3C standard, which defines the specific markup that is valid within an XML document. Additionally, Schemas provide rules to ensure that the internal structure of the XML to which they apply remains predictable and consistent. For instance, the contents of an "<age>" element should only be numeric. Instead of the awkward DTD syntax, XML Schemas use actual XML to represent their contents. In this way, one XML document describes another. Schemas are a powerful tool for vendors and developers alike, and can be used to ensure the integrity of XML data, perhaps eventual ly replacing DTDs. Since XForms can directly apply Schema constraints directly to form data, system integrators have a powerful tool to catch "bad data" at the source, before it spreads to other systems.XML and related specifications from the W3C are still evolving. Today, XML offers a valuable technology for collecting data and sharing it with other applications. By choosing XML as the foundation for all data exchange, enterprises gain access to a growing repository of tools and functionality.

The standards for designing forms and Web pages are still in flux, however. Eventually this work will culminate in the publication of a "Recommendation"--a finalized, stable reference for XML technology on the Web. The progress of W3C drafts in various states of completions can be tracked at website http://www.w3.org/TR/.

Until then, present XML-based form solutions are proprietary in nature, and organizations must be aware of this when selecting an XML/eForms product.

www.cardiff.com

Micah Dubinko is chief XML architect for Cardiff Software (San Diego, Calif.), and represents the company as an editor with the World Wide Web Consortium (W3C).