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 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.
[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.
[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.
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.
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 [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.
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.
[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:
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 property of their parent node.
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, 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.
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.
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:
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 item is an instance of one or more item types:
All items are instances of the type item()
.
Every Node is an instance of the type node()
, and more
specifically it is an instance of one of seven node kinds document()
,
element(*)
, attribute(*)
, text()
,
comment()
, processing-instruction()
, or
namespace()
. Nodes may also be instances of more specific
types characterized by the node name and type annotation.
Every atomic value is an instance of a specific atomic type determined by its type annotation; it is also an instance of every type from which that type is derived by restriction (directly or indirectly), and of every union type that includes that type as a member type.
Every function is an instance of the generic type function(*)
,
and also of a specific function type defining the types of the function's parameters and the
type of the result.
A map item, as well as being a function, is also an instance of the generic
map type map(*)
, of more specific map types map(K, V)
defining the
types of the keys and values, and perhaps of one or more record types that associate a type with
specific key values.
An array item, as well as being a function, is also an instance of the generic
array type array(*)
, and also of more specific array types array(M)
defining the type of the array's members.
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.
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.
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.
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.]
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.
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
.
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].
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
.
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].
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.
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.
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.
[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()
[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.
map-entries
Accessordm: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.
[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.
array-size
Accessordm:array-size
($array
as
array()
) as
xs:nonNegativeInteger
The dm:array-size accessor returns the number of items in the array.
array-get
Accessordm: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.