What Is XML Data?

XML data can be understood at two levels: the textual representation, and the model of this data as a tree of nodes.

XML as Text

XML is often seen in its textual form. As text, XML may be viewed in any text editor and easily passed around the World Wide Web using text-based protocols such as HTTP. The example below shows some XML text. Note the tags Person and FirstName . Such tags give names to the data.

 <?xml version="1.0"?> <Person id="12">    <FirstName>John</FirstName>    <LastName>Smith</LastName> <Person> 

XML Data Model

In a rough sense, the XML data model (XML Infoset [INFOSET]) describes XML as a tree of data. The XQuery data model is essentially this same tree definition with some important additions, such as sequences and primitive datatypes. As earlier chapters have illustrated , the XQuery data model [XQ-DM] is a central foundation of the XQuery language. In a native XML database, the XQuery data model is also fundamentally important to the architecture of the DBMS. The XQuery data model is used throughout a native XML DBMS to model all XML data as it flows from a stored document collection, through the XQuery system, and out to the client applications via a result set.

The XQuery data model (henceforth called the data model) supports a set of possible values, referred to as the value space of the data model. The data values in the value space conform to the data model definition. Often, values in the value space are referred to as "instances of the data model" (more strictly , they are instances of the top-level type defined in the data model, which is the type sequence). By implication , the data model also defines what lies outside the value space: For example, a nonconforming value would be an attribute node that had a child attribute node. Figure 8.1 shows an example data value resulting from the XML in the preceding example of XML text (the Person document text). This Person document value conforms to the data model diagrammed in Figure 8.2, which is a Unified Modeling Language (UML) diagram that defines the XQuery data model.

Figure 8.1. Person Document Value

Figure 8.2. The XQuery Data Model

Figure 8.2 reflects the set of valid values supported by the data model. Inevitably, it is a simplification. It doesn't specify all the constraints (for example, the fact that an element node cannot contain a document node). It doesn't attempt to show that element nodes and attribute nodes have a typed value, which can be any sequence of atomic values. Further, it shows the constraints that apply to a well- formed document as defined in the XML recommendation [XML] and the XML Infoset [INFOSET] ” namely, that a document node contains exactly one element node as a direct child. In fact, the data model relaxes this constraint, largely to allow the temporary trees used by XSLT (remember that the data model is shared between XQuery and XSLT).

The Person document tree in Figure 8.1 conforms to the data model defined in Figure 8.2. In fact, using Figure 8.2 as a UML static class diagram and using Figure 8.1 as an instance diagram, you can see that Figure 8.1 is a conforming instance of the Sequence class defined in Figure 8.2. We can describe the correspondence of the Person document to the data model definition as follows :

• The Person document has a DocumentNode at its root. Document Node is a subclass of Node , which is itself a subclass of Item. An Item may be contained in a Sequence , so the top level conforms. Since we only have one document, the Sequence is of length one. This DocumentNode , in turn , has a child Element Node named Person , which has an AttributeNode named id . An element node is not said to have "child" attribute nodes; rather, it just has attribute nodes. This is consistent with the child:: and attribute:: axes in XPath. Following along, the Person element has a child element named FirstName , which in turn has a child TextNode with a value of "John" . The other parts of the tree can be similarly described.

• Text nodes containing whitespace only have been ignored in this example. The data model allows insignificant whitespace to be stripped from the tree, and the example assumes that this has been done.

The data model definition above reveals that the value space allows other kinds of values, not only documents. For example, a sequence of xs:decimal values without any enclosing node conforms to the data model. A sequence of DocumentNode s also conforms. Such values do not correspond directly to any well-formed textual document described by the XML 1.0 Recommendation [XML], and they are not well-formed XML Infoset [INFOSET] instances. Allowing such values, however, makes the XQuery data model more flexible, in that any constituent part or sequence of parts of an XML document can flow through XQuery and the XML DBMS and are conforming values with respect to the XQuery data model.

The most obvious use of the XQuery data model is to describe the persistent documents stored in the database. But in a native XML database, the XQuery data model does more than just describe the persistent documents. For example, it also describes the following:

• Collections : Collections, in the terminology of XQuery, are the sets of documents that comprise a persistent database: They are the raw input to a query. A collection itself is modeled as a sequence, typically a sequence of document nodes. This doesn't necessarily mean that order of documents in a database is significant, but it reuses the general-purpose concept of a sequence in the data model and allows persistent collections to be manipulated in the query language in the same way as any other sequence.

• Working data : During the processing of XQuery, expression values may be constructed to represent intermediate results, all of which are sequences of nodes and/or atomic values ”in other words, they are instances of the data model. This means that any temporary data constructed in the course of query processing can be manipulated using the full power of the XQuery language in exactly the same way as persistent data.

• Query results : The result of a query is also a sequence of nodes and/or atomic values ”again, a value conforming to the data model. The XQuery specification doesn't say how the results are delivered to a user or to an application; this is up to the implementation to define. Perhaps a standard XQuery client API will emerge in future, but in the meantime, each implementation defines its own. An example of such an API is described later in the chapter. Implementations may also deliver results in other ways: Tamino [TAMINO], for example, allows a query to be submitted in the form of an HTTP request to a web server and returns the results of the query as the response to the HTTP request, serialized as an XML document.