2 Terminology and Concepts

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.

2.1 Terminology

For a full glossary of terms, see D Glossary.

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

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

[Definition: 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 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.

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.

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 expanded QName that is not in any namespace. For such properties, it is convenient to be able to speak of "the state of having no value". [Definition: When a property has no value, we say that it is absent.]

Within this specification, the term URI refers to a Uniform Resource Identifier as defined in [RFC 3986] and extended in [RFC 3987] 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.

2.2 Basic Concepts

[Definition: Every instance of the data model is a sequence.]

[Definition: 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 2.6 Sequences.

[Definition: Because every value is a sequence, the term value is used synonymously with sequence.]

[Definition: An item is either a node, a function, or an atomic value.]

[Definition: An item type represents a class of items.] An item is said to be an instance of an item type (or to match the item type) if it is a member of that class. Items generally belong to more than one item type, and the membership of different item types is overlapping.

Every node is one of the seven kinds of nodes defined in Section 6 Nodes. Nodes form a tree. Each node has at most one parent (reachable via the dm:parent accessor) and descendant nodes that are reachable directly or indirectly via the dm:children, dm:attributes, and dm:namespace-nodes accessors.

[Definition: The root node is the topmost node of a tree, the node with no parent.] Every tree has exactly one root node and every other node can be reached from exactly one root node.

Note:

The term “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.

Note:

Generally, the term tree is used to refer to a complete tree rooted at a parentless node. On occasions, which should be clear from the context, the same term is used to refer to a subtree, that is, a tree forming part of a larger tree.

[Definition: A tree whose root node is a Document Node is referred to as a document.]

[Definition: A tree whose root node is not a Document Node is referred to as a fragment.]

[Definition: An atomic value is a pair (T, D) where T (the type annotation) is an atomic type, and D (the datum) is a point in the value space of T.]

[Definition: The datum of an atomic value is a point in the value space of its type, which is also a point in the value space of the primitive type from which that type is derived.] There are 20 primitive atomic types (19 defined in XSD, plus xs:untypedAtomic), and these have non-overlapping value spaces, so each datum belongs to exactly one primitive atomic type.

Note:

The term value space is defined in [Schema 1.1 Part 2], as a set of values. The term datum is used here in preference to value, because value has a different meaning in this data model.

[Definition: An atomic type is either a primitive simple type with variety atomic, or a type derived by restriction from another atomic type.] (Types derived by list or union are not atomic.)

Note:

Atomic types include the 19 primitive atomic types defined in XSD (such as xs:string, xs:boolean, and xs:decimal), the built-in non-primitive types defined in XSD (such as xs:integer, and xs:NCName, and xs:dayTimeDuration), atomic types derived from these in a user-defined schema, and the special type xs:untypedAtomic.

[Definition: The primitive simple types are the types defined in 2.2.1 Types adopted from XML Schema.]

[Definition: The term type annotation has two slightly different meanings. For an atomic value, the type annotation of the value is the most specific atomic type that it is an instance of (it is also an instance of every type from which that type is derived). For an element or attribute node, the type annotation is the schema type (a simple or complex type) against which the node has been validated, defaulting to xs:untypedAtomic for unvalidated attribute nodes, and xs:untyped for unvalidated element nodes.]

Named types are identified in the data model by an expanded-QName. A schema may also contain anonymous types, and these may be used as type annotations on nodes and atomic values; anonymous types, however, cannot be referenced explicitly in programs.

[Definition: An expanded-QName is a triple consisting of a possibly absent prefix, a possibly absent namespace URI, and a local name.] See 3.3.3 QNames and NOTATIONS.

2.2.1 Types adopted from XML Schema

[Definition: A schema type corresponds to a type definition component as defined in XSD.] Schema types are either complex types or simple types; simple types are either atomic types, list types, or union types.

The data model adopts the following schema types:

  • The 19 primitive atomic types defined in Section 3.2 Primitive datatypesXS2 of [Schema Part 2].

  • Three built-in list types: xs:NMTOKENS, xs:IDREFS, and xs:ENTITIES.

    The following types which were originally defined in [XQuery 1.0 and XPath 2.0 Data Model (XDM)] and were subsequently adopted by [Schema 1.1 Part 2]: xs:anyAtomicType, xs:dayTimeDuration, xs:yearMonthDuration.

  • In the case of a processor that supports [Schema 1.1 Part 2], the data model also includes: the new union type xs:error (a type with no instances) and the new derived type xs:dateTimeStamp.

  • The following types, although they use the xs: namespace, are defined here in the data model and not in XML Schema: xs:untypedAtomic, and xs:numeric, a union type whose members are xs:double, xs:float and xs:decimal.

Schema types fulfil a different role from item types. Schema types other than atomic types arise in the data model only as type annotations on element and attribute nodes. Nodes are not instances of schema types in the sense of the XPath instance of operator; but an element or attribute node may be an instance of the item type element(*, S) or attribute(*, S) where S is a schema type. The node matches this item type if its type annotation is S, or a type derived from S, which will be the case if the node has been validated against type S in the course of schema validation.

Schema types and item types form overlapping categories:

  • Atomic types belong to both categories.

  • Node types and function types are item types, but they are not schema types.

  • Complex types, list types, and union types are schema types, but they are not item types.

2.3 Notation

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.

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

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

  3. 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 [XQuery and XPath Functions and Operators 4.0], described in Section 1.4 Function signatures and descriptionsFO40.

This document relies on the [Infoset] 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.

2.4 Node Identity

Each node has a unique identity. The identity of a node is distinct from its value or other visible properties; nodes may be distinct even when they have the same values for all intrinsic properties other than their identity. (The identity of atomic values, by contrast, is determined solely by their intrinsic properties. No two distinct integers, for example, have the same value; every instance of the value “5” as an integer is identical to every other instance of the value “5” as an integer.)

Note:

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.

2.5 Document Order

[Definition: 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.] [Definition: 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:

  1. The root node is the first node.

  2. Every node occurs before all of its children and descendants.

  3. Namespace Nodes immediately follow the Element Node with which they are associated. The relative order of Namespace Nodes is stable but implementation-dependent.

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

  5. The relative order of siblings is the order in which they occur in the children property of their parent node.

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

2.6 Sequences

An important characteristic of the data model is that there is no distinction between an item (a node, function, 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, functions, 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.

Note:

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

Note:

Arrays and maps are derived from functions and therefore can also be contained within sequences.

2.7 Namespace Names

The specifications [Namespaces in XML] and [Namespaces in XML 1.1] introduce the concept of a namespace name. In [Namespaces in XML] a namespace name is required to be a URI; in [Namespaces in XML 1.1] it is required to be an IRI; but both specifications explicitly do not require a processor to check that namespace names appearing in an instance document are in fact valid URIs or IRIs.

[Definition: This specification uses the term Namespace URI to refer to a namespace name, whether or not it is a valid URI or IRI]. Following the lead of [Namespaces in XML] and [Namespaces in XML 1.1], processors implementing this data model may raise an error if a namespace name is not a valid URI or IRI (depending on whether they support [Namespaces in XML] or [Namespaces in XML 1.1]), but they are not required to make any checks. Note that the use of a relative reference as a namespace name is deprecated and is defined to be meaningless, but it is not an error. Namespace names, whatever form they take, are treated as character strings and compared for equality using codepoint-by-codepoint comparison, subject only to whitespace normalization if they appear in a context (for example, within an attribute value) where this is appropriate.

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 [Schema Part 2], the type xs:anyURI imposes some restrictions on the value space, but there is latitude for implementors to decide exactly what these restrictions are. In [Schema 1.1 Part 2] there are no restrictions on the form of an 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 may reject character strings that are not valid URIs or IRIs, but they are not required to do so.

2.8 Schema Information

The data model supports strongly typed languages such as [XML Path Language (XPath) 4.0] and [XQuery 4.0: An XML Query Language] that have a type system based on [Schema Part 1]. To achieve this, the data model includes (by reference) the Schema Component Model described in [Schema Part 1].

Note:

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:

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

  2. 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 item is an instance of one or more item types:

There is a constraint that the total set of schema 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.

Note:

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 an element node with a particular type annotation T, and a function that expects an argument of type element(*, 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.

2.8.1 Representation of Types

The data model uses expanded-QNames to represent the names of schema types, which include the built-in types defined by [Schema Part 2], five additional types defined by this specification, and may include other user- or implementation-defined types.

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.

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.

Note:

The type annotation of a schema-validated node, or of an atomic value extracted by atomizing a schema-validated node, may be an anonymous type. Queries and expressions cannot refer explicitly to anonymous types, but it is always possible to test whether such an item matches a named type from which the anonymous type is derived.

2.8.2 Predefined Types

In addition to the 19 primitive atomic types defined in Section 3.2 Primitive datatypesXS2 of [Schema Part 2], the data model defines five additional atomic types: 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; in implementations that support [Schema 1.1 Part 2], the XSD 1.1 definitions of xs:anyAtomicType, xs:dayTimeDuration, and xs:yearMonthDuration supersede the definitions in this specification.

xs:untyped

The datatype xs:untyped denotes the dynamic type of an element node that has not been validated, or has been validated in skip mode. The properties of xs:untyped are the same as the properties of xs:anyType except for the base type and name. The base type of xs:untyped is xs:anyType. No predefined types are derived from xs:untyped and no such derivations are allowed.

xs:untypedAtomic

The datatype xs:untypedAtomic denotes untyped atomic data, such as text that has not been assigned a more specific type. An attribute that has been validated in skip mode is represented in the Data Model by an attribute node with the type xs:untypedAtomic. No predefined types are derived from xs:untypedAtomic and no such derivations are allowed.

xs:anyAtomicType

The datatype xs:anyAtomicType is an atomic type that includes all atomic values (and no values that are not atomic). Its base type is 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.

No type may be derived from xs:anyAtomicType by restriction, union, or list.

xs:dayTimeDuration

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 [ISO 8601]. An xs:dayTimeDuration is derived from xs:duration as follows:

<xs:simpleType name='dayTimeDuration'>
  <xs:restriction base='xs:duration'>
    <xs:pattern value="[^YM]*[DT].*"/>
  </xs:restriction>
</xs:simpleType>
xs:yearMonthDuration

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 [ISO 8601], respectively.

The type xs:yearMonthDuration is derived from xs:duration as follows:

<xs:simpleType name='yearMonthDuration'>
  <xs:restriction base='xs:duration'>
    <xs:pattern value="[^DT]*"/>
  </xs:restriction>
</xs:simpleType>

A schema for xs:dayTimeDuration and xs:yearMonthDuration is provided in C Schema for the Extended XS Namespace.

2.8.3 XML and XSD Versions

Some of the types defined in XML Schema have differing definitions in XSD 1.0 and XSD 1.1; furthermore, some types are defined by reference to other specifications including XML and XML Namespaces, and these too may vary from one version of the specification to the next.

As a general policy, implementations of data types should support the latest definitive version of any referenced specification, even if that is published after the date of this specification.

This means, for example, that the xs:string data type should (at the time of writing) support the set of characters defined by the Char production in XML 1.1 Second Edition. Similarly, the xs:anyURI data type should support the definition used in XSD 1.1 (which allows any sequence of characters), and the xs:NCName data type should support the definition based on the syntax of a name as defined in both XML 1.1 Second Edition and XML 1.0 Fifth Edition (which are the same).

In practice interoperability problems can arise both because specifications are not always in synchronization with each other (for example, XSD 1.0 contains references to dated versions of XML 1.0 other than the latest version), and also because implementations may use third-party components (such as XML parsers, serializers, and schema validators) that were built against different versions of the base specifications. For these reasons, use of the latest version of referenced specifications is generally recommended but not required. It is implementation-dependent how a processor handles any such conflicts.

[Definition: A string is a sequence of zero or more characters, or equivalently, a value in the value space of the xs:string data type.]

[Definition: A character is an instance of the Char production in [XML]. ]

[Definition: A codepoint is a non-negative integer assigned to a character by the Unicode consortium, or reserved for future assignment to a character.]

2.8.4 Type System

The diagrams below show how nodes, functions, primitive simple types, and user defined types fit together into a type system. This type system comprises two distinct subsystems that both include the primitive simple types. In the diagrams, connecting lines represent relationships between derived types and the types from which they are derived; the arrowheads point toward the type from which they are derived. The dashed line represents relationships not present in this diagram, but that appear in one of the other diagrams. Dotted lines represent additional relationships that follow an evident pattern. The information that appears in each diagram is recapitulated in tabular form.

The xs:IDREFS, xs:NMTOKENS, xs:ENTITIES types, and xs:numeric and both the user-defined list types and user-defined 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 relationship of various item types. Item types in the data model form a directed graph, rather than a hierarchy or lattice: in the relationship defined by the derived-from(A, B) function, some types are derived from more than one other type. Examples include functions (function(xs:string) as xs:int is substitutable for function(xs:NCName) as xs:int and also for function(xs:string) as xs:decimal), and union types (A is substitutable for union(A, B) and also for union(A, C). In XDM, item types include node types, function types, and built-in atomic types. The diagram, which shows only hierarchic relationships, is therefore a simplification of the full model.

%3 anyAtomicType xs:anyAtomicType xitem item xitem->anyAtomicType xnode node xitem->xnode function function(*) xitem->function attribute attribute xnode->attribute document document xnode->document element element xnode->element leafNodes text comment processing-instruction namespace xnode->leafNodes user_defined_attribute_types user-defined attribute types attribute->user_defined_attribute_types user_defined_document_types user-defined document types document->user_defined_document_types user_defined_element_types user-defined element types element->user_defined_element_types array array(*) function->array map map(*) function->map %3 cluster_legend Legend _bat Built-in atomic types _nod Node types _fit Function item types _udt User-defined types _abt Abstract types

The image shows a portion of the type hierarchy, rooted at the abstract type item. The types xs:anyAtomicType, and the abstract types for nodes and functions are derived from item. Arrays and maps are further derived from functions. Attribute, document, element, text, comment, processing-instruction, and namespace nodes are derived from node. User-defined attribute, document, and element types are also be derived from attribute, document, and element, respectively.

The next diagram and table illustrate the schema type subsystem, in which all types are derived from distinguished type xs:anyType.

%3 cluster_XmlSchemaTypes cluster_simpleTypes cluster_atomicTypes anyType xs:anyType conc_xsd XML Schema types anyType->conc_xsd anySimpleType xs:anySimpleType anyType->anySimpleType complex_types complex types anyType->complex_types conc_simple Simple types anySimpleType->conc_simple anyAtomicType xs:anyAtomicType anySimpleType->anyAtomicType list_types list types anySimpleType->list_types union_types union types anySimpleType->union_types conc_atomic Atomic types anyAtomicType->conc_atomic listTypes xs:IDREFS xs:NMTOKENS xs:ENTITIES list_types->listTypes user_defined_list_types user-defined list types list_types->user_defined_list_types numeric xs:numeric union_types->numeric user_defined_union_types user-defined union types union_types->user_defined_union_types untyped xs:untyped complex_types->untyped user_defined_complex_types user-defined complex types complex_types->user_defined_complex_types %3 cluster_legend Legend _bat Built-in atomic types _bic Built-in complex types _fit Built-in list types _udt User-defined types _abt Conceptual types

The image shows a portion of the type hierarchy, rooted at xs:anyType which represents, conceptually, all of the XML Schema types. The xs:anySimpleType, representing conceptually all of the simple types, and all of the conceptual complex types, are derived from xs:anyType. The xs:anyAtomicType representing conceptually all of the atomic types, and all of the conceptual list and union types are derived from xs:anySimpleType. The types xs:IDREFS, xs:NMTOKENS, xs:ENTITIES, and user-defined list types are derived from list types. The types xs:numeric and user-defined union types are derived from the union types. The types xs:untyped and user-defined complex types are derived from complex types.

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 [Schema Part 2].

%3 anyAtomicType xs:anyAtomicType untypedAtomic xs:untypedAtomic anyAtomicType->untypedAtomic string xs:string anyAtomicType->string duration xs:duration anyAtomicType->duration dateAndTime xs:date xs:time anyAtomicType->dateAndTime dateTime xs:dateTime anyAtomicType->dateTime floatingPoint xs:double xs:float anyAtomicType->floatingPoint decimal xs:decimal anyAtomicType->decimal binaryTypes xs:base64Binary xs:hexBinary anyAtomicType->binaryTypes boolean xs:boolean anyAtomicType->boolean anyURI xs:anyURI anyAtomicType->anyURI QName xs:QName anyAtomicType->QName NOTATION xs:NOTATION anyAtomicType->NOTATION gDateTypes xs:gYear xs:gMonth xs:gDay xs:gYearMonth xs:gMonthDay anyAtomicType->gDateTypes normalizedString xs:normalizedString string->normalizedString dateTimeStamp xs:dateTimeStamp durationTypes xs:yearMonthDuration xs:dayTimeDuration duration->durationTypes integer xs:integer nonPositiveInteger xs:nonPositiveInteger integer->nonPositiveInteger long xs:long integer->long nonNegativeInteger xs:nonNegativeInteger integer->nonNegativeInteger negativeInteger xs:negativeInteger nonPositiveInteger->negativeInteger int xs:int long->int short xs:short int->short byte xs:byte short->byte unsignedLong xs:unsignedLong nonNegativeInteger->unsignedLong positiveInteger xs:positiveInteger nonNegativeInteger->positiveInteger unsignedInt xs:unsignedInt unsignedLong->unsignedInt unsignedShort xs:unsignedShort unsignedInt->unsignedShort unsignedByte xs:unsignedByte unsignedShort->unsignedByte dateTime->dateTimeStamp decimal->integer token xs:token normalizedString->token language xs:language token->language NMTOKEN xs:NMTOKEN token->NMTOKEN Name xs:Name token->Name NCName xs:NCName Name->NCName idTypes xs:ID xs:IDREF NCName->idTypes ENTITY xs:ENTITY NCName->ENTITY %3 cluster_legend Legend _bat Built-in atomic types

The image shows a portion of the type hierarchy, rooted at xs:anyAtomicType. The types xs:untypedAtomic, xs:string, xs:duration, xs:date, xs:time, xs:dateTime, xs:double, xs:float, xs:decimal, xs:base64Binary, xs:hexBinary, xs:boolean, xs:anyURI, xs:QName, xs:Notation, xs:gYear, xs:gMonth, xs:gDay, xs:gYearMonth, and xs:gMonthDay are derived from xs:anyAtomicType.

Starting at xs:string, xs:normalizedString is derived and xs:token is derived from that. The types xs:language, xs:NMTOKEN, and xs:Name are derived from xs:token. The type xs:NCName is further derived from xs:Name, and the types xs:ID, xs:IDREF, and xs:ENTITY are derived from xs:NCName.

The types xs:yearMonthDuration and xs:dayTimeDuration are derived from xs:duration.

The type xs:integer is derived from xs:decimal. The types xs:nonPositiveInteger (and from that xs:negativeInteger), xs:long, and xs:nonNegativeInteger are derived from xs:integer. An xs:long is the head of a chain of derivations from xs:int to xs:short to xs:byte. Finally, a positiveInteger and the chain of derivations from xs:unsignedLong to xs:unsignedInt to xs:unsighedShort to xs:unsignedByte are derived from xs:nonNegativeInteger.

2.8.5 Atomic Values

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 consistent with schema 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 Section 18 Constructor functionsFO40 and the related Section 19 CastingFO40 section of [XQuery and XPath Functions and Operators 4.0].

2.8.6 String Values

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 Section 19 CastingFO40.

2.8.7 Negative Zero

The xs:float and xs:double data types in the data model have the same value space as in XML Schema 1.1 ([Schema 1.1 Part 2]). Specifically they include both negative and positive zero, and in this respect they differ from XML Schema 1.0.

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.

2.9 Other Items

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.

2.9.1 Functions

[Definition: A function is an item that can be called. ] Functions cannot be compared for identity, equality, or otherwise, and have no serialization.

A function has the following properties:

  • name (xs:QName): An expanded QName, possibly absent.

  • parameter names (xs:QName*): A list of distinct names, one for each of the function's parameters.

  • signature (a FunctionTest of the form Annotation* TypedFunctionTest): The TypedFunctionTestXP40 has one SequenceTypeXP40 for each parameter, and one SequenceType for the function's result. [Definition: A function signature represents the type of a function.] The presence of annotations is language dependent; functions defined in languages, such as XPath, that have no mechanism for defining annotations will create functions in the data model with zero annotations.

  • implementation This enables the function, when it's called, to map instances of its parameter types into an instance of its result type. The implementation is either:

    • a host language expression, which is always associated with a static context, or

    • an implementation-dependent function implementation, which is optionally associated with both a static and a dynamic context.

  • nonlocal variable bindings (a mapping from xs:QName to item()*): This provides a value for each of the function's free variables (i.e., variables referenced by the function's implementation, other than locals and parameters).

[Definition: A function's arity is the number of its parameters. ] The number of names in a function's parameter names, and the number of parameter types in its signature, must equal the function's arity.

The space of all possible function signatures forms a hierarchy of function types. All function types are a subtype of function(*), which is itself a subtype of item(). Subtypes of function(*) are partitioned into discrete types, each representing functions that accept a particular number of arguments. Function types which have the same arity can be subtypes of each other based on their argument and return types. This subtype relationship is defined in Section 3.7 Subtype RelationshipsXP40. For example:

  • function(item()) as item() is a subtype of function(*)

  • function(item()) as xs:integer is a subtype of function(item()) as item()

  • function(item()) as item() is a subtype of function(xs:string) as item()

2.9.2 Map Items

[Definition: A map item is a value that represents a map (sometimes called a hash or an associative array).] A map is logically a collection of key/value pairs. Each key in the map is unique (there is no other key to which it is equal) and has associated with it a value that is a single item or sequence of items. There is no uniqueness constraint on values. The semantics of equality are described in Section 17.1.1 op:same-keyFO40.

Note:

This version of the XPath Data Model does not specify whether or not maps have any identity other than their values. No operations currently defined on maps depend on the notion of map identity. Other specifications, for example, the XQuery Update Facility, may make identity of maps explicit.

There is a single accessor associated with maps, it is defined in the following section.

2.9.2.1 map-entries Accessor
dm:map-entries($map as map()) as array(array(item()))

The dm:map-entries accessor returns an array of arrays. For each key/value pair in the $map, an array will be constructed with the key in position 1 and the value in position 2. The array returned by dm:map-entries is the array of the arrays constructed for the key/value pairs. The order of the members in the array returned is implementation-dependent.

2.9.3 Array Items

[Definition: An array item is a value that represents an array.] An array is an ordered list of values; these values are called the members of the array. Unlike sequences, a member of an array can be any value (including a sequence or an array). The number of members in an array is called its size, and they are referenced by their position, in the range 1 to the size of the array.

Note:

This version of the XPath Data Model does not specify whether or not arrays have any identity other than their values. No operations currently defined on arrays depend on the notion of array identity. Other specifications, for example, the XQuery Update Facility, may make identity of arrays explicit.

The accessors associated with arrays are defined in the following sections.

2.9.3.1 array-size Accessor
dm:array-size($array as array()) as xs:nonNegativeInteger

The dm:array-size accessor returns the number of items in the array.

2.9.3.2 array-get Accessor
dm:array-get($array as array(), $position as xs:positiveInteger) as item()*

The dm:array-get accessor returns the value in the array at the position $position. An error is raised if the array does not contain a value at that position. For all positions greater than 0 and less than or equal to the array size, dm:array-get will return a value.