Generated XML: XML Transformations

XML generated from the database is in a canonical format that maps columns to elements and object types to nested elements. However, applications might require different representations of the XML document in different circumstances.

Transforming Query Results Using XSLT

This involves querying on the original document and transforming the result into a form required by the end-user or application. For instance, if an application is talking to a cellular phone using WML, it might need to transform the XML generated into WML or other similar standard suitable for communicating with the cellular phone.

This can be accomplished by applying XSL-T transformations on the result XML document. The XSL-T transformations can be pushed into the generation phase itself as an optimization. A scalable, high performance XSL-T transformation engine within the database server would be able to handle large amounts of data.

Indexing and Querying Transformations

You may need to create indexes and query on transformed views of an XML document. For example, in an XML messaging, there could be purchase order messages in different formats. You, however, may like to query them in canonical fashion, so that a particular query can work across all the purchase order messages. In this case, the query is posed against the transformed view of the documents.

You can register standard XSL-T transformation scripts for transforming XML documents to the canonical format, with the database. When indexing or querying, the database can automatically create the transformed virtual documents and satisfy the query or build the index.

Indexing Approaches

The native implementation for the extractNode() and existsNode() operators is to parse the XML document and perform the path traversal and extract the fragment. But this is not a performance and scalable solution.

The second approach is to utilize the inverted text index which interMedia text creates when it parses a document. This can give the offset into the document where the element occurs. But this would not work for object-relational data.

A third but different approach would be to index the XPath path expressions themselves. A lot of pioneering work has been done in this respect in the research community, especially in Lore. Lore creates a data guide for all semi-structured documents stored in the database, which is an index of all possible path traversals through all the documents. We can follow a similar approach and index on all possible XPath path expressions on the XML document, using the extensibility mechanism. This, however, poses some challenges in generating the optimal execution plans, such as bottom up versus top down evaluations.