CARVIEW |
This document is governed by the
This is a
This Recommendation specifies the XQuery and XPath Data Model (XDM)
version 3.1, a fully compatible extension of
This specification is designed to be referenced normatively from
other specifications defining a host language for it; it is not
intended to be implemented outside a host language. The
implementability of this specification has been tested in the context
of its normative inclusion in host languages defined by the
No substantive changes have been made to this specification since its publication as a Proposed Recommendation.
Please report errors in this document using W3C's
This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.
This document was produced by groups operating under the
This document defines the
See the CVS changelog.
This document defines the
In this document, examples and material
labeled as Note
are provided for explanatory purposes
and are not normative.
The XQuery and XPath Data Model 3.1 (henceforth "data model")
serves two purposes.
First, it defines the information contained in the input to an
XSLT or XQuery processor. Second, it defines all permissible values of
expressions in the XSLT, XQuery, and XPath languages. A
language is
The data model
Support for XML Schema types. The XML Schema recommendations
define features, such as structures (
Representation of collections of documents and of
complex values. (
Support for typed atomic values.
Support for ordered, heterogeneous sequences.
As with the Infoset, the XQuery and XPath Data Model 3.1 specifies what information in the documents is accessible but does not specify the programming-language interfaces or bindings used to represent or access the data.
The data model can represent various values including not only the input and the output of a stylesheet or query, but all values of expressions used during the intermediate calculations. Examples include the input document or document repository (represented as a Document Node or a sequence of Document Nodes), the result of a path expression (represented as a sequence of nodes), the result of an arithmetic or a logical expression (represented as an atomic value), a sequence expression resulting in a sequence of items, etc.
This document provides a precise definition of the properties of nodes in the XQuery and XPath Data Model 3.1, how they are accessed, and how they relate to values in the Infoset and PSVI.
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
Every node is one of the seven kinds of nodes defined in Section
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.
A type is represented in the data model by an
Within this specification, the term URI refers to a
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.
The data model adopts the following types:
The 19 types defined in
Three built-in list types:
xs:NMTOKENS
, xs:IDREFS
, and xs:ENTITIES
.
The following types which were originally defined in
xs:anyAtomicType
, xs:dayTimeDuration
,
xs:yearMonthDuration
.
In the case of a processor that supports
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
xs:numeric
,
a union type whose members are xs:double
, xs:float
and xs:decimal
.
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
https://www.w3.org/2001/XMLSchema
xsi:
bound to
https://www.w3.org/2001/XMLSchema-instance
fn:
bound to
https://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.
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, 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
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
Arrays and maps are derived from functions and therefore can also be contained within 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
), 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.
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.
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; in implementations that support
xs:anyAtomicType
, xs:dayTimeDuration
,
and xs:yearMonthDuration
supersede the definitions in this
specification.
The datatype 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
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.
No type may be derived from xs:anyAtomicType
by restriction, union, or list.
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 xs:dayTimeDuration
and
xs:yearMonthDuration
is provided in
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
This means, for example, that the xs:string data type
In practice interoperability problems can arise both because
specifications are not always in synchronization with each other (for
example, XSD 1.0 contains referenced to dated versions of XML 1.0
other than the latest version), and also because implementations
xs:string
data
type.
Char
production in
The diagrams below show how nodes, functions,
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.
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 | |||
namespace | |||
processing-instruction | |||
text | |||
function(*) | |||
array(*) | |||
map(*) |
The next diagram and table illustrate the any type
type subsystem, 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 | |||
xs:anySimpleType | |||
xs:anyAtomicType | |||
list types | |||
xs:IDREFS | |||
xs:NMTOKENS | |||
xs:ENTITIES | |||
user-defined list types | |||
union types | |||
xs:numeric | |||
user-defined union types | |||
complex types | |||
xs:untyped | |||
user-defined 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
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: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 has the following properties:
xs:QName
)
xs:QName*
)
FunctionTest
of the form
Annotation* TypedFunctionTest
)
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.
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).
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(item()) as item()
is a subtype of function(xs:string) as item()
If any date/time values (xs:date, xs:dateTime, xs:time, xs:gYear, etc.) are used as keys, all such values must either have a timezone or must not have a timezone. An error is raised if an attempt is made to mix date/time key values that have a timezone with values that do not. This constraint applies only to map keys and applies independently to each map (it is not an error to have one map that uses date/time keys with timezones and another which uses values without timezones).
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
There is a single accessor associated with maps, it is defined in the following section.
map-entries
AccessorThe $map
, an
array will be constructed with the key in position 1 and the value
in position 2. The array returned by
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
AccessorThe
array-get
AccessorThe $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,
This section describes the constraints on instances of the data model.
The data model supports well-formed XML documents conforming to
In other words, the data model supports the following classes of XML documents:
Well-formed documents conforming to
DTD-valid documents conforming to
W3C XML Schema-validated documents.
This document describes how to construct an instance of the data
model from an infoset (
An instance of the data model can also be constructed directly through application APIs, or from non-XML sources such as relational tables in a database. Data model construction from sources other than an Infoset or PSVI is implementation-defined. Regardless of how an instance of the data model is constructed, every node and atomic value in the data model must have a typed-value that is consistent with its type.
The data model supports some kinds of values that are not supported
by
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
An instance of the data model can be constructed from an infoset that satisfies the following general constraints:
All general and external parsed entities must be fully expanded. The
Infoset must not contain any
The infoset required
in this document.
The properties identified as optional
may be used, if they are present. All other properties are ignored.
An instance of the data model constructed from an information set
Furthermore, construction of an instance of the data model from an Infoset is only guaranteed to be well-defined for Infosets that could have been derived from a conforming XML document.
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
Data model construction requires that the PSVI provide unique names for all anonymous schema types.
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.
A PSVI element or attribute information item may have a
,
,
or
and reflects the outcome of schema-validity assessment. In the data
model, precise schema type information is exposed for Element and
Attribute Nodes that are
. Nodes
that are not
are treated as if they
were simply well-formed XML and only very general schema type
information is associated with them.
The precise definition of the schema type of an element or attribute
information item depends on the properties of the PSVI.
In the PSVI,
The type depends on the declared type, the actual type, and the
The
and
, respectively, the
schema type of an element or attribute information item is
represented by an
If the declared type exists and is a union and the actual type is (not the same as the declared type, and not a type derived from the declared type, but) one of the member types of the union, or derived from one of its member types:
If the {name} property of the declared type is present: the {target namespace} and {name} properties of the declared type.
If the {name} property of the declared type is absent: the namespace and local name of the anonymous type name supplied for the declared type.
If there is no declared type, and the actual type is a union, then:
If the {name} property of the actual type is present: the {target namespace} and {name} properties of the actual type.
If the {name} property of the actual type is absent: the namespace and local name of the anonymous type name supplied for the actual type.
Otherwise:
If
If
The
, or the
, the schema type of an element
is xs:anyType
and the type of an attribute is
xs:anySimpleType
.
The
, the schema type of an element is
xs:anyType
and the type of an attribute is
xs:anySimpleType
.
The xs:untyped
and the type of an attribute is
xs:untypedAtomic
.
The prefix associated with the type names is implementation-dependent.
This section describes how the typed value of an Element or
Attribute Node is computed from an element or attribute PSVI
information item, where the information item has either a simple type
or a complex type with simple content. For other kinds of
Element Nodes, see
The typed value of Attribute Nodes and some Element Nodes is a sequence of atomic values. The types of the items in the typed value of a node may differ from the type of the node itself. This section describes how the typed value of a node is derived from the properties of an information item in a PSVI.
The types of the items in the typed value of a node are determined as follows.
The process begins with a type, T
. If the schema type of the node itself, as
represented in the PSVI, is a complex type with simple content, then T
is the
{content type} of the schema type of the node; otherwise, T
is the schema type
of the node itself. For each primitive or ordinary simple type T
, the W3C XML
Schema specification defines a function M
mapping the lexical representation of
a value onto the value itself.
For atomic and list types, the mapping is the “lexical mapping”
defined for T
in
The typed value is determined as follows:
If the true
, then the typed value is the empty sequence.
If T
is xs:anySimpleType
or
xs:anyAtomicType
, the typed value
is the xs:untypedAtomic
.
Otherwise, the typed value is the result of applying M
to the string value as an instance of the appropriate value type,
where the appropriate value type is the T
is a union type, otherwise it
is simply T
.
The typed value determination process is guaranteed to result in a sequence of atomic values, each having a well-defined atomic type. This sequence of atomic values, in turn, determines the typed-value property of the node in the data model.
Element and attribute nodes have both typed-value and string-value properties. However, implementations are allowed some flexibility in how these properties are stored. An implementation may choose to store the string-value only and derive the typed-value from it, or to store the typed-value only and derive the string-value from it, or to store both the string-value and the typed-value.
In order to permit these various implementation strategies, some variations in the string value of a node are defined as insignificant. Implementations that store only the typed value of a node are permitted to return a string value that is different from the original lexical form of the node content. For example, consider the following element:
Assuming that the node is valid, it has a typed value of 30 as an
xs:integer
. An implementation may return either "30" or
"0030" as the string value of the node. Any string that is a valid
lexical representation of the typed value is acceptable. In this
specification, we express this rule by saying that the relationship
between the string value of a node and its typed value must be
"consistent with schema validation."
If an implementation stores only the string-value of a node, the following considerations apply:
Where union types occur, the implementation must be able to deliver
the typed-value as an instance of the appropriate member type. For
example, if the type
Where types of xs:QName
, xs:NOTATION
, or
types derived from one of these types occur, the implementation must
be able to deliver the typed-value as a triple including a local name,
a namespace prefix, and a namespace URI, even though the namespace URI
is not part of the string-value (see
Where an element with a complex type and element-only content occurs, it is an error to attempt to access the typed-value of the Element Node.
If an implementation stores only the typed-value of a node, it must be prepared to construct string values from not only the node, but in some cases also the descendants of that node. For example, an element with a complex type and element-only content has no typed-value but does have a string-value that is the concatenation of the string-values of all its Text Node descendants in document order.
A further caveat applies if an implementation stores the typed value of a node. If a new data model is constructed by copying portions of another data model, and the copy operation does not preserve inherited namespaces, and the type is a union type that is sensitive to the namespace context, then the typed value may be different than what would be obtained by revalidating the node within its new namespace context. Although this may stretch the semantics of “consistent with schema validation”, we accept this possibility; it is not an error.
Creating a subtype by restriction generally reduces the
The pattern facet is different because it restricts the
The pattern facet is not reversible in practice. A given point in the value space might have several lexical representations. In general, there's no practical way to determine which, if any, of these representations satisfies the pattern facet of the type.
As a consequence, pattern facets are not respected when mapping to an Infoset or during serialization and values in the data model that were originally valid with respect to a schema that contains pattern-based restrictions may be invalid after serialization.
The date and time types require special attention. This section
applies to implementations that store the typed value of
xs:dateTime
, xs:date
, xs:time
,
xs:gYearMonth
, xs:gYear
,
xs:gMonthDay
, xs:gMonth
,
xs:gDay
, and types that are derived from them. These are
known collectively as the date/time types in this specification.
The values of the date/time types are represented in the data model using seven components:
An xs:integer
.
An xs:integer
between 1 and 12, inclusive.
An xs:integer
between 1 and 31, inclusive, possibly
restricted further depending on the values of month and year.
An xs:integer
between 0 and 23, inclusive.
An xs:integer
between 0 and 59, inclusive.
An xs:decimal
greater than or equal to zero and less
than 60. Leap seconds are not supported.
An xs:dayTimeDuration
between -PT14H00M and PT14H00M,
inclusive. All timezone values must be an integral number of minutes.
Components that are intrinsic to the datatype (for example, day,
month, and year in a xs:date
) are required; components
that can never be part of a datatype (for example, years in a
xs:time
) must be missing. Missing components are
represented by the empty sequence. When a component is present, it
contains the “local value” that has not been normalized in any way.
The timezone component is optional for all the date/time datatypes.
Thus, the lexical xs:dateTime
representation
“2003-01-02T11:30:00-05:00
” is stored as
“{2003, 1, 2, 11, 30, 0.0, -PT05H00M}
”.
The value of the lexical representation “2003-01-16T16:30:00
”
is stored as
“{2003, 1, 16, 16, 30, 0, ()}
”
because it has no timezone.
The value of the lexical xs:gDay
representation
“---30+10:30
” is
stored as
“{(), (), 30, (), (), (), PT10H30M}
”.
The lexical form “24:00:00
” is normalized in the component
model. As a xs:time
, it is stored as
“{(), (), (), 0, 0, 0.0, ()}
”
and the xs:dateTime
representation
“1999-12-31T24:00:00
” is stored as
“{2000, 1, 1, 0, 0, 0.0, ()}
”.
Implementations are permitted to store date/time values in any representation that's convenient for them, provided that the individual properties can be accessed and modified.
The QName
and NOTATION
data types require
special attention. The following sections apply to
xs:QName
, xs:NOTATION
, and types derived
from them. These types are referred to collectively as “qualified
names”.
As defined in XML Schema, the lexical space for qualified names includes a local name and an optional namespace prefix. The value space for qualified names contains a local name and an optional namespace URI. Therefore, it is not possible to derive a lexical value from the typed value, or vice versa, without access to some context that defines the namespace bindings.
When qualified names exist as values of nodes in a well-formed document, it is always possible to determine such a namespace context. However, the data model also allows qualified names to exist as freestanding atomic values, or as the name or value of a parentless attribute node, and in these cases no namespace context is available.
In this Data Model, therefore, the value space for qualified names contains a local-name, an optional namespace URI, and an optional prefix. The prefix is used only when producing a lexical representation of the value, that is, when casting the value to a string. The prefix plays no part in other operations involving qualified names: in particular, two qualified names are equal if their local names and namespace URIs match, regardless whether they have the same prefix.
The following consistency constraints apply:
If the namespace URI of a qualified name is
For every element node whose name has a prefix, the prefix must be one that has a binding to the namespace URI of the element name in the namespaces property of the element.
For every element node whose name has no prefix, the element must have a a binding for the empty prefix to the namespace URI of the element name, or must have no binding for the empty prefix in the case where the name of the element has no namespace URI.
For every attribute node whose name has a prefix, the attribute node must either be parentless, or the prefix must be one that has a binding to the namespace URI of the attribute name in the namespaces property of the parent element.
For every qualified name that contains a prefix and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, the prefix must be one that is bound to the namespace URI of the qualified name in the namespaces property of that element.
For every qualified name that contains a namespace URI and no prefix, and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, that element node must have a binding for the empty prefix to that namespace URI in its namespace property.
For every qualified name that contains neither a namespace URI nor a prefix, and that is included in the typed value of an element node, or of an attribute node that has an element node as its parent, that node must not have a binding for the empty prefix.
No qualified name that contains a prefix may be included in the typed value of an attribute node that has no parent.
This specification describes how to map each kind of node to the corresponding information item. This mapping produces an Infoset; it does not and cannot produce a PSVI. Validation must be used to obtain a PSVI for a (portion of a) data model instance.
A set of accessors is defined on
In order for processors to be able to operate on instances of the
data model, the model must expose the properties of the items it contains.
The data model does this by defining a family of accessor functions.
These are not functions in the literal sense; they are not available
for users or applications to call directly. Rather they are
descriptions of the information that an implementation of the data model
must expose to applications. Functions and operators available to end-users
are described in
Some typed values in the data model
are
attributes
AccessorThe
It is defined on
base-uri
AccessorThe
It is defined on
children
AccessorThe
It is defined on
document-uri
AccessorThe
It is defined on
is-id
AccessorThe
It is defined on
is-idrefs
AccessorThe
It is defined on
namespace-nodes
AccessorThe
It is defined on
nilled
AccessorThe nilled
.
It is defined on
node-kind
AccessorThe
It is defined on
node-name
AccessorThe xs:QName
s. Note that the
QName value includes an optional prefix as described in
It is defined on
parent
AccessorThe
It is defined on
string-value
AccessorThe
It is defined on
type-name
AccessorThe xs:QName
s.
It is defined on
typed-value
AccessorThe
It is defined on
unparsed-entity-public-id
AccessorThe $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
unparsed-entity-system-id
AccessorThe $entityname
exists, or if the entity is not an external unparsed entity, the empty sequence
is returned.
It is defined on
All nodes
Every node
The
The
The
No node may appear more than once in the
Document Nodes encapsulate XML documents. Documents have the following properties:
Document Nodes
The
If a node
If a node
The
In the
Implementations that support DTD processing and access to the
unparsed entity accessors use the
Returns the empty sequence
Returns the value of the
Returns the value of the
Returns the absolute URI of the resource from which the Document Node was constructed, or the empty sequence if no such absolute URI is available.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence
Returns the empty sequence
Returns “document
”.
Returns the empty sequence.
Returns the empty sequence
Returns the value of the
Returns the empty sequence.
Returns the value of the
Returns the public identifier of the specified unparsed entity or the empty sequence if no such entity exists.
Returns the system identifier of the specified unparsed entity or the empty sequence if no such entity exists.
The
The following infoset properties are required:
The following infoset properties are optional:
Document Node properties are derived from the infoset as follows:
The value of the
In practice a
The sequence of nodes constructed from the information
items found in the
For each element, processing instruction, and comment found in the
If present among the
If the
The internal structure of the values of the
The concatenation of the string-values of all its Text Node descendants in document order. If the document has no such descendants, the zero-length string.
The xs:untypedAtomic
value.
The
If the fn:doc()
with the
In other words, for any Document Node $arg
, either
fn:document-uri($arg)
must return the empty sequence or
fn:doc(fn:document-uri($arg))
must return $arg
.
Construction from a PSVI is identical to construction from the Infoset.
A Document Node maps to a
The following properties are specified by this mapping:
A list of information items obtained by processing each of the
The
An unordered set of
Each unparsed entity maps to an
The name of the entity.
The system identifier of the entity.
The public identifier of the entity.
Implementation defined. In many cases, the
The following properties of the
The following properties of the
Element Nodes encapsulate XML elements. Elements have the following properties:
Element Nodes
The
The Attribute Nodes of an element xs:QName
s.
If a node
Exclusive of Attribute and Namespace Nodes, if a node
The data model permits Element Nodes without parents
(to represent partial results during expression processing, for example).
Such Element Nodes
An element may not be its own child or its own parent.
If an Attribute Node
If an Attribute Node
The data model permits Attribute Nodes without parents.
Such Attribute Nodes
If a Namespace Node
If a Namespace Node
The data model permits Namespace Nodes without parents. Such
Namespace Nodes
If the xs:untyped
, then the xs:untyped
and the
xs:untypedAtomic
.
If the xs:untyped
, then the
false
.
If the true
, then the
For every xs:QName
or xs:NOTATION
(or any type derived
from those types) that appears in the typed-value of the element or
the typed-value of any of its attributes, if the expanded QName has a non-empty URI, then
there
If any of the expanded QNames has an empty URI, then there
Every element must include a Namespace Node and/or namespace binding
for the prefix xml
bound to the URI
https://www.w3.org/XML/1998/namespace
and there must be no other
prefix bound to that URI.
The
Returns the value of the
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the value of the
Returns the value of the
Returns the value of the
Returns the value of the
Returns “element
”.
Returns the value of the
Returns the value of the
Returns the value of the
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the empty sequence.
The
The following infoset properties are required:
Element Node properties are derived from the infoset as follows:
The value of the
In practice a
An xs:QName
constructed from the
The node that corresponds to the
value of the
All Element Nodes constructed from an infoset have the type
xs:untyped
.
The sequence of nodes constructed from the information
items found in the
For
each element, processing instruction, comment, and maximal sequence of
adjacent
Because the data model requires
that all general entities be expanded, there will never be
A set of Attribute Nodes constructed from the
special
attributes
(
Default and fixed attributes provided by the DTD
are added to the
A set of Namespace Nodes constructed from the
Implementations
It appears in the
It appears in the
Note: applications may rely on namespaces that are not known to be used,
for example when QNames are used in content and that content does not
have a type of xs:QName
Such applications may have difficulty
processing data models where some namespaces have been ignored.
All Element Nodes constructed from an infoset have a
.
The
This process is equivalent to concatenating the
If the element has no such descendants, the
The xs:untypedAtomic
.
All Element Nodes constructed from an infoset have a
.
All Element Nodes constructed from an infoset have a
.
The following Element Node properties are affected by PSVI properties.
The
The sequence of nodes constructed from the information
items found in the
For each element, processing instruction, comment, and maximal
sequence of adjacent
For elements with schema simple types, or complex types with simple content,
if the
The relative order of Processing Instruction and Comment Nodes must be preserved, but the position of the Text Node, if it is present, among them is implementation defined.
The effect of the above rules is that where a fixed or default value for an element is defined in the schema, and the element takes this default value, a text node will be created to contain the value, even though there are no character information items representing the value in the PSVI. The position of this text node relative to any comment or processing instruction children is implementation-dependent.
Section 3.3.1 in
Because the data model requires
that all general entities be expanded, there will never be
A set of Attribute Nodes constructed from the
special
attributes
(
Default and fixed attributes provided by XML Schema processing
are added to the
A set of Namespace Nodes constructed from the
Implementations
It appears in the
It appears in the
It appears in the xs:QName
that appear among the
element's children or the typed values of its attributes.
Note: applications may rely on namespaces that are not known to be used,
for example when QNames are used in content and that content does not
have a type of xs:QName
Such applications may have difficulty
processing data models where some namespaces have been ignored.
If the
then if
the
.
In all other cases, including all cases where schema validity assessment was
not attempted or did not succeed, the
.
The string-value is calculated as follows:
If the element is empty: its string value is the zero length string.
If the element has a type of xs:untyped
, a complex
type with element-only content, or a complex type with mixed content: its
string-value is the concatenation of the
If the element has a simple type or a complex type with simple content:
its string-value is the
If an implementation stores only the typed value of an element, it
may use any valid lexical representation of the typed value for the
The typed-value is calculated as follows:
If the element is of type xs:untyped
, its typed-value
is its xs:untypedAtomic
.
If the element has a complex type with empty content, its typed-value is the empty sequence.
If the element has a simple type or a complex type with simple content:
its typed value is computed as described in
Note that in the case of dates and times, the timezone is preserved
as described in xs:QName
s and xs:NOTATION
s,
the prefix is preserved as described in
If the element has a complex type with mixed content
(including xs:anyType
), its typed-value
is its xs:untypedAtomic
.
Otherwise, the element must be a complex type with element-only content.
The typed-value of such an element is
If the element has a complex type with element-only content,
the false
.
Otherwise, if the typed-value of the element consists of exactly
one atomic value and that value is of type xs:ID
,
or a type derived from xs:ID
,
the true
, otherwise it is false
.
This means that in the case of a type constructed by list
from xs:ID
, the ID is recognized provided that the list
is of length one. A type constructed as a union
involving xs:ID
is recognized provided the actual value
is of type xs:ID
.
The element that is marked with the
xs:ID
value.
This node is a child of the element node that, according to XML Schema,
is uniquely identified by this ID.
If the element has a complex type with element-only content, the
false
.
Otherwise, if any of the atomic values in the typed-value of the
element is of type xs:IDREF
or xs:IDREFS
, or
a type derived from one of those types, the
true
, otherwise it is false
.
All other properties have values that are consistent with construction from an infoset.
An Element Node maps to an
The following properties are specified by this mapping:
The namespace name of the value of
The local part of the value of
The prefix associated with the value of
A list of information items obtained by processing each of the
An unordered set of information items obtained by processing each of the
An unordered set of
Each in-scope namespace maps to a
The prefix associated with the namespace.
The URI associated with the namespace.
The value of
If this node is the root of the infoset mapping operation,
If this node has a parent, the information item that corresponds
to the node returned by
Otherwise
The following property has no value:
Attribute Nodes represent XML attributes. Attributes have the following properties:
Attribute Nodes
If an Attribute Node
If a Attribute Node
The data model permits Attribute Nodes without parents
(to represent partial results during expression processing, for example).
Such attributes
In the node-name of an attribute node, if a namespace URI is
present then a prefix
For convenience, the Element Node that owns this attribute is called its "parent" even though an Attribute Node is not a "child" of its parent element.
Returns the empty sequence.
If the attribute has a parent, returns the value of the
Returns the empty sequence.
Returns the empty sequence.
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the empty sequence.
Returns “attribute
”.
Returns the value of the
Returns the value of the
Returns the value of the
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the empty sequence.
The
The following infoset properties are required:
Attribute Node properties are derived from the infoset as follows:
An xs:QName
constructed from the
The Element Node that corresponds to the value of the
The value xs:untypedAtomic
.
The
The attribute’s typed-value
is its xs:untypedAtomic
.
If the attribute is named ID
, then ID
and that it is properly normalized. If an error is encountered during
xml:id processing, an implementation true
for
attributes named
If the ID
, true
, otherwise false
.
If the IDREF
or IDREFS
,
true
, otherwise false
.
The following Attribute Node properties are affected by PSVI properties.
The
Otherwise, the
If an implementation stores only the typed value of an attribute, it
may use any valid lexical representation of the typed value for the
The
The typed-value is calculated as follows:
If the attribute is of type xs:untypedAtomic
: its typed-value
is its xs:untypedAtomic
.
Otherwise, a sequence of zero or more atomic values as described in
If the attribute is named xs:ID
or a type derived from xs:ID
,
then xs:ID
and that it is properly normalized.
If an error is encountered during xml:id processing,
an implementation xml:id
.
Otherwise, if the typed-value of the attribute consists of
exactly one atomic value and that value is of type xs:ID
,
or a type derived from xs:ID
,
the true
, otherwise it is false
.
This means that in the case of a type constructed by list
from xs:ID
, the ID is recognized provided that the list
is of length one. A type constructed as a union
involving xs:ID
is recognized provided the actual value
is of type xs:ID
.
If any of the atomic values in the typed-value of the
attribute is of type xs:IDREF
or xs:IDREFS
, or
a type derived from one of those types, the
true
, otherwise it is false
.
This rule means that a
xs:IDREF
(or a type derived from xs:IDREF
)
xs:IDREFS
or is derived from
xs:IDREFS
. Because union types are allowed, it also means that an
element or attribute with the
xs:IDREF
alongside values of other types.
xs:IDREF
;
it is not sufficient that the type annotation permits such values.
All other properties have values that are consistent with construction from an infoset.
Note: attributes from the XML Schema instance namespace,
,
(https://www.w3.org/2001/XMLSchema-instance
An Attribute Node maps to an
The following properties are specified by this mapping:
The namespace name of the value of
The local part of the value of
The prefix associated with the value of
The value of
If this node has a parent, the information item that corresponds
to the node returned by
Otherwise
The following properties have no value:
Each Namespace Node represents the binding of a namespace URI to a
namespace prefix or to the default namespace. Implementations that do not
use Namespace Nodes may represent the same information using the
Namespace Nodes
If a Namespace Node
If a Namespace Node
A Namespace Node xmlns
nor the string-value
https://www.w3.org/2000/xmlns/
.
The data model permits Namespace Nodes without parents, see below.
In XPath 1.0, Namespace Nodes were directly accessible by applications, by
means of the namespace axis. In XPath
The information held in namespace
nodes is instead made available to applications using functions defined
in
Implementations that expose the namespace axis xml
prefix, which is implicitly declared by
In implementations that do not expose the namespace axis, there is no means by which the host language can tell if namespace nodes are shared or not and, in such circumstances, sharing namespace nodes may be a very reasonable implementation strategy.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns “namespace
”.
If the xs:QName
with the value of the
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the value of the xs:string
.
Returns the empty sequence.
Returns the empty sequence.
The
The following infoset properties are required:
Namespace Node properties are derived from the infoset as follows:
The
The
The element in whose
Construction from a PSVI is identical to construction from the Infoset.
A Namespace Node maps to a
The following properties are specified by this mapping:
The prefix associated with the namespace.
The value of
Processing Instruction Nodes encapsulate XML processing instructions. Processing instructions have the following properties:
Processing Instruction Nodes
The string ?>
The NCName
.
Returns the empty sequence.
Returns the value of the
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns “processing-instruction
”.
Returns an xs:QName
with the value of the
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the value of the xs:string
.
Returns the empty sequence.
Returns the empty sequence.
A Processing Instruction Node is constructed for each
The following infoset properties are required:
Processing Instruction Node properties are derived from the infoset as follows:
The value of the
The value of the
The value of the
In practice a
The node corresponding to the value of the
There are no Processing Instruction Nodes for processing instructions
that are children of a
Construction from a PSVI is identical to construction from the Infoset.
An Processing Instruction Node maps to a
The following properties are specified by this mapping:
The local part of the value of
The value of
The value of
If this node is the root of the infoset mapping operation,
If this node has a parent, the information item that corresponds
to the node returned by
Otherwise
Comment Nodes encapsulate XML comments. Comments have the following properties:
Comment Nodes
The string --
The character -
Returns the empty sequence.
If the comment has a parent, returns the value of the
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns “comment
”.
Returns the empty sequence.
Returns the value of the
Returns the value of the
Returns the empty sequence.
Returns the value of the xs:string
.
Returns the empty sequence.
Returns the empty sequence.
The
A Comment Node is constructed for each
The following infoset properties are required:
Comment Node properties are derived from the infoset as follows:
The value of the
The node corresponding to the value of the
There are no Comment Nodes for comments that are children of a
Construction from a PSVI is identical to construction from the Infoset.
A Comment Node maps to a
The following properties are specified by this mapping:
The value of the
If this node is the root of the infoset mapping operation,
If this node has a parent, the information item that corresponds
to the node returned by
Otherwise
Text Nodes encapsulate XML character content. Text has the following properties:
Text Nodes
If the
In addition, Document and Element Nodes impose the constraint that
two consecutive Text Nodes can never occur as adjacent siblings.
When a Document or Element Node is constructed, Text Nodes that would
be adjacent
Returns the empty sequence.
If the Text Node has a parent, returns the value of the
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns “text
”.
Returns the empty sequence.
Returns the value of the
Returns the value of the
Returns xs:untypedAtomic
.
Returns the value of the xs:untypedAtomic
.
Returns the empty sequence.
Returns the empty sequence.
The
The following infoset properties are required:
The following infoset properties are optional:
A sequence of
All of the information items in the sequence have the same parent.
The sequence consists of adjacent
No other such sequence exists that contains any of the same
Text Node properties are derived from the infoset as follows:
A string comprised of characters that correspond to the
If the resulting Text Node consists entirely of whitespace and
the true
,
the
The content of the Text Node is not necessarily normalized as
described in the
The node corresponding to the value of the
For Text Nodes constructed from the
Otherwise, construction from a PSVI is the same as construction
from the Infoset except for the mixed
”, then
the
Text Nodes are only allowed to be empty if they have no parents; an empty Text Node will be discarded when its parent is constructed, if it has a parent.
A Text Node maps to a sequence of
Each
character of the
The Unicode code point value of the character.
If this node is the root of the infoset mapping operation,
If this node has a parent, the information item that corresponds
to the node returned by
Otherwise
This sequence of characters constitutes the infoset mapping.
The data model is intended primarily as a component that can be
used by other specifications. Therefore, the data model relies on
specifications that use it (such as
Authors of conformance criteria for the use of the data model should pay particular attention to the following features of the data model:
Support for the normative construction from an infoset described in
Support for the normative construction from a PSVI described in
Support for XML 1.0 and XML 1.1.
Support for data types in XML Schema 1.0 and XML Schema 1.1.
How namespaces are supported, through nodes or through the alternative, implementation-dependent representation.
In addition, the
This specification conforms to the XML Information Set
The
Other information items and properties made available by the
Infoset processor are ignored. In addition to the properties above,
the following PSVI properties are required
on
The following schema defines the additional types in the
xs:
namespace identified by this document.
You can retrieve the normative schema document for this namespace from
The following XML document is used to illustrate the information contained in a data model:
The document is associated with the URI
https://www.example.com/catalog.xml
,
and is valid with respect to the following XML schema:
The schema is associated with the URI
https://www.example.com/dm-example.xsd
.
This example exposes the data model for a document that has an associated
schema and has been validated successfully against it.
In general, an XML Schema is not required,
that is, the data model can represent a schemaless, well-formed XML
document with the rules described in
The XML document is represented by the nodes described below.
The value
For brevity:
Text Nodes in the data model that contain only white space are not shown.
Literal strings are shown in quotes without the xs:string()
constructor
Literal decimals are shown without the xs:decimal()
constructor
Nodes are referred to using the syntax [nodeID]
xs:QNames are used with the following prefixes bindings:
xs | https://www.w3.org/2001/XMLSchema |
xsi | https://www.w3.org/2001/XMLSchema-instance |
cat | https://www.example.com/catalog |
xlink | https://www.w3.org/1999/xlink |
html | https://www.w3.org/1999/xhtml |
anon | An implementation-dependent prefix associated with anonymous type names |
The abbreviation
is used in string literals
to represent a newline character; this isn't supported in XPath, but it makes
this presentation clearer.\n
Accessors that return the empty sequence have been omitted.
To simplify the presentation, we’re assuming an implementation
that does not expose the namespace axis. Therefore,
Namespace Nodes are shared across multiple elements.
See
// Document node D1 | ||
dm:base-uri(D1) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(D1) | = | "document" |
dm:string-value(D1) | = | " Staind: Been Awhile Tee Black (1-sided) \n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n 25.00 It's Been A While 10.99 Staind " |
dm:typed-value(D1) | = | xs:untypedAtomic(" Staind: Been Awhile Tee Black (1-sided) \n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n 25.00 It's Been A While 10.99 Staind ") |
dm:children(D1) | = | ([ |
// Namespace node N1 | ||
dm:node-kind(N1) | = | "namespace" |
dm:node-name(N1) | = | xs:QName("", "xml") |
dm:string-value(N1) | = | "https://www.w3.org/XML/1998/namespace" |
dm:typed-value(N1) | = | "https://www.w3.org/XML/1998/namespace" |
// Namespace node N2 | ||
dm:node-kind(N2) | = | "namespace" |
dm:node-name(N2) | = | () |
dm:string-value(N2) | = | "https://www.example.com/catalog" |
dm:typed-value(N2) | = | "https://www.example.com/catalog" |
// Namespace node N3 | ||
dm:node-kind(N3) | = | "namespace" |
dm:node-name(N3) | = | xs:QName("", "html") |
dm:string-value(N3) | = | "https://www.w3.org/1999/xhtml" |
dm:typed-value(N3) | = | "https://www.w3.org/1999/xhtml" |
// Namespace node N4 | ||
dm:node-kind(N4) | = | "namespace" |
dm:node-name(N4) | = | xs:QName("", "xlink") |
dm:string-value(N4) | = | "https://www.w3.org/1999/xlink" |
dm:typed-value(N4) | = | "https://www.w3.org/1999/xlink" |
// Namespace node N5 | ||
dm:node-kind(N5) | = | "namespace" |
dm:node-name(N5) | = | xs:QName("", "xsi") |
dm:string-value(N5) | = | "https://www.w3.org/2001/XMLSchema-instance" |
dm:typed-value(N5) | = | "https://www.w3.org/2001/XMLSchema-instance" |
// Processing Instruction node P1 | ||
dm:base-uri(P1) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(P1) | = | "processing-instruction" |
dm:node-name(P1) | = | xs:QName("", "xml-stylesheet") |
dm:string-value(P1) | = | "type="text/xsl" href="dm-example.xsl"" |
dm:typed-value(P1) | = | "type="text/xsl" href="dm-example.xsl"" |
dm:parent(P1) | = | ([ |
// Element node E1 | ||
dm:base-uri(E1) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E1) | = | "element" |
dm:node-name(E1) | = | xs:QName("https://www.example.com/catalog", "catalog") |
dm:string-value(E1) | = | " Staind: Been Awhile Tee Black (1-sided) \n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n 25.00 It's Been A While 10.99 Staind " |
dm:typed-value(E1) | = | fn:error() |
dm:type-name(E1) | = | anon:TYP000001 |
dm:is-id(E1) | = | false |
dm:is-idrefs(E1) | = | false |
dm:parent(E1) | = | ([ |
dm:children(E1) | = | ([ |
dm:attributes(E1) | = | ([ |
dm:namespace-nodes(E1) | = | ([ |
dm:namespace-bindings(E1) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Attribute node A1 | ||
dm:node-kind(A1) | = | "attribute" |
dm:node-name(A1) | = | xs:QName("https://www.w3.org/2001/XMLSchema-instance", "xsi:schemaLocation") |
dm:string-value(A1) | = | "https://www.example.com/catalog dm-example.xsd" |
dm:typed-value(A1) | = | (xs:anyURI("https://www.example.com/catalog"), xs:anyURI("catalog.xsd")) |
dm:type-name(A1) | = | anon:TYP000002 |
dm:is-id(A1) | = | false |
dm:is-idrefs(A1) | = | false |
dm:parent(A1) | = | ([ |
// Attribute node A2 | ||
dm:node-kind(A2) | = | "attribute" |
dm:node-name(A2) | = | xs:QName("https://www.w3.org/XML/1998/namespace", "xml:lang") |
dm:string-value(A2) | = | "en" |
dm:typed-value(A2) | = | "en" |
dm:type-name(A2) | = | xs:NMTOKEN |
dm:is-id(A2) | = | false |
dm:is-idrefs(A2) | = | false |
dm:parent(A2) | = | ([ |
// Attribute node A3 | ||
dm:node-kind(A3) | = | "attribute" |
dm:node-name(A3) | = | xs:QName("", "version") |
dm:string-value(A3) | = | "0.1" |
dm:typed-value(A3) | = | "0.1" |
dm:type-name(A3) | = | xs:string |
dm:is-id(A3) | = | false |
dm:is-idrefs(A3) | = | false |
dm:parent(A3) | = | ([ |
// Comment node C1 | ||
dm:base-uri(C1) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(C1) | = | "comment" |
dm:string-value(C1) | = | " This example is for data model illustration only.\n It does not demonstrate good schema design. " |
dm:typed-value(C1) | = | " This example is for data model illustration only.\n It does not demonstrate good schema design. " |
dm:parent(C1) | = | ([ |
// Element node E2 | ||
dm:base-uri(E2) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E2) | = | "element" |
dm:node-name(E2) | = | xs:QName("https://www.example.com/catalog", "tshirt") |
dm:string-value(E2) | = | " Staind: Been Awhile Tee Black (1-sided) \n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n 25.00 " |
dm:typed-value(E2) | = | fn:error() |
dm:type-name(E2) | = | cat:tshirtType |
dm:is-id(E2) | = | false |
dm:is-idrefs(E2) | = | false |
dm:parent(E2) | = | ([ |
dm:children(E2) | = | ([ |
dm:attributes(E2) | = | ([ |
dm:namespace-nodes(E2) | = | ([ |
dm:namespace-bindings(E2) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Attribute node A4 | ||
dm:node-kind(A4) | = | "attribute" |
dm:node-name(A4) | = | xs:QName("", "code") |
dm:string-value(A4) | = | "T1534017" |
dm:typed-value(A4) | = | xs:ID("T1534017") |
dm:type-name(A4) | = | xs:ID |
dm:is-id(A4) | = | true |
dm:is-idrefs(A4) | = | false |
dm:parent(A4) | = | ([ |
// Attribute node A5 | ||
dm:node-kind(A5) | = | "attribute" |
dm:node-name(A5) | = | xs:QName("", "label") |
dm:string-value(A5) | = | "Staind : Been Awhile" |
dm:typed-value(A5) | = | xs:token("Staind : Been Awhile") |
dm:type-name(A5) | = | xs:token |
dm:is-id(A5) | = | false |
dm:is-idrefs(A5) | = | false |
dm:parent(A5) | = | ([ |
// Attribute node A6 | ||
dm:node-kind(A6) | = | "attribute" |
dm:node-name(A6) | = | xs:QName("https://www.w3.org/1999/xlink", "xlink:href") |
dm:string-value(A6) | = | "https://example.com/0,,1655091,00.html" |
dm:typed-value(A6) | = | xs:anyURI("https://example.com/0,,1655091,00.html") |
dm:type-name(A6) | = | xs:anyURI |
dm:is-id(A6) | = | false |
dm:is-idrefs(A6) | = | false |
dm:parent(A6) | = | ([ |
// Attribute node A7 | ||
dm:node-kind(A7) | = | "attribute" |
dm:node-name(A7) | = | xs:QName("", "sizes") |
dm:string-value(A7) | = | "M L XL" |
dm:typed-value(A7) | = | (xs:token("M"), xs:token("L"), xs:token("XL")) |
dm:type-name(A7) | = | cat:sizeList |
dm:is-id(A7) | = | false |
dm:is-idrefs(A7) | = | false |
dm:parent(A7) | = | ([ |
// Element node E3 | ||
dm:base-uri(E3) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E3) | = | "element" |
dm:node-name(E3) | = | xs:QName("https://www.example.com/catalog", "title") |
dm:string-value(E3) | = | "Staind: Been Awhile Tee Black (1-sided)" |
dm:typed-value(E3) | = | xs:token("Staind: Been Awhile Tee Black (1-sided)") |
dm:type-name(E3) | = | xs:token |
dm:is-id(E3) | = | false |
dm:is-idrefs(E3) | = | false |
dm:parent(E3) | = | ([ |
dm:children(E3) | = | ([ |
dm:attributes(E3) | = | () |
dm:namespace-nodes(E3) | = | ([ |
dm:namespace-bindings(E3) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Text node T1 | ||
dm:base-uri(T1) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T1) | = | "text" |
dm:string-value(T1) | = | "Staind: Been Awhile Tee Black (1-sided)" |
dm:typed-value(T1) | = | xs:untypedAtomic("Staind: Been Awhile Tee Black (1-sided)") |
dm:type-name(T1) | = | xs:untypedAtomic |
dm:parent(T1) | = | ([ |
// Element node E4 | ||
dm:base-uri(E4) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E4) | = | "element" |
dm:node-name(E4) | = | xs:QName("https://www.example.com/catalog", "description") |
dm:string-value(E4) | = | "\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n " |
dm:typed-value(E4) | = | xs:untypedAtomic("\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n ") |
dm:type-name(E4) | = | cat:description |
dm:is-id(E4) | = | false |
dm:is-idrefs(E4) | = | false |
dm:parent(E4) | = | ([ |
dm:children(E4) | = | ([ |
dm:attributes(E4) | = | () |
dm:namespace-nodes(E4) | = | ([ |
dm:namespace-bindings(E4) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Element node E5 | ||
dm:base-uri(E5) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E5) | = | "element" |
dm:node-name(E5) | = | xs:QName("https://www.w3.org/1999/xhtml", "html:p") |
dm:string-value(E5) | = | "\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n " |
dm:typed-value(E5) | = | xs:untypedAtomic("\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n ") |
dm:type-name(E5) | = | xs:anyType |
dm:is-id(E5) | = | false |
dm:is-idrefs(E5) | = | false |
dm:parent(E5) | = | ([ |
dm:children(E5) | = | ([ |
dm:attributes(E5) | = | () |
dm:namespace-nodes(E5) | = | ([ |
dm:namespace-bindings(E5) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Text node T2 | ||
dm:base-uri(T2) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T2) | = | "text" |
dm:string-value(T2) | = | "\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n " |
dm:typed-value(T2) | = | xs:untypedAtomic("\n Lyrics from the hit song 'It's Been Awhile'\n are shown in white, beneath the large\n 'Flock & Weld' Staind logo.\n ") |
dm:type-name(T2) | = | xs:untypedAtomic |
dm:parent(T2) | = | ([ |
// Element node E6 | ||
dm:base-uri(E6) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E6) | = | "element" |
dm:node-name(E6) | = | xs:QName("https://www.example.com/catalog", "price") |
dm:string-value(E6) | = | "25.00" |
// The typed-value is based on the content type of the complex type for the element | ||
dm:typed-value(E6) | = | cat:monetaryAmount(25.0) |
dm:type-name(E6) | = | cat:price |
dm:is-id(E6) | = | false |
dm:is-idrefs(E6) | = | false |
dm:parent(E6) | = | ([ |
dm:children(E6) | = | ([ |
dm:attributes(E6) | = | () |
dm:namespace-nodes(E6) | = | ([ |
dm:namespace-bindings(E6) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Text node T3 | ||
dm:base-uri(T3) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T3) | = | "text" |
dm:string-value(T3) | = | "25.00" |
dm:typed-value(T3) | = | xs:untypedAtomic("25.00") |
dm:type-name(T3) | = | xs:untypedAtomic |
dm:parent(T3) | = | ([ |
// Element node E7 | ||
dm:base-uri(E7) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E7) | = | "element" |
dm:node-name(E7) | = | xs:QName("https://www.example.com/catalog", "album") |
dm:string-value(E7) | = | " It's Been A While 10.99 Staind " |
dm:typed-value(E7) | = | fn:error() |
dm:type-name(E7) | = | cat:albumType |
dm:is-id(E7) | = | false |
dm:is-idrefs(E7) | = | false |
dm:parent(E7) | = | ([ |
dm:children(E7) | = | ([ |
dm:attributes(E7) | = | ([ |
dm:namespace-nodes(E7) | = | ([ |
dm:namespace-bindings(E7) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Attribute node A8 | ||
dm:node-kind(A8) | = | "attribute" |
dm:node-name(A8) | = | xs:QName("", "code") |
dm:string-value(A8) | = | "A1481344" |
dm:typed-value(A8) | = | xs:ID("A1481344") |
dm:type-name(A8) | = | xs:ID |
dm:is-id(A8) | = | true |
dm:is-idrefs(A8) | = | false |
dm:parent(A8) | = | ([ |
// Attribute node A9 | ||
dm:node-kind(A9) | = | "attribute" |
dm:node-name(A9) | = | xs:QName("", "label") |
dm:string-value(A9) | = | "Staind : Its Been A While" |
dm:typed-value(A9) | = | xs:token("Staind : Its Been A While") |
dm:type-name(A9) | = | xs:token |
dm:is-id(A9) | = | false |
dm:is-idrefs(A9) | = | false |
dm:parent(A9) | = | ([ |
// Attribute node A10 | ||
dm:node-kind(A10) | = | "attribute" |
dm:node-name(A10) | = | xs:QName("", "formats") |
dm:string-value(A10) | = | "CD" |
dm:typed-value(A10) | = | cat:formatType("CD") |
dm:type-name(A10) | = | cat:formatType |
dm:is-id(A10) | = | false |
dm:is-idrefs(A10) | = | false |
dm:parent(A10) | = | ([ |
// Element node E8 | ||
dm:base-uri(E8) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E8) | = | "element" |
dm:node-name(E8) | = | xs:QName("https://www.example.com/catalog", "title") |
dm:string-value(E8) | = | "It's Been A While" |
dm:typed-value(E8) | = | xs:token("It's Been A While") |
dm:type-name(E8) | = | xs:token |
dm:is-id(E8) | = | false |
dm:is-idrefs(E8) | = | false |
dm:parent(E8) | = | ([ |
dm:children(E8) | = | ([ |
dm:attributes(E8) | = | () |
dm:namespace-nodes(E8) | = | ([ |
dm:namespace-bindings(E8) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Text node T4 | ||
dm:base-uri(T4) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T4) | = | "text" |
dm:string-value(T4) | = | "It's Been A While" |
dm:typed-value(T4) | = | xs:untypedAtomic("It's Been A While") |
dm:type-name(T4) | = | xs:untypedAtomic |
dm:parent(T4) | = | ([ |
// Element node E9 | ||
dm:base-uri(E9) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E9) | = | "element" |
dm:node-name(E9) | = | xs:QName("https://www.example.com/catalog", "description") |
dm:string-value(E9) | = | "" |
// xsi:nil is true so the typed value is the empty sequence | ||
dm:typed-value(E9) | = | () |
dm:type-name(E9) | = | cat:description |
dm:is-id(E9) | = | false |
dm:is-idrefs(E9) | = | false |
dm:parent(E9) | = | ([ |
dm:children(E9) | = | () |
dm:attributes(E9) | = | ([ |
dm:namespace-nodes(E9) | = | ([ |
dm:namespace-bindings(E9) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Attribute node A11 | ||
dm:node-kind(A11) | = | "attribute" |
dm:node-name(A11) | = | xs:QName("https://www.w3.org/2001/XMLSchema-instance", "xsi:nil") |
dm:string-value(A11) | = | "true" |
dm:typed-value(A11) | = | xs:boolean("true") |
dm:type-name(A11) | = | xs:boolean |
dm:is-id(A11) | = | false |
dm:is-idrefs(A11) | = | false |
dm:parent(A11) | = | ([ |
// Element node E10 | ||
dm:base-uri(E10) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E10) | = | "element" |
dm:node-name(E10) | = | xs:QName("https://www.example.com/catalog", "price") |
dm:string-value(E10) | = | "10.99" |
dm:typed-value(E10) | = | cat:monetaryAmount(10.99) |
dm:type-name(E10) | = | cat:price |
dm:is-id(E10) | = | false |
dm:is-idrefs(E10) | = | false |
dm:parent(E10) | = | ([ |
dm:children(E10) | = | ([ |
dm:attributes(E10) | = | ([ |
dm:namespace-nodes(E10) | = | ([ |
dm:namespace-bindings(E10) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Attribute node A12 | ||
dm:node-kind(A12) | = | "attribute" |
dm:node-name(A12) | = | xs:QName("", "currency") |
dm:string-value(A12) | = | "USD" |
dm:typed-value(A12) | = | cat:currencyType("USD") |
dm:type-name(A12) | = | cat:currencyType |
dm:is-id(A12) | = | false |
dm:is-idrefs(A12) | = | false |
dm:parent(A12) | = | ([ |
// Text node T5 | ||
dm:base-uri(T5) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T5) | = | "text" |
dm:string-value(T5) | = | "10.99" |
dm:typed-value(T5) | = | xs:untypedAtomic("10.99") |
dm:type-name(T5) | = | xs:untypedAtomic |
dm:parent(T5) | = | ([ |
// Element node E11 | ||
dm:base-uri(E11) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(E11) | = | "element" |
dm:node-name(E11) | = | xs:QName("https://www.example.com/catalog", "artist") |
dm:string-value(E11) | = | " Staind " |
dm:typed-value(E11) | = | " Staind " |
dm:type-name(E11) | = | xs:string |
dm:is-id(E11) | = | false |
dm:is-idrefs(E11) | = | false |
dm:parent(E11) | = | ([ |
dm:children(E11) | = | ([ |
dm:attributes(E11) | = | () |
dm:namespace-nodes(E11) | = | ([ |
dm:namespace-bindings(E11) | = | ("xml", "https://www.w3.org/XML/1998/namespace", "", "https://www.example.com/catalog", "html", "https://www.w3.org/1999/xhtml", "xlink", "https://www.w3.org/1999/xlink", "xsi", "https://www.w3.org/2001/XMLSchema-instance") |
// Text node T6 | ||
dm:base-uri(T6) | = | xs:anyURI("https://www.example.com/catalog.xml") |
dm:node-kind(T6) | = | "text" |
dm:string-value(T6) | = | " Staind " |
dm:typed-value(T6) | = | xs:untypedAtomic(" Staind ") |
dm:type-name(T6) | = | xs:untypedAtomic |
dm:parent(T6) | = | ([ |
A graphical representation of the data model for the preceding example is shown below. Document order in this representation can be found by following the traditional left-to-right, depth-first traversal; however, because the image has been rotated for easier presentation, this appears to be bottom-to-top, depth-first order.
Graphic representation of the data model.
[ |
The following items are
The following items are
The following changes have been made to this document since the
Update the text and diagrams that specify the type system for XPath, XQuery, and XSLT.
Incorporate new material that defines a new kind of item — map item — in the data model. See
Incorporate new material that defines a new kind of item — array item — in the data model. See
Update document text to reflect version 3.1
Clarify the meaning of the word identity
in the context of this specification.
Clarify that there exists in the data model only one unparsed entity associated with any given name.