This section outlines a number of general concepts that apply throughout this specification.
In this document, examples and material labeled as "Note" are provided for explanatory purposes and are not normative.
For a full glossary of terms, see
In this specification the words
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
Sometimes it is necessary to distinguish the case where a
particular property has no value in the data model. The canonical
example of such a case is the namespace URI property of an
Thus the root node is merely a designator, based on position, for one of the nodes in the tree without implying what kind of a node it is. In the XPath 1.0 datamodel the root node was a kind of node.
Every node is one of the seven kinds of nodes defined in
xs:untypedAtomic and
xs:anyAtomicType
A type is represented in the data model by an
Within this specification, the term URI refers to a Universal
Resource Identifier as defined in
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
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
fn: bound to
http://www.w3.org/2005/xpath-functions
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
This document relies on the
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
The concept of node identity 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.
Within a tree, document order satisfies the following constraints:
The root node is the first node.
Every node occurs before all of its children and descendants.
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. If there are no Namespace Nodes associated with a given element, then the Attribute Nodes associated with that element immediately follow the element. The relative order of Attribute Nodes is stable but implementation-dependent.
The relative order of siblings is the order in which they occur in
the
Children and descendants 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 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, function item, or 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 any mixture of nodes, function items, 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
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 3.0, duplicate removal is provided by functions on node sequences.
The specifications
In some interfaces, namespace names are held as values of type
xs:anyURI. For example, the namespace part of an expanded QName is
defined to be a value of type xs:anyURI. In
xs:anyURI imposes some
restrictions on the value space, but there is latitude for
implementors to decide exactly what these restrictions are. In
xs:anyURI value, so any sequence of characters is
acceptable within the value space. In this and related specifications,
the use of the type xs:anyURI to hold a namespace name does not imply
any restrictions on the value space beyond those described in this
section: implementations
The data model supports strongly typed languages such as
The Schema Component Model includes a number of kinds of component, such as type definitions and element and attribute declarations, and defines the properties and relationships of these components. Many of these components and properties are not used by the language specifications that rely on XDM, and where this is the case, there is no requirement for implementations to make them visible. However, this specification makes no attempt to define the minimal subset of the schema component model that is needed to support the semantics of XPath and XQuery processing.
There are two main areas where the language semantics depend on information in schema components:
Expressions are evaluated with respect to a static context, which includes schema components, specifically type definitions, element declarations, and attribute declarations. The names of such components may be used in language constructs only if the components are present in the static context.
Values including element and attribute nodes, and atomic values, have a property called a type annotation whose value is a type: this is a reference to a type definition in the Schema Component Model.
Every xs:integer or xs:string)xs:integer or xs:string), or a user-defined type.
There is a constraint that the total set of components used during expression processing (both statically and dynamically) must constitute a valid schema. This implies, for example, that this total set does not include two different types with the same expanded name.
This makes it the responsibility of the processor to ensure that the schema components used in the static context of a query or expression during static analysis are consistent with the schema components used to validate documents during query or expression evaluation. This specification does not say how this should be achieved.
It is also a constraint that the schema available to the processor must contain at least the components and properties needed to correctly implement the semantics of the XPath and XQuery language. For example, this means that given a node with a particular type annotation T, and a function that expects an argument of type S, there must be sufficient information available to the processor to establish whether or not T is derived from S. As with other consistency constraints described in this data model, it is a precondition that these constraints are satisfied; the specifications do not speculate on what happens if they are not.
The data model uses
For XML Schema types, 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.
The data model relies on the fact that an expanded-QName uniquely identifies every named type. Although it is possible for different schemas to define different types with the same expanded-QName, at most one of them can be used in any given validation episode. The data model cannot support environments where different types with the same expanded-QName are available.
For anonymous types, the processor xs:QNames, but in practice
implementations are not required to use xs:QNames to
represent the implementation-dependent names of anonymous types.
The scope over which the names of anonymous types must be meaningful and distinct is depends on the processing context. It is the responsibility of the host language to define the size and scope of the processing context.
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 schema type is defined in
In addition to the 19 types defined in
xs:anyAtomicType,
xs:untyped, xs:untypedAtomic,
xs:dayTimeDuration, and
xs:yearMonthDuration.
These types are defined in the XML Schema namespace with permission
of the XML Schema Working Group, which is expected to add them to
some future version of XML Schema.
The datatype
The datatype xs:untypedAtomic. No
predefined types are derived from xs:untypedAtomic.
The datatype xs:anySimpleType from which all simple
types, including atomic, list, and union types are derived. All
primitive atomic types, such as xs:decimal and
xs:string, have xs:anyAtomicType
as their base type.
The type xs:dayTimeDuration is derived from
xs:duration by restricting its lexical representation to
contain only the days, hours, minutes and seconds components. The
value space of xs:dayTimeDuration is the set of
fractional second values. The components of
xs:dayTimeDuration correspond to the day, hour, minute
and second components defined in Section 5.5.3.2 of xs:dayTimeDuration is
derived from xs:duration as follows:
The type xs:yearMonthDuration is derived from
xs:duration by restricting its lexical representation to
contain only the year and month components. The value space of
xs:yearMonthDuration is the set of
xs:integer month values. The year and month components of
xs:yearMonthDuration correspond to the Gregorian year
and month components defined in section 5.5.3.2 of
The type xs:yearMonthDuration is derived from
xs:duration as follows:
A schema for these types is provided in
The diagrams below show how nodes, function items,
The xs:IDREFS, xs:NMTOKENS, and
xs:ENTITIES types and the user-defined list and union types
are special types in that these types are lists or unions
rather than types derived by extension or restriction.
The first diagram and its corresponding table illustrate
the item
type hierarchy.
In XDM, items include node types, function types, and built-in atomic types.
In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.
| item | |||
| xs:anyAtomicType | |||
| node | |||
| attribute | |||
| user-defined attribute types | |||
| comment | |||
| document | |||
| user-defined document types | |||
| element | |||
| user-defined element types | |||
| processing-instruction | |||
| text |
The next diagram and table illustrate the any type
type hierarchy, in which
all types are derived from distinguished type xs:anyType.
In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.
| xs:anyType | ||
| user-defined complex types | ||
| xs:untyped | ||
| xs:anySimpleType | ||
| user-defined list and union types | ||
| xs:IDREFS | ||
| xs:NMTOKENS | ||
| xs:ENTITIES | ||
| xs:anyAtomicType |
The final diagram and table show all of the atomic types, including the primitive simple types and the
built-in types derived from the primitive simple types.
This includes all the built-in datatypes defined in
In the table, each type whose name is indented is derived from the type whose name appears nearest above it with one less level of indentation.
| xs:untypedAtomic | ||||||
| xs:dateTime | ||||||
| xs:dateTimeStamp | ||||||
| xs:date | ||||||
| xs:time | ||||||
| xs:duration | ||||||
| xs:yearMonthDuration | ||||||
| xs:dayTimeDuration | ||||||
| xs:float | ||||||
| xs:double | ||||||
| xs:precisionDecimal | ||||||
| xs:decimal | ||||||
| xs:integer | ||||||
| xs:nonPositiveInteger | ||||||
| xs:negativeInteger | ||||||
| xs:long | ||||||
| xs:int | ||||||
| xs:short | ||||||
| xs:byte | ||||||
| xs:nonNegativeInteger | ||||||
| xs:unsignedLong | ||||||
| xs:unsignedInt | ||||||
| xs:unsignedShort | ||||||
| xs:unsignedByte | ||||||
| xs:positiveInteger | ||||||
| xs:gYearMonth | ||||||
| xs:gYear | ||||||
| xs:gMonthDay | ||||||
| xs:gDay | ||||||
| xs:gMonth | ||||||
| xs:string | ||||||
| xs:normalizedString | ||||||
| xs:token | ||||||
| xs:language | ||||||
| xs:NMTOKEN | ||||||
| xs:Name | ||||||
| xs:NCName | ||||||
| xs:ID | ||||||
| xs:IDREF | ||||||
| xs:ENTITY | ||||||
| xs:boolean | ||||||
| xs:base64Binary | ||||||
| xs:hexBinary | ||||||
| xs:anyURI | ||||||
| xs:QName | ||||||
| xs:NOTATION |
An atomic value can be constructed from a lexical
representation. Given a string and an atomic type, the atomic value is
constructed in such a way as to be
xs:untypedAtomic is specified as the type,
no validation takes place. The details of the construction are
described in
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
The xs:float and xs:double data types
in the data model have the same value space as in
XML Schema 1.1 (
To accommodate this difference,
when converting from an
xs:string to an xs:float or
xs:double, it is implementation-defined whether the
lexical value “-0” (and similar forms such as “-0.0”) convert to
negative zero or to positive zero in the value space.
xs:string to an xs:float or
xs:double, it is implementation-defined whether the
lexical value “-0” (and similar forms such as “-0.0”) convert to
negative zero or to positive zero in the value space.The XPath Data Model is the abstraction over which XPath expressions are evaluated. Historically, all of the items in the data model could be derived directly (nodes) or indirectly (typed values, sequences) from an XML document. However, as the XPath expression language has matured, new features have been added which require additional types of items to appear in the data model. These items have no direct XML serialization, but they are never the less part of the data model.
A function item consists of the following information:
The set of variable values for the variables referenced by the function.
The name of the function as a xs:QName. This is potentially
The signature of the function item.
The function implementation.
The space of all possible function(*), which is itself a subtype of item(). Subtypes of function(*)
are partitioned into discrete types, each representing
function(item()) as item() is a subtype of function(*)
function(item()) as xs:integer is a subtype of function(item()) as item()
function(xs:string) as item() is a subtype of function(item()) as item()
FIXME: do we need to define map accessors: map-contains, map-get, map-put?