Almost every software vendor serving the IT market has claimed that its products support extensible markup language (XML). However, some vendors have made the claim of "XML support" liberally and creatively, and all too often the support is so minimal as to be useless. For IT personnel and others evaluating software products, it's difficult to know what level of XML support is appropriate for specific business purposes.

THE HURWITZ TAKE: To help sort out this evaluation problem, let's look at a particular business situation and examine the technical requirements for XML support.

The X in XML stands for "extensible" – after all, XML is a meta-language for defining a plague of standards. Even so, the X may as well stand for "exchange," since one of the leading uses of XML is to exchange structured data between information systems over the Internet. The XML documents exchanged among e- businesses typically include structured content describing customer profiles, product catalog data and requests for quotes, bids, sales transactions, purchase orders, invoices, query result sets, database records/tables and even entire databases. Exchanging this type of structured data via XML documents requires five technology pieces.

  1. XML generator. The IT system wherein the data originates needs a generator that creates the XML document. Part and parcel of the generator is a mapping facility that identifies data structures within the originating IT system and maps these (along with any requisite data transformations) to the schema of the XML document.
  2. XML parser. The IT system receiving XML-described data needs a parser that can break an XML document down into its data elements. As with the generator, the parser must include a facility that maps elements from the XML schema to data structures in the receiving system.
  3. XML storage. In many XML-based solutions, the generating system keeps no record of specific instances of XML documents it creates, and receiving systems dispose of XML documents as soon as they have parsed them and stored the data. Some XML documents, however, are binding contracts or financial instruments. These should be stored in a database for legal or auditing purposes. The storage could be in native XML data structures or relational structures from which the document can be easily reconstituted.
  4. Index of XML data. Assuming that an XML document is stored in a database, it should be indexed, like any structured data, to enable query. Storing an XML document as a binary large object (BLOB) is inappropriate due to the lack of indexing. As a complement to database indexing (required for query), word indexing may be appropriate, in some cases, to enable search capabilities.
  5. Query of XML data. An index representing structured data in native XML format should be accessible through structured query language (SQL), which is widely supported by query tools and well understood by IT personnel and others. Although efforts are underway to produce an XML-based query language (XQL), Hurwitz Group believes that its acceptance among users and implementation by vendors is unlikely. The hegemony of SQL will reign supreme over XQL, just as it did a few years ago over object query language (OQL).

Any vendor claiming to have XML support must corroborate direct support for these requirements or offer a credible equivalent for each. Conversely, IT personnel and others evaluating the XML support in a software product can apply the above list of requirements when determining the depth to which a product supports XML.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access