attributes"> base-uri"> children"> content"> namespaces"> nilled"> node-name"> parent"> prefix"> string-value"> target"> type"> uri"> ]>
XQuery 1.0 and XPath 2.0 Data Model &doc.prefix;-&doc.date; W3C Working Draft &date.day; &date.month; &date.year; &url.this; XML http://www.w3.org/TR/xpath-datamodel/ http://www.w3.org/TR/2003/WD-xpath-datamodel-20030502/ Mary Fernández (XML Query WG) AT&T Labs mff@research.att.com Ashok Malhotra (XML Query and XSL WGs) Microsoft ashokma@microsoft.com Jonathan Marsh (XSL WG) Microsoft jmarsh@microsoft.com Marton Nagy (XML Query WG) Science Applications International Corporation (SAIC) marton.nagy@saic.com Norman Walsh (XSL WG) Sun Microsystems Norman.Walsh@Sun.COM

This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the W3C technical reports index at http://www.w3.org/TR/.

This is a Public Working Draft for review by W3C Members and other interested parties. Publication as a Working Draft does not imply endorsement by the W3C Membership. This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to cite this document as other than work in progress.

The XQuery 1.0 and XPath 2.0 Data Model has been defined jointly by the XML Query Working Group and the XSL Working Group (both part of the XML Activity).

This is a Last Call Working Draft which consolidates changes and editorial improvements undertaken in response to feedback received during the previous Last Call publication which begin on 2 May 2003. A list of the Last Call issues addressed by the Working Groups is also available.

Comments on this document are due on 15 February 2004. Comments should be sent to the W3C mailing list public-qt-comments@w3.org. (archived at http://lists.w3.org/Archives/Public/public-qt-comments/) with “[DM]” at the beginning of the subject field.

Patent disclosures relevant to this specification may be found on the XML Query Working Group's patent disclosure page at http://www.w3.org/2002/08/xmlquery-IPR-statements and the XSL Working Group's patent disclosure page at http://www.w3.org/Style/XSL/Disclosures.html.

This document defines the W3C XQuery 1.0 and XPath 2.0 Data Model, which is the data model of at least , , and , and any other specifications that reference it. This data model is based on the data model and earlier work on an . This document is the result of joint work by the and the .

 English

See the CVS changelog.
Introduction

This document defines the XQuery 1.0 and XPath 2.0 Data Model, which is the data model of , and

The XQuery 1.0 and XPath 2.0 Data Model (henceforth "data model") serves two purposes. First, it defines precisely the information contained in the input to an XSLT or XQuery processor. Second, it defines all permissible values of expressions in the XSLT, XQuery, and XPath languages. A language is closed with respect to a data model if the value of every expression in the language is guaranteed to be in the data model. XSLT 2.0, XQuery 1.0, and XPath 2.0 are all closed with respect to the data model.

The data model is based on the (henceforth "Infoset"), but it requires the following new features to meet the and :

Support for XML Schema types. The XML Schema recommendations define features, such as structures () and simple data types (), that extend the XML Information Set with precise type information.

Representation of collections of documents and of complex values. ()

As with the Infoset, the XQuery 1.0 and XPath 2.0 Data Model specifies what information in the documents is accessible, but it does not specify the programming-language interfaces or bindings used to represent or access the data.

Every value in the data model is a sequence of zero or more items.

Every node is one of the seven kinds defined in . Connected nodes form a tree that consists of a root node plus all the nodes that are reachable directly or indirectly from the root node via the children, attributes, and namespaces accessors. Every node belongs to exactly one tree, and every tree has exactly one root node. A tree whose root node is a document node is referred to as a document. A tree whose root node is some other kind of node is referred to as a fragment.

An atomic value encapsulates an XML Schema atomic type and a corresponding value of that type. They are defined in . A sequence is an ordered collection of nodes, atomic values, or any mixture of nodes and atomic values. A sequence cannot be a member of a sequence. A single item appearing on its own is modeled as a sequence containing one item. Sequences are defined in .

In XPath 1.0, the data model only defines nodes. The primitive data types (number, boolean, string, node-set) are part of the expression language, not the data model.

The data model can represent various values including not only the input and the output of a stylesheet or query, but all values of expressions used during the intermediate calculations. Examples include the input document or document repository (represented as a document node or a sequence of document nodes), the result of a path expression (represented as a sequence of nodes), the result of an arithmetic or a logical expression (represented as an atomic value), a sequence expression resulting in a sequence of items, etc.

In this document, we provide a precise definition of the properties of nodes in the XQuery 1.0 and XPath 2.0 Data Model, how they are accessed, and how they relate to values in the Infoset. We note wherever the XQuery 1.0 and XPath 2.0 Data Model differs from that of XPath 1.0.

 Concepts

This section outlines a number of general concepts that apply throughout this specification.

Terminology

For a full glossary of terms, see .

In this specification the words must, must not, should, should not, may and recommended are to be interpreted as described in .

In this specification, the term implementation-defined refers to a feature where the implementation is allowed some flexibility, and where the choices made by the implementation should be described in the vendor's documentation.

The term implementation-dependent refers to a feature where the behavior may vary from one implementation to another, and where the vendor is not expected to provide a full specification of the behavior. (This might apply, for example, to limits on the size of data models that can be constructed.)

In all cases where this specification leaves the behavior implementation-defined or implementation-dependent, the implementation has the option of providing mechanisms that allow the user to influence the behavior.

Paragraphs labeled as Notes or described as examples are non-normative.

 Notation

In addition to prose, we define a set of accessor functions to explain the data model. The accessors defined by the data model are shown with the prefix dm:. The prefix is always shown in italics to emphasize that these functions are abstract; they exist to explain the interface between the data model and specifications that rely on the data model: they are not and cannot be made accessible directly from the host language.

The signature of accessors is shown using the same style as . For example:

Some accessors can accept or return sequences. The following notation is used to denote sequence values:

V* denotes a sequence of zero or more items of type V.

V? denotes a sequence of exactly zero or one items of type V.

V+ denotes a sequence of one or more items of type V.

In a sequence, V may be a node or an atomic value.

There are some functions in the data model that are partial functions. We use the occurrence indicators ? or * when specifying the return type of such functions. For example, a node may have one parent node or no parent. If the node argument has a parent, the parent accessor returns a singleton sequence. If the node argument does not have a parent, it returns the empty sequence. The signature of parent specifies that it returns an empty sequence or a sequence containing one node:

This document relies on the . Information items and properties are indicated by the styles information item and property, respectively.

This document frequently uses the term expanded-QName. An expanded-QName is a pair of values consisting of a namespace URI and a local name. They belong to the value space of the XML Schema type xs:QName. When this document refers to xs:QName we always mean the value space, i.e. a namespace URI, local name pair (and not the lexical space referring to constructs of the form prefix:local-name).

Prefix Bindings

Several prefixes are used throughout this document for notational convenience. The following bindings are assumed.

xs: bound to http://www.w3.org/2001/XMLSchema

xsi: bound to http://www.w3.org/2001/XMLSchema-instance

xdt: bound to http://www.w3.org/&date.year;/&date.MM;/xpath-datatypes

fn: bound to http://www.w3.org/2003/05/xpath-functions

In practice, any prefix that is bound to the appropriate URI may be used.

 Node Identity

Because XML documents are tree-structured, we define the data model using conventional terminology for trees. The data model is a node-labeled, directed graph, in which each node has a unique identity. Every node in the data model is unique: identical to itself, and not identical to any other node.

This concept should not be confused with the concept of a unique ID, which is a unique name assigned to an element by the author to represent references using ID/IDREF correlation.

 Document Order

A document order is defined among all the nodes used during a given query or transformation. Document order is a total ordering, although the relative order of some nodes is implementation-dependent. Informally, document order is the order returned by an in-order, depth-first traversal of the data model. Document order is stable, which means that the relative order of two nodes will not change during the processing of a given query or transformation, even if this order is implementation-dependent.

Within a tree, document order satisfies the following constraints:

The root node is the first node.

The relative order of siblings is determined by their order in the XML representation of the tree. A node N1 occurs before a node N2 in document order if and only if the start of N1 occurs before the start of N2 in the XML representation.

Namespace nodes immediately follow the element node with which they are associated. The relative order of namespace nodes is stable but implementation-dependent.

Attribute nodes immediately follow the namespace nodes of the element with which they are associated. The relative order of attribute nodes is stable but implementation-dependent.

Element nodes occur before their children; children occur before following-siblings.

The relative order of nodes in distinct trees is stable but implementation-dependent, subject to the following constraint: If any node in tree T1 is before any node in tree T2, then all nodes in tree T1 are before all nodes in tree T2.

 Types

The data model uses expanded-QNames to represent the names of named types, which includes both the built-in types defined by and named user-defined types declared in a schema and imported by a stylesheet or query. Since named types in XML Schema are global, an expanded-QName uniquely identifies such a type. The namespace name of the expanded-QName is the target namespace property of the type definition, and its local name is the name property of the type definition.

For anonymous types, the processor must construct an anonymous type name that is distinct from the name of every named type and the name of every other anonymous type. An anonymous type name is an implementation defined, unique type name provided by the processor for every anonymous type declared in an imported schema. Anonymous type names must be globally unique across all anonymous types that are accessible to the processor. In the formalism of this specification, we assume that the anonymous type names are xs:QNames, but in practice implementations are not required to use xs:QNames to represent the implementation-defined names of anonymous types.

The data model associates type information with element nodes, attribute nodes and atomic values. The item is guaranteed to be a valid instance of that type.

When no type information exists for an element or an attribute node we frequently use the terminology element with unknown type or attribute with unknown simple type.

The data model does not represent element or attribute declaration schema components, but it supports various type-related operations. The semantics of other operations, for example, checking if a particular instance of an element node has a given type is defined in .

Data Model Construction

In this section, we describe the constraints on data model construction.

The data model supports well-formed XML documents conforming to . Documents that are not well-formed are, by definition, not XML. XML documents that do not conform to are not supported (nor are they supported by ).

In other words, the data model supports the following classes of XML documents:

Well-formed documents conforming to ,

DTD-valid documents conforming to , and

W3C XML Schema-validated documents.

This document describes how to construct an instance of the data model from an or a Post Schema Validation Infoset (PSVI), the augmented infoset produced by an XML Schema validation episode.

An instance of the data model can also be constructed directly through application APIs, or from non-XML sources such as relational tables in a database.

The data model supports some kinds of values that are not supported by . Examples of these are well-formed document fragments and sequences of documents nodes. The data model also supports values that are not nodes. Examples of these are atomic values, sequences of atomic values, or sequences mixing nodes and atomic values. These are necessary to be able to represent the results of intermediate expressions in the data model during expression processing.

Direct Construction

Although this document describes construction of a data model in terms of infoset properties, an infoset is not an absolutely necessary precondition for building an instance of the data model.

There are no constraints on how an instance of the data model may be constructed directly, save that the resulting data model instance must satisfy all of the constraints described in this document.

 Construction from an Infoset

An instance of the data model can be constructed from an . A data model can only be constructed from infosets that satisfy the following general constraints:

All general and external parsed entities must be fully expanded. The Infoset must not contain any unexpanded entity reference information items.

The infoset must provide all of the properties identified as required in this document. The properties identified as optional may be used, if they are present. All other properties are ignored.

Constructing and instance of the data model from an information set must be consistent with the description provided for each node type.

 Construction from a PSVI

An instance of the data model can be constructed from a PSVI that has been strictly, laxly, or skip validated or validated using any combination assessment modes. Constructing an instance of the data model from a PSVI must be consistent with the description provided in this section and with the description provided for each node type.

An incompletely validated document is an XML document that has a corresponding schema but whose schema-validity assessment has resulted in one or more element or attribute information items being assigned values other than 'valid' for the validity property in the PSVI.

The data model supports incompletely validated documents. Elements and attributes that are not valid are treated as having unknown types.

The most significant difference between Infoset construction and PSVI construction occurs in the area of type assignment. Other differences can also arise from schema processing: default attribute and element values may be provided, whitespace normalization of element content may occur, and the user-supplied lexical form of elements and attributes with atomic types may be lost.

Mapping PSVI Additions to Types

A PSVI element or attribute information item may have a validity property. The validity property may be valid, invalid, or notKnown and reflects the outcome of schema-validity assessment. The only information that can be inferred from an invalid or not known validity value is that the information item is well-formed, therefore, we must associate very general type information with the element or attribute node if it is not known to be valid.

The precise definition of the type of an element or attribute information item depends on the properties of the Infoset or PSVI. In a PSVI, XML Schema only guarantees the existence of either the type definition property, or the type definition namespace, type definition name and type definition anonymous properties. If the type definition refers to a union type, there are further properties defined, that refer to the type definition which actually validated the item's normalized value. These properties are either the member type definition, or the member type definition namespace, member type definition name and member type definition anonymous properties. If these are available, the type of an element or attribute will refer to the member type that actually validated the schema normalized value.

If the validity property exists and is valid, the type of an element or attribute information item is represented by an expanded-QName whose namespace and local name correspond to the first applicable items in the following list:

If member type definition exists and its {name} property is present:

The {target namespace} and {name} properties of the member type definition property.

If the type definition property exists and its {name} property is present:

The {target namespace} and {name} properties of the type definition property.

If member type definition anonymous exists:

If it is false: the member type definition namespace and the member type definition name.

Otherwise, the namespace and local name of the appropriate anonymous type name.

If type definition anonymous exists:

If it is false: the type definition namespace and the type definition name

Otherwise, the namespace and local name of the appropriate anonymous type name.

If the validity property does not exist or is not valid, the type of an element is xdt:untypedAny and the type of an attribute is xdt:untypedAtomic.

 Mapping xsi:nil on Element Nodes

introduced a mechanism for signaling that an element should be accepted as valid when it has no content despite a content type which does not require or even necessarily allow empty content. That mechanism is the xsi:nil attribute.

The data model exposes this special semantic in the &dm.prop.nilled; property.

If the validity property exists on an element node and is valid then if the nil property exists and is true, then &dm.prop.nilled; property is true. In all other cases, including all cases where schema validity assessment was not attempted or did not succeed, the &dm.prop.nilled; property is false.

 Storing xs:dateTime, xs:date, and xs:time Values in the Data Model

permits xs:dateTime, xs:date, and xs:time values both with and without timezones and therefore only specifies a partial ordering between date and time values. In the data model, it is necessary to preserve timezone information.

In order to achieve this goal, xs:dateTime, xs:date, and xs:time values must be stored with care. If the lexical representation of the value includes a timezone, it is converted to UTC as defined by and the timezone in the lexical representation is converted to a xdt:dayTimeDuration value. Implementations must keep track of both these values for each xs:dateTime, xs:date, and xs:time stored.

Lexical representations that do not have a timezone are assumed to be in UTC for the purposes of normalization only. An empty sequence is used for their timezone.

Thus, for the purpose of validation, 2003-01-02T11:30:00-05:00 is converted to 2003-01-02T16:30:00Z, but in the data model it must be stored as as (2003-01-02T16:30:00Z, -PT5H0M). The value 2003-01-16T16:30:00 is stored as (2003-01-02T16:30:00Z, ()) because it has no timezone.

Retreiving the Typed Value of xs:dateTime, xs:date, and xs:time Values

For xs:dateTime, xs:date and xs:time, the typed value is the atomic value that is determined from its stored form as follows:

If the timezone component is not the empty sequence, then the value contains the time component, normalized to the timezone specified by the timezone component, as well as the timezone component. The stored values "(2003-01-02T16:30:00Z, -PT5H0M)" produce the value "2003-01-02T11:30:00-05:00".

If the timezone component is the empty sequence, then the time component without any indication of timezone. The stored values "(2003-01-02T16:30:00Z, ())" produce the value "2003-01-02T16:30:00".

 Data Model Serialization

Constructing an Infoset from an instance of the data model, for example in order to perform schema validity assessment, is accomplished by serializing the document and parsing it. Implementations are not required to implement this process literally, but they must obtain the same result as if they had.

Serialization of the data model is governed by .

 Accessors

A set of accessors is defined on all seven kinds of nodes, see . Some accessors return a constant empty sequence on certain node kinds. Some node kinds have additional accessors that are not summarized here.

In order for applications to be able to operate on instances of the data model, the model must expose properties of the items it contains. The data model does this by defining a family of accessor functions. These are not functions in the literal sense, they are not available for users or applications to call directly, rather they are descriptions of the interface that an implementation of the data model must expose to applications. Functions and operators available to end-users are described in .

base-uri Accessor

The base-uri accessor returns the base URI of a node as a sequence containing zero or one URI reference. For more information about base URIs, see .

It is defined on all seven node types.

 node-kind Accessor

The node-kind accessor returns a string identifying the kind of node. It will be one of “document”, “element”, “attribute”, “processing-instruction”, “comment”, or “text”.

It is defined on all seven node types.

 node-name Accessor

The node-name accessor returns the name of the node as a sequence of zero or one xs:QNames.

It is defined on all seven node types.

 parent Accessor

The parent accessor returns the parent of a node as a sequence containing zero or one nodes.

It is defined on all seven node types.

 string-value Accessor

The string-value accessor returns the string value of a node.

It is defined on all seven node types.

 typed-value Accessor

The typed-value accessor returns the typed-value of the node as a sequence of zero or more atomic values.

It is defined on all seven node types.

 type Accessor

The type accessor returns the name of the type of a node as a sequence of zero or one xs:QNames.

It is defined on all seven node types.

 children Accessor

The children accessor returns the children of a node as a sequence containing zero or more nodes.

It is defined on all seven node types.

 attributes Accessor

The attributes accessor returns the attributes of a node as a sequence containing zero or more attribute nodes.

It is defined on all seven node types.

 namespaces Accessor

The namespaces accessor returns the namespaces associated with a node as a sequence containing zero or more namespace nodes.

It is defined on all seven node types.

 nilled Accessor

The nilled accessor returns true if the node is nilled, see .

It is defined on all seven node types, but always returns the empty sequence for all nodes except elements.

 Nodes

The category of Node values contains seven distinct kinds of nodes: document, element, attribute, text, namespace, processing instruction, and comment. The seven kinds of nodes are defined in the following subsections.

&Document; ∈ &Attribute; &Namespace; &ProcessingInstruction; &Comment; &Text; Atomic Values

An atomic value is a value in the value space of an atomic type labeled with that atomic type. An atomic type is a primitive simple type or a type derived by restriction from another atomic simple type. Types derived by list or union are not atomic.

There are 21 primitive atomic types, the 19 defined in of and xdt:untypedAtomic and xdt:anyAtomicType. The “xdt:” types, including the atomic types xdt:dayTimeDuration and xdt:yearMonthDuration, derived by restriction from xs:duration, are described below.

The value space of the atomic values is the union of the value spaces of the atomic types. This value space clearly includes those atomic values whose type is primitive, but it also includes those whose type is derived by restriction, as derivation by restriction always limits the value space.

Implementors may extend the set of types available. The value space of those types, as well as the behavior of those types when used in expressions, is implementation defined.

An XML Schema simple type definition has a variety which may be atomic, union, or list.

The value of a node whose type is an atomic type is represented as an atomic value of that type.

The value of a node whose type is a union type is represented by the appropriate value for the appropriate member type of the union type. If the member type is an atomic type, the value is represented as an atomic value of that type. If the member type is a list type, the value is represented as a sequence of atomic values whose type is the item type of the list type. The union type information is lost and only the specific type of the actual item is retained.

The value of a node whose type is a list type whose item type is an atomic type is represented by a sequence of atomic values whose type is the item type.

The value of a node whose type is a list type whose item type is a union type is represented by a sequence of atomic values, each of whose type is one of the member types of the union type. The union type information is lost and only the specific types of each individual item is retained.

An atomic value can be constructed from the value's lexical representation. Given a string and an atomic type, the atomic value is constructed in such a way as to be consistent with validation. If the string does not represent a valid value of the type, an error is raised. When xs:untypedAtomic is specified as the type, no validation takes place. The details of the construction are described in and the related section of .

A string value can be constructed from an atomic value. Such a value is constructed by converting the atomic value to its string representation as described in . Using the canonical lexical representation for atomic values may not always be compatible with XPath 1.0. These and other backwards incompatibilities are described in .

New Datatypes xdt:untypedAny

The abstract complex type xdt:untypedAny is a subtype of xs:anyType and serves as a special type annotation to indicate elements that have not been validated by a XML Schema or a DTD or that have received a type annotation of xs:anyType in the PSVI.

This datatype cannot be used in element declarations, nor can it be used as a base for user-defined complex types. It can be used in the production (for example in a function signature) to specify the required type of an element. This datatype resides in the namespace http://www.w3.org/2003/11/xpath-datatypes.

 xdt:untypedAtomic

The abstract atomic type xdt:untypedAtomic is a subtype of xdt:anyAtomicType and serves as a special type annotation to indicate elements or attributes that have not been validated by a XML Schema or DTD, or that have received a type annotation of xs:anySimpleType in the PSVI. It is also used as the type of the typed value of such nodes, and of text nodes.

This datatype cannot be used in element or attribute declarations, nor can it be used as a base for user-defined atomic types, an item type for user-defined list types, or a member type of user-defined union types. It can be used in the production to define a required type (for example in a function signature), to indicate that only an untyped atomic value is acceptable. This datatype resides in the namespace http://www.w3.org/2003/11/xpath-datatypes.

 xdt:anyAtomicType

The abstract simple type xdt:anyAtomicType is a subtype of xs:anySimpleType and is the base type for all the primitive atomic types described in , and for xdt:untypedAtomic.

This datatype cannot be used in element or attribute declarations, nor can it be used as a base for user-defined atomic types, an item type for user-defined list types, or a member type of user-defined union types. It can be used in the production to define a required type (for example in a function signature), to indicate that any atomic value is acceptable. This datatype resides in the namespace http://www.w3.org/2003/11/xpath-datatypes.

 xdt:dayTimeDuration

The datatype xdt:dayTimeDuration is a subtype of xs:duration whose lexical representation contains only day, hour, minute, and second components.

This datatype resides in the namespace http://www.w3.org/&date.year;/&date.MM;/xpath-datatypes.

 xdt:yearMonthDuration

The datatype xdt:yearMonthDuration is a subtype of xs:duration whose lexical representation contains only year and month components.

This datatype resides in the namespace http://www.w3.org/&date.year;/&date.MM;/xpath-datatypes.

 Sequences

A sequence is an ordered collection of zero or more items. An item may be a node or an atomic value, i.e. a sequence may contain nodes, atomic values, or any mixture of nodes and atomic values. When a node is added to a sequence its identity remains the same. Consequently a node may occur in more than one sequence and a sequence may contain duplicate items.

An important characteristic of the data model is that there is no distinction between an item (a node or an atomic value) and a singleton sequence containing that item. An item is equivalent to a singleton sequence containing that item and vice versa.

Sequences never contain other sequences; if sequences are combined, the result is always a “flattened” sequence. In other words, appending “(d e)” to “(a b c)” produces a sequence of length 5: “(a b c d e)”. It does not produce a sequence of length 4: “(a b c (d e))”, such a nested sequence never occurs.

Sequences replace node-sets from XPath 1.0. In XPath 1.0, node-sets do not contain duplicates. In generalizing node-sets to sequences in XPath 2.0, duplicate removal is provided by functions on node sequences.

A collection of documents is represented in the data model as a sequence of document nodes.

Equality comparison of sequences is performed by comparing the items of the sequences. Whereas you can compare the identity of two nodes, you cannot compare the identity of two sequences; you can only determine whether or not they contain the same members.

 XML Information Set Conformance

This specification conforms to the XML Information Set . The following information items must be exposed by the infoset producer to construct a data model:

The Document Information Item with base URI and children properties.

Element Information Items with base URI, children, attributes, in-scope namespaces, local name, namespace name, parent properties.

Attribute Information Items with namespace name, local name, normalized value, attribute type, and owner element properties.

Character Information Items with character code and parent properties.

Processing Instruction Information Items with base URI, target, content and parent properties.

Comment Information Items with content and parent properties.

Namespace Information Items with prefix and namespace name properties.

Other information items and properties made available by the Infoset processor are ignored. In addition to the properties above, the following properties from the PSV Infoset are required:

validity, type definition, type definition namespace, type definition name, type definition anonymous, member type definition, member type definition namespace, member type definition name, member type definition anonymous and schema normalized value properties on Element Information Items.

validity, type definition, type definition namespace, type definition name, type definition anonymous, member type definition, member type definition namespace, member type definition name, member type definition anonymous and schema normalized value properties on Attribute Information Items.

 References Normative References Other References XML Query Data Model, Mary Fernández and Jonathan Robie, Editors. World Wide Web Consortium, 15 Feb 2001. XML Query Working Group, World Wide Web Consortium. Home page: http://www.w3.org/XML/Query XSL Working Group, World Wide Web Consortium. Home page: http://www.w3.org/Style/XSL/ Glossary Example

We use the following XML document to illustrate the information contained in a data model:

&dm-example.xml;

The document is associated with the URI http://www.example.com/catalog.xml, and is valid with respect to the following XML schema:

&dm-example.xsd;

This example exposes the data model for a document that has an associated schema and has been validated successfully against it. In general, an XML Schema is not required, that is, the data model can represent a schemaless, well-formed XML document with the rules described in .

The XML document is represented by the nodes described below. The value D1 represents a document node; the values E1, E2, etc. represent element nodes; the values A1, A2, etc. represent attribute nodes; the values N1, N2, etc. represent namespace nodes; the values P1, P2, etc. represent processing-instruction nodes; the values T1, T2, etc. represent text nodes.

For brevity:

Text nodes in the data model that contain only white space are not shown.

Literal strings are shown in quotes without the xs:string() constructor

Literal decimals are shown without the xs:decimal() constructor

Nodes are referred to using the syntax [nodeID]

xs:QNames are used with the following prefixes:

xshttp://www.w3.org/2001/XMLSchema
xsihttp://www.w3.org/2001/XMLSchema-instance
cathttp://www.example.com/catalog
xlinkhttp://www.w3.org/1999/xlink
htmlhttp://www.w3.org/1999/xhtml

The abbreviation \n is used in string literals to represent a newline character; this isn't supported in XPath, but it makes this presentation clearer.

Accessors that return the empty sequence have been omitted.

To simplify the presentation, we’re assuming an implementation that does not expose the namespace axis. Therefore, we can share namespace nodes across multiple elements. See .

 &dm-example.tbl;

A graphical representation of the data model for the preceding example is shown below. Document order in this representation can be found by following the traditional in-order, left-to-right, depth-first traversal; however, because the image has been rotated for easier presentation, this appears to be in-order, bottom-to-top, depth-first order.

Graphic representation of the data model. [large view, SVG]