Once a storage model becomes "XML aware" it must differentiate between content that is XML and simply marked-up documents such as HTML pages. In order to do this it obviously must understand the nature of XML and what differentiates it. The W3C XML CORE specification defines what constitutes an XML document and thus any database that professes to store XML must be able to enforce this specification. One particularly difficult requirement is the required support for Unicode as this can double the size of the storage model and any buffers.

Many consider the W3C XML Namespaces specification as a "necessary evil" to move XML into the business world. This support is necessary in order to specify and distinguish the XML meta data and is a necessary component for data type support as specified by XML Schema. Since namespaces are not simply prefixes to element and attribute names, but can also be inherited without prefixes, the result can be difficult to maintain without access to the data model of the document.

Databases store data to be able to retrieve it. While this is an obvious statement it bears re-stating as XML can be considered a container for data from which it is to be retrieved. The W3C XPath specification was developed to provide and navigational syntax that could query into the structure of an XML document. XPath is the basis for both XSLT and XML Query - two languages for querying an XML document or collection and returning or processing the results. For a database to properly support XML, it must expose functions that can take XPath selectors and predicates otherwise the processing will need to occur outside the storage model where it would be less efficient. Relational databases need to virtualize the XPath structure through either object support, sophisticated indexes or both.

Databases also store data in rows and columns as that has proven to be an efficient storage model for data-intensive applications. To serve as a data source for an XML application you need to be able to generate XML documents with the data from these tables. A new ISO standard, SQL/XML provides a set of functions that extends SQL (i.e. XMLElement(), XMLForest(), XMLAttribute(), etc.) to be able to create XML structure with a SQL query. Thus supporting this standard has become an important requirement when using relational data in an XML application.

The structure or data model for an XML document can be defined by Document Type Definitions(DTD) or XML schemas(XSD) respectively. These provide the capability to validate an input XML document to insure its integrity and completeness for further processing. While DTDs focused on defining the meta data and structure of an XML document, XSDs take this one step further and introduce data types into the model.

Several challenges exist for databases to have their schemas support DTDs and XSDs. Both models must be supported as they serve different applications, yet both focus on the input XML where the database needs a model that delivers performance on the retrieval side. Additionally, DTD support means support for entities which either get expanded and thus are lost, or are maintained but need to be linked. Finally, XSDs introduce not only over 40 simple data types that need to be mapped to the SQL ones but also complex types which mandated some level of object support.

The W3C Document Object Model(DOM) specification, Simple API for XML (SAX) and Sun Java Architectural Binding for XML (JAXB) all expose the content of an XML document to applications through a standard set of APIs. While these have not been considered client or mid-tier interfaces, if they could operate on the storage model directly sigifcant efficiencies are avaliable especially on large documents or result sets.

In some sense, using an XMLType CLOB is the simplest way to store an XML file. It treats the XML document as exactly that: a document. The file is preserved as a complete text document in storage (with whitespace, comments, and so on intact), by storing it simply as a single, character-based entry in the database. Consequently, files of any size and depth can be stored as long as they are well-formed XML. However, although you may have defined data types in the document for validation against a schema, the data is not typed in the sense that it can be manipulated or retrieved using SQL queries.

Because of this clear limitation, the document must be searched using a text search engine in contrast to SQL queries, which can leverage the functionality of query rewrites, functional indexes, and do on. Efficiently updating the document is limited as it involves pulling the entire file, making the change, and replacing it. If, however, the primary purpose of your XML documents is to encapsulate content in a structure for transformation (as might be the focus in Web publishing, content management, document archiving, and so on), and most changes to content are made at a document level, then the XMLType CLOB is your best choice for XML data storage. In these cases, you aren't likely to need a SQL context for your data, and you get a guarantee of byte-by-byte fidelity.

An alternative to the CLOB XML Type is to create a virtual XML document on top of a set of relational tables as an "XML view." This approach permits a user to insert, update, and delete data in the XML file just as though it were SQL data. Because you are defining a virtual XML document on top of the data store, you aren't limited to just one representation of the data as with CLOB; rather, you can have multiple XML "documents."

Storing data in relational tables also means that you can update individual elements without pulling the entire document. In general, with XMLType Views, you get all the advantages and efficiency that come with SQL operations, because the relational database engine is optimized for these kinds of retrievals. Finally, you can use the SQL data type operations on the XML data types, instead of treating them simply as text. (For example, a date can be treated as a true date from a SQL standpoint, rather than simply a string of characters.).

This approach has some disadvantages, however. Defining XMLType views where the structure is deep (that is, deeper than 8 to 10 tiers) can degrade performance significantly. Inserting and updating views require instead-of-triggers and are more difficult to maintain as you will need to include application code in the trigger. The great virtue of the CLOB approach is the complete preservation of structure and byte-for byte fidelity. But with the XMLType View you lose the guarantee of strict document order, as many items (such as comments and processing instructions) will have disappeared while shredding the document data into tables.

None of this matters, of course, if you are shredding your data for use by data-centric applications that don't "care" about document structure. If your goal is to move data in and out of the database and keep metadata intact as the only context and have all the advantages of DML operations, XMLType Views is ideal: You start from the database schema and generate the corresponding XML schema. Therefore, there is no concept of document order; any required section ordering can be explicitly defined via ROWIDs or other application-specific methods. Functions are provided in the database and XDK to create XML schemas automatically from XMLType Views.

This method is especially useful if you are working with several XML Schemas of differing tag names and structure and do not want them to define your underlying database schema (as when extending an existing legacy database application to now support XML while preserving its legacy functionality). In a typical example, you can repurpose the same data store for a variety of customers who are dictating formats and templates to you. You simply define an XML view for each customer and when you retrieve or insert the data to that view it will have the format appropriate to the corresponding customer.

It is possible to have your cake and eat it too, at least to an extent: You can store your document as a Native XML Type (see below) in Oracle's XML DB repository, which will preserve byte-by-byte document fidelity and also shred it into SQL tables. This approach gives you complete validation while allowing you to do all the DML operations on the document that you get with XML Views. You still get fine-grained data management, and can create multiple views and documents based on the SQL data. When your XML schema is registered, you store your XML data in your database, by simply inserting an XML document file using SQL, PL/SQL, Java, FTP, HTTP, or WebDAV. Getting XML data out of your database can be as simple as executing a SQL query or reading a file using one of those Internet-standard protocols. This functionality is made possible through the built-in query re-write support eliminating the need for the instead-of-triggers.

Besides the ease of working with XML in either its document or data form, you get an enhancement to the W3C-standard Document Object Model (DOM) APIs when programmatically accessing it. When parsing XML from a file you can build an in-memory tree representation of the entire file in order to manipulate it. (This approach is shared other XML processors such as XSLT.) With the "virtual DOM" feature of the native XMLType described below, you build the tree on demand not only preserving resources when using DOM APIs and XSLT, but in cases of large documents or row sets, your application simply works instead of crashing.

There are many advantages to the XML DB repository, but it isn't right for every application. Overhead is involved in maintaining the relationship between the full document and its shredded data. However, the biggest problem comes with schema evolution. Because the document dictates the storing process (mapping which data to which tables), when you want to change the document schema, it is no longer a simple abstraction, but is intimately bound to the database schema whose structure it dictated. That means you can't do most nontrivial changes of either the database or the document schema, without having to export all the data and re-import it into the database.

That could be a real nightmare if you are working with multiple industry schemas and you have to dump your data every time there's a change. If there is no need for document fidelity, these changes can be abstracted from your database schema using the XMLType View storage model described previously.