Technology Industry
Industry: Email Alert RSS FeedBuyer beware: XML and eForms come in various flavors - Internet - Buyers Guide
Computer Technology Review, Oct, 2002 by Micah Dubinko
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.
- Most Popular Articles in Technology
- An overview of continuous data protection
- Why all those current ratings?
- Many countries now have a mobile penetration rate above 100%, report says
- The Tata Group's big telecom gamble: VSNL's recent acquisition of Tyco ...
- MEASURING BANK BRANCH EFFICIENCY USING DATA ENVELOPMENT ANALYSIS: MANAGERIAL ...
- More »
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.