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 .

This specification distinguishes between the data model as a general concept and specific items (documents, elements, atomic values, etc.) that are concrete examples of the data model by identifying all concrete examples as instances of the data model.

Every instance of the data model is a sequence..

A sequence is an ordered collection of zero or more items. 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 .

An item is either a node or an atomic value,

The topmost node of a tree is called the root node.

Every node is one of the seven kinds of nodes defined in . 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 namespace-nodes accessors. Every node belongs to exactly one tree, and every tree has exactly one root node.

A tree whose root node is a &documentNode; is referred to as a document.

A tree whose root node is not a &documentNode; is referred to as a fragment.

An atomic value is a value in the value space of an atomic type and is labeled with the name of that atomic type.

An atomic type is a primitive simple type or a type derived by restriction from another atomic type. (Types derived by list or union are not atomic.)

There are 21 primitive simple types: the 19 defined in of and xs:untypedAtomic and xs:anyAtomicType, defined in .

A type is represented in the data model by an expanded-QName.

An expanded-QName is a set of three values consisting of a possibly empty prefix, a possibly empty namespace URI, and a local name. See .

Implementation-defined indicates an aspect that may differ between implementations, but must be specified by the implementor for each particular implementation.

Implementation-dependent indicates an aspect that may differ between implementations, is not specified by this or any W3C specification, and is not required to be specified by the implementor for any particular implementation.

In certain situations a value is said to be undefined (for example, the typed value of an element node). This term indicates that the property in question has no value and that any attempt to use its value results in an error.

Within this specification, the term URI refers to a Universal Resource Identifier as defined in and extended in with the new name IRI. The term URI has been retained in preference to IRI to avoid introducing new names for concepts such as “Base URI” that are defined or referenced across the whole family of XML specifications.

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.

In addition to prose, this specification defines a set of accessor functions to explain the data model. The accessors are shown with the prefix dm:. This 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 accessible directly from the host language.

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

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

The signature of accessor functions is shown using the same style as , described in .

This document relies on the and Post-Schema-Validation Infoset (PSVI). Information items and properties are indicated by the styles information item and infoset property, respectively.

Some aspects of type assignment rely on the ability to access properties of the schema components. Such properties are indicated by the style {component property}. Note that this does not mean a lightweight schema processor cannot be used, it only means that the application must have some mechanism to access the necessary properties.

Each node has a unique identity. Every node in an instance of the data model is unique: identical to itself, and not identical to any other node. (Atomic values do not have identity; every instance of the value “5” as an integer is identical to every other instance of the value “5” as an integer.)

A document order is defined among all the nodes accessible 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 in which nodes appear in the XML serialization of a document. 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 relative order of nodes in distinct trees is stable but implementation-dependent, subject to the following constraint: If any node in a given tree, T1, occurs before any node in a different tree, T2, then all nodes in T1 are before all nodes in T2.

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.

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.

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.

The data model supports strongly typed languages such as and that have a type system based on . The type system is formally defined in .

Every item in the data model has both a value and a type. In addition to nodes, the data model can represent atomic values like the number 5 or the string “Hello World.” For each of these atomic values, the data model contains both the value of the item (such as 5 or “Hello World”) and its type name (such as xs:integer or xs:string).

Although this document describes construction of an instance of the data model in terms of infoset properties, an infoset is not a 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 instance must satisfy all of the constraints described in this document.

An instance of the data model can be constructed from an infoset that satisfies the following general constraints:

An instance of the data model constructed from an information set must be consistent with the description provided for each node kind.

An instance of the data model can be constructed from a PSVI, whose element and attribute information items have been strictly assessed, laxly assessed, or have not been assessed. 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 kind.

Data model construction requires that the PSVI provide unique names for all anonymous schema types.

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 schema type assignment. Other differences can also arise from schema processing: default attribute and element values may be provided, white space normalization of element content may occur, and the user-supplied lexical form of elements and attributes with atomic schema types may be lost.

The attributes accessor returns the attributes of a node as a sequence containing zero or more &attributeNode;s. The order of &attributeNode;s is stable but implementation dependent.

It is defined on all seven node kinds.

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 kinds.

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

It is defined on all seven node kinds.

The document-uri accessor returns the absolute URI of the resource from which the &documentNode; was constructed, if the absolute URI is available. If there is no URI available, or if it cannot be made absolute when the &documentNode; is constructed, or if it is used on a node other than a &documentNode;, the empty sequence is returned.

It is defined on all seven node kinds.

The is-id accessor returns true if the node is an XML ID. Exactly what constitutes an ID depends in part on how the data model was constructed, see and .

It is defined on all seven node kinds.

The is-idrefs accessor returns true if the node is an XML IDREF or IDREFS. Exactly what constitutes an IDREF or IDREFS depends in part on how the data model was constructed, see and .

It is defined on all seven node kinds.

The namespace-bindings accessor returns the dynamic, in-scope namespaces associated with a node as a set of prefix/URI pairs, using an implementation-dependent representation.

The prefix for the default namespace is the zero length string.

The namespace-bindings accessor is defined on all seven node kinds.

Note: this accessor and the namespace-nodes accessor provide two views of the same information.

The namespace-nodes accessor returns the dynamic, in-scope namespaces associated with a node as a sequence containing zero or more &namespaceNode;s. The order of &namespaceNode;s is stable but implementation dependent.

It is defined on all seven node kinds.

Note: this accessor and the namespace-bindings accessor provide two views of the same information. Implementations that do not need to expose &namespaceNode;s might choose not to implement this accessor.

The nilled accessor returns true if the node is nilled. introduced the nilled mechanism to signal that an element should be accepted as valid when it has no content even when it has a content type which does not require or even necessarily allow empty content.

It is defined on all seven node kinds.

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

It is defined on all seven node kinds.

The node-name accessor returns the name of the node as a sequence of zero or one xs:QNames. Note that the QName value includes an optional prefix as described in .

It is defined on all seven node kinds.

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

It is defined on all seven node kinds.

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

It is defined on all seven node kinds.

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

It is defined on all seven node kinds.

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 kinds.

The unparsed-entity-public-id accessor returns the public identifier of an unparsed external entity declared in the specified document. If no entity with the name specified in $entityname exists, or if the entity is not an external unparsed entity, or if the entity has no public identifier, the empty sequence is returned.

It is defined on all seven node kinds.

The unparsed-entity-system-id accessor returns the system identifier of an unparsed external entity declared in the specified document. The value is an absolute URI, and is obtained by resolving the system identifier of the unparsed entity information item against the declaration base URI of the same item. If no entity with the name specified in $entityname exists, or if the entity is not an external unparsed entity, the empty sequence is returned.

It is defined on all seven node kinds.