XQuery 1.0 and XPath 2.0 Data ModelWD-xpath-datamodel-20050915W3C Working Draft15September2005http://www.w3.org/TR/2005/WD-xpath-datamodel-20050915/XMLRevisions to LC Drafthttp://www.w3.org/TR/xpath-datamodel/http://www.w3.org/TR/2005/WD-xpath-datamodel-20050404/http://www.w3.org/TR/2005/WD-xpath-datamodel-20050211/http://www.w3.org/TR/2004/WD-xpath-datamodel-20041029/Mary Fernández (XML Query WG)AT&T Labsmff@research.att.comAshok Malhotra (XML Query and XSL WGs)Oracle Corporationashok.malhotra@alum.mit.eduJonathan Marsh (XSL WG)Microsoftjmarsh@microsoft.comMarton Nagy (XML Query WG)Science Applications International Corporation (SAIC)marton.nagy@saic.comNorman Walsh (XSL WG)Sun MicrosystemsNorman.Walsh@Sun.COM
This section describes the status of this document at the time
of its publication. Other documents may supersede this document. A
list of current W3C publications and the latest revision of this
technical report can be found in the W3C technical reports index at
http://www.w3.org/TR/.
This is a Public Working Draft for review by W3C Members and
other interested parties.
Publication as a Working Draft does not imply endorsement by the W3C
Membership. This is a draft document and may be updated, replaced or
obsoleted by other documents at any time. It is inappropriate to cite
this document as other than work in progress.
The XQuery 1.0 and XPath 2.0 Data Model has been defined jointly by
the XML Query Working Group
and the
XSL Working Group
(both part of the
XML Activity).
This draft includes many corrections and changes based on member-only
and public comments on the Last Call
Working Draft
(http://www.w3.org/TR/2005/WD-xpath-datamodel-20050404/). These decisions
are recorded
in the
Bugzilla database (http://www.w3.org/Bugs/Public/).
A list of changes introduced by this draft can be found
in .
This draft is being provided to permit public review of the changes
that have been made as a result of the Last Call comments.
Comments on the
changes should be made against the pertinent Last Call comment
(instructions can be found at
http://www.w3.org/XML/2005/04/qt-bugzilla). If access to that system is
not feasible, you may send your comments to the W3C mailing list,
public-qt-comments@w3.org
(archived at
http://lists.w3.org/Archives/Public/public-qt-comments/). Please start
the subject line with “[DM]” so comments can be classified correctly.
The XML Query and XSL Working Groups expect to progress this document to
Candidate
Recommendation status in
the very near future.
The patent policy for this document is the 5 February
2004 W3C Patent Policy.
Patent disclosures relevant
to this specification may be found on the XML Query
Working Group's patent disclosure page and the XSL Working Group's
patent disclosure page. An individual who has actual knowledge of
a patent which the individual believes contains Essential Claim(s) with
respect to this specification should disclose the information in
accordance with section
6 of the W3C Patent Policy.
This document defines the W3C XQuery 1.0 and XPath 2.0 Data Model,
which is the data model of ,
, and , and any other
specifications that reference it. This data model is based on the
data model and earlier work on an
. This document is the result of joint
work by the and the .
English
See the CVS changelog.
Introduction
This document defines the XQuery 1.0 and XPath 2.0 Data Model,
which is the data model of , and
The XQuery 1.0 and XPath 2.0 Data Model (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 closed with respect to a data model if the value
of every expression in the language is guaranteed to be in the data model.
XSLT 2.0, XQuery 1.0, and XPath 2.0 are all closed with respect to
the data model.
The data model is based on the
(henceforth "Infoset"), but it requires the following new features to
meet the and :
Support for XML Schema types. The XML Schema recommendations
define features, such as structures ()
and simple data types (), that extend
the XML Information Set with precise type information.
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 1.0 and XPath 2.0 Data Model
specifies what information in the documents is accessible, but it 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 1.0 and XPath 2.0 Data Model, how they are accessed, and how
they relate to values in the Infoset and PSVI.
Concepts
This section outlines a number of general concepts that apply throughout
this specification.
Terminology
For a full glossary of terms, see .
In this specification the words must,
must not,
should,
should not,
may and
recommended
are to be interpreted as described in .
This specification distinguishes between the data model as a general
concept and specific items (documents, elements, atomic values, etc.)
that are concrete examples of the data model by identifying all concrete
examples as instances of the data model.
Every
instance of the data model is a
sequence..
A sequence
is an ordered collection of zero or more items. A sequence cannot be a member
of a sequence. A single item appearing on its own is modeled as a
sequence containing one item. Sequences are defined in .
An item
is either a
node or an
atomic value,
Every node is one of the seven kinds of nodes defined in . Nodes form a tree that consists of a root node plus
all the nodes that are reachable directly or indirectly from the root node
via the children,
attributes, and namespace-nodes
accessors. Every node belongs to exactly one tree, and every tree has
exactly one root node.
A
tree whose root node is a Document Node is referred to as a
document.
A tree whose root node is not a Document Node is
referred to as a fragment.
An
atomic value is a value in the value space
of an atomic type and is labeled with
the name of that atomic type.
An atomic type
is a primitive simple type
or a type derived by restriction from
another atomic type.
(Types derived by list or union are not atomic.)
There
are 23
primitive simple types: the 19 defined in
of and
xdt:anyAtomicType,
xdt:untypedAtomic, xdt:dayTimeDuration,
and xdt:yearMonthDuration,
defined in . The other new type,
xdt:untyped, is also described in .
A type is represented in the data model by an
expanded-QName.
An
expanded-QName is a set of three values consisting of a
possibly empty prefix, a possibly empty namespace URI, and a local
name. See .
Implementation-defined indicates an aspect that
may differ between implementations, but must be specified by the
implementor for each particular implementation.
Implementation-dependent indicates an aspect
that may differ between implementations, is not specified by this or
any W3C specification, and is not required to be specified by the
implementor for any particular implementation.
Within this specification, the term URI refers to a Universal
Resource Identifier as defined in
and extended in
with the new name IRI. The term URI has been retained in preference to
IRI to avoid introducing new names for concepts such as “Base URI”
that are defined or referenced across the whole family of XML
specifications.
In all cases where this specification leaves the behavior
implementation-defined or implementation-dependent, the implementation
has the option of providing mechanisms that allow the user to
influence the behavior.
Notation
In addition to prose, this specification defines a set of accessor
functions to explain the data model. The accessors are shown with the
prefix dm:. This prefix is always shown in italics to
emphasize that these functions are abstract; they exist to explain the
interface between the data model and specifications that rely on the
data model: they are not accessible directly from the host
language.
Several prefixes are used throughout this document for notational
convenience. The following bindings are assumed.
xs: bound to
http://www.w3.org/2001/XMLSchema
xsi: bound to
http://www.w3.org/2001/XMLSchema-instance
xdt: bound to
http://www.w3.org/2005/xpath-datatypes
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
, described in
.
This document relies on the and 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.
Node Identity
Each node has a unique identity. Every node in an instance of the data model is unique: identical to
itself, and not identical to any other node. (Atomic values do not have identity;
every instance of the value “5” as an integer is identical to every
other instance of the value “5” as an integer.)
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.
Document Order
A
document order is defined among all the nodes
accessible during a given query or transformation. Document order is a
total ordering, although the relative order of some nodes is
implementation-dependent. Informally, document order is the order in
which nodes appear in the XML serialization of a document.Document order is
stable, which means that the relative order of two
nodes will not change during the processing of a given query or
transformation, even if this order is implementation-dependent.
Within a tree, document order satisfies the following constraints:
The 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.
The relative order of Namespace Nodes 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 Attribute Nodes 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.
The relative order of distinct trees is
stable but implementation-dependent.
Sequences
An important characteristic of the data model is that there is no
distinction between an item (a node or an atomic value) and a
singleton sequence containing that item. An item is
equivalent to a singleton sequence containing that item and vice
versa.
A sequence may contain nodes, atomic values, or any mixture of
nodes and atomic values. When a node is added to a sequence its
identity remains the same. Consequently a node may occur in more than
one sequence and a sequence may contain duplicate items.
Sequences never contain other sequences; if sequences are combined,
the result is always a “flattened” sequence. In other words, appending
“(d e)” to “(a b c)” produces a sequence of length 5: “(a b c d e)”.
It does not produce a sequence of length 4: “(a b c (d e))”,
such a nested sequence never occurs.
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 2.0, duplicate removal is provided by functions on node
sequences.
Types
The data model supports strongly typed languages such as
and
that have a type system based on . The
type system is formally defined in .
Every item in the data model has both
a value and a type.
In addition to nodes, the data model can represent atomic values like
the number 5 or the string “Hello World.” For each of these
atomic values, the data model contains both the value of the item
(such as 5 or “Hello World”) and its type name (such as
xs:integer or xs:string).
Representation of Types
The data model uses
expanded-QNames to
represent the names of schema types, which include the built-in
types defined by , five additional types
defined by this specification, and may include other user- or
implementation-defined types.
Support for additional user-defined or
implementation-defined types is implementation-defined.
For XML Schema types, the namespace name of the expanded-QName
is the target namespace property
of the type definition, and its local name is the name property of the type
definition.
The data model relies on the fact that an expanded-QName uniquely
identifies every named type. Although it is possible for different
schemas to define different types with the same expanded-QName, at
most one of them can be used in any given validation episode. The data model
cannot support environments where different types with the same expanded-QName
are available.
For anonymous types, the processor must construct an
anonymous type name
that is distinct from the name of every named type and the name of
every other anonymous type.
An
anonymous type name is an implementation dependent,
unique type name provided by the processor for every anonymous
type declared in the schemas available.
Anonymous type names
must
be globally unique across all anonymous types that are accessible to
the processor. In the formalism of this specification, the anonymous
type names are assumed to be xs:QNames, but in practice
implementations are not required to use xs:QNames to
represent the implementation-dependent names of anonymous types.
The names of anonymous types are implementation-dependent.
The scope over which the names of anonymous types must be
meaningful and distinct is depends on the processing context.
It is the responsibility of the host language to define the
size and scope of the processing context.
The data model does not represent element or attribute declaration
schema components, but it supports various type-related operations.
The semantics of other operations, for example, checking if a particular
instance of an Element Node has a given schema type is defined in
.
Predefined Types
In addition to the 19 types defined in
of , the data model defines five
additional types: xdt:anyAtomicType,
xdt:untyped, xdt:untypedAtomic,
xdt:dayTimeDuration, and
xdt:yearMonthDuration:
The datatype xdt:untyped denotes the dynamic type of
an element node that has not been validated, or has been validated in
skip mode. No predefined types are derived from xdt:untyped.
The datatype xdt: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 xdt:untypedAtomic. No
predefined types are derived from xdt:untypedAtomic.
The datatype xdt: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:integer and
xs:string, have xdt:anyAtomicType
as their base type.
The type xdt: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 xdt:dayTimeDuration is the set of
fractional second values. The components of
xdt:dayTimeDuration correspond to the day, hour, minute
and second components defined in Section 5.5.3.2 of ,
, respectively. xdt:dayTimeDuration is
derived from xs:duration as follows:
The type xdt:yearMonthDuration is derived from
xs:duration by restricting its lexical representation to
contain only the year and month components. The value space of
xdt:yearMonthDuration is the set of
xs:integer month values. The year and month components of
xdt:yearMonthDuration correspond to the Gregorian year
and month components defined in section 5.5.3.2 of ,
respectively.
The type xdt:yearMonthDuration is derived from
xs:duration as follows:
The diagram below shows how the nodes,
primitive
simple types, and user defined types fit together into
a hierarchy.
The xs:IDREFS, xs:NMTOKENS,
xs:ENTITIES and user-defined list and union
types are special types in that these types are lists or unions
rather than true subtypes.
Atomic Values
An atomic value can be constructed from a lexical
representation. Given a string and an atomic type, the atomic value is
constructed in such a way as to be
consistent with schema validation.
If the
string does not represent a valid value of the type, an error is
raised. When xdt:untypedAtomic is specified as the type,
no validation takes place. The details of the construction are
described in
and the related
section of .
String Values
A string value can be constructed from an atomic value.
Such a value is constructed by
converting the atomic value to its string representation as described
in .
Using the canonical lexical representation for atomic values
may not always be compatible with XPath 1.0. These and other backwards
incompatibilities are described in
.
Data Model Construction
This section describes the constraints on instances of the data model.
The data model supports well-formed XML documents conforming to
or .
Documents that are not well-formed are,
by definition, not XML. XML documents that do not conform to
or
are not supported (nor are they supported by
).
In other words, the data model supports the following classes
of XML documents:
Well-formed documents conforming to or
.
DTD-valid documents conforming to or
, and
W3C XML Schema-validated documents.
This document describes how to construct an instance of the data
model from an infoset () or a Post Schema Validation
Infoset (PSVI), the augmented infoset produced by an XML Schema
validation episode.
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. 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 . Examples of these are
document fragments
and sequences of Document Nodes.
The data model also supports values that are not nodes. Examples of
these are sequences of atomic values,
or sequences mixing nodes and atomic
values. These are necessary to be able to represent the results of
intermediate expressions in the data model during expression
processing.
Direct Construction
Although this document describes construction of an instance of the
data model in terms of infoset properties, an infoset is not a
necessary precondition for building an instance of the data model.
There are no constraints on how an instance of the data model may be
constructed directly, save that the resulting instance
must satisfy all of the constraints described in
this document.
Construction from an Infoset
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 unexpanded entity
reference information items.
The infoset must provide all of the properties identified as
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
must be consistent with the description provided
for each node kind.
Construction from a PSVI
An instance of the data model can be constructed from a PSVI, whose
element and attribute information items have been strictly assessed,
laxly assessed, or have not been assessed. Constructing an instance of
the data model from a PSVI must be consistent with
the description provided in this section and with the description
provided for each node kind.
Data model construction requires that the PSVI provide unique names
for all anonymous schema types.
does not require all schema processors to
provide unique names for anonymous schema types. In order to build an
instance of the data model
from a PSVI produced by a processor that does not provide the names,
some post-processing will be required in order to assure that they are
all uniquely identified before construction begins.
An
incompletely validated document is an XML document that has a
corresponding schema but whose schema-validity assessment has resulted
in one or more element or attribute information items being assigned
values other than 'valid' for the validity
property in the PSVI.
The data model supports incompletely validated documents. Elements
and attributes that are not valid are treated as having unknown types.
The most significant difference between Infoset construction and PSVI
construction occurs in the area of schema type assignment. Other differences
can also arise from schema processing: default attribute and element values
may be provided, white space normalization of element content may occur, and the
user-supplied lexical form of elements and attributes with atomic schema types
may be lost.
Mapping PSVI Additions to Node Properties
A PSVI element or attribute information item may have a
validity property.
The validity property may be
valid, invalid,
or notKnown
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 valid. Nodes
that are not valid are treated as if they
were simply well-formed XML and only very general schema type
information is associated with them.
Element and Attribute Node Type Names
The precise definition of the schema type of an element or attribute
information item depends on the properties of the PSVI.
In the PSVI,
only guarantees the existence of either the
type definition property,
or the
type definition namespace,
type definition name and
type definition anonymous
properties.
If the type definition refers to a union type, there
are further properties defined, that refer to the type definition
which actually validated the item's normalized value. These properties
are not used to determine the schema type of the node
but they may be used to determine the typed value of
the node, as described in .
The type depends on the
validity and
validation attempted properties in
the PSVI. If:
The validity and
validation attempted properties exist
and have the values valid and
full, respectively, the
schema type of an element or attribute information item is
represented by an expanded-QName
whose namespace and local name correspond
to the first applicable items in the following list:
If the type definition property exists:
If the {name} property is not absent, the {target namespace} and {name}
properties of the type definition
property;
Otherwise, the namespace and local name of the appropriate
anonymous type name.
If type definition anonymous exists:
If it is false:
the type definition namespace
and the type definition name properties;
Otherwise, the namespace and local name of the appropriate
anonymous type name.
The validity property exists
and is invalid, or the
validition attempted property exists
and is partial, the schema type of an element
is xs:anyType and the type of an attribute is
xs:anySimpleType.
The validity property exists and is
notKnown, and the
validition attempted property exists
and is none, the schema type of an element is
xdt:untyped and the type of an attribute is
xdt:untypedAtomic.
The validity or
valadition attempted properties do not
exist, the schema type of an element is
xdt:untyped and the type of an attribute is
xdt:untypedAtomic.
The prefix associated with the type names is implementation-dependent.
The prefix associated with type names is
implementation-dependent.
Typed Value Determination
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 ; for other kinds of
Attribute 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 not be the same as
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
by a recursive process called typed value determination. This process
begins with T, the schema type of the node itself, as
represented in the PSVI. The type T has a variety, which
is either atomic, union, or list. The typed value determination
process is defined as follows:
If the nilled property of the node in question is
true, then the typed value is the empty sequence.
If T is xs:anySimpleType, the typed value
is the schema normalized value as
an instance of xdt:untypedAtomic.
If the {variety} of T is atomic,
the typed value is an instance of T derived
from the schema normalized value in
a way consistent with XML Schema validation.
If the {variety} of T is union, then the type of the
typed value is the determined by the type definition that actually
validated the content of the node, as follows:
If member type definition exists:
If the {name} property exists, the {target namespace} and {name}
properties of the member type definition;
otherwise, the appropriate anonymous type name.
If member type definition anonymous exists:
If it is false, the member type definition namespace
and member type definition name properties;
otherwise, the appropriate anonymous type name.
The resulting type is substituted for T, and the typed
value determination process is invoked recursively.
If the {variety} of T is list, the
schema normalized value of the
node is considered to be a space-separated list of lexical forms, each of
which has its own type. For each of these lexical forms, the type of the
corresponding item is found in {item type definition}. This type is then
substituted for T, and the typed value determination process is invoked
recursively for each member of the list.
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.
Relationship Between Typed-Value and String-Value
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:
<offset xsi:type="xs:integer">0030</offset>
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:
If the type-name of the node denotes a union type, the implementation
must be able to deliver the typed-value of the node as an instance of the
appropriate member type. For example, if the type-name property of an
element node is my:integer-or-string, which is defined as a union of
xs:integer and xs:string, and the string-value of the node is "47", the
implementation must be able to deliver the typed-value of the node as
either the integer 47 or the string "47", depending on which member type
validated the element.
If the type-name of the node is xs:QName, xs:NOTATION, or is derived
from one of these types, the implementation must be able to deliver the
typed-value of the node 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 ).
Pattern Facets
Creating a subtype by restriction generally reduces the
value space of the original schema type. For example,
expressing a hat size as a restriction of decimal with a minimum value
of 6.5 and maximum value of 8.0 creates a schema type whose legal values are
only those in the range 6.5 to 8.0.
The pattern facet is different because it restricts the
lexical space of the schema type, not its value space.
Expressing a three-digit number as a restriction of integer with the
pattern facet “[0-9]{3}” creates a schema type whose legal values
are only those with a lexical form consisting of three digits.
The pattern facet is not reversible in practice; a given point in
the value space of a type may not have a lexical representation that
satisfies the pattern facet of the type and even if it does have such
a representation, there's no practical way to determine what it is.
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 not be valid after
serialization.
Dates and Times
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 xdt: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, ()}”.
Note: 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.
QNames and NOTATIONS
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 absent, then the prefix must
also be absent.
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.
Infoset Mapping
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.
An Infoset can also be constructed by serializing an instance of
the data model and parsing it. Serialization is governed by
.
Accessors
A set of accessors is defined on nodes in
the data model. For consistency, all the accessors are defined on
every kind of node, although several accessors return a constant empty
sequence on some kinds of nodes.
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 undefined.
Attempting to access an undefined property is always an error. Behavior
in these cases is implementation-defined and the host language is responsible
for determining the result.
Some typed values in the data model are undefined.
Attempting to access an undefined property is always an error. Behavior
in these cases is implementation-defined and the host language is responsible
for determining the result.attributes Accessor
The attributes accessor returns the attributes of
a node as a sequence containing zero or more Attribute Nodes.
The order of Attribute Nodes is stable but implementation dependent.
It is defined on
all seven node kinds.
base-uri Accessor
The base-uri accessor returns the base URI of a node
as a sequence containing zero or one URI reference. For more information
about base URIs, see .
It is defined on
all seven node kinds.
children Accessor
The children accessor returns the children of a node
as a sequence containing zero or more nodes.
It is defined on
all seven node kinds.
document-uri Accessor
The document-uri accessor returns the
absolute URI of the resource from which the Document Node was constructed, if
the absolute URI is available. If there is no URI available, or if it cannot
be made absolute when the Document Node is constructed, or if it is used
on a node other than a Document Node,
the empty sequence is returned.
It is defined on
all seven node kinds.
is-id Accessor
The is-id accessor returns true if the
node is an XML ID. Exactly what constitutes an ID depends in part on
how the data model was constructed, see
and .
It is defined on all seven
node kinds.
is-idrefs Accessor
The is-idrefs accessor returns true if the
node is an XML IDREF or IDREFS.
Exactly what constitutes an IDREF or IDREFS depends in part on
how the data model was constructed, see
and .
It is defined on all seven
node kinds.
namespace-bindings Accessor
The namespace-bindings accessor returns the
dynamic, in-scope namespaces associated with a node as a set of
prefix/URI pairs, using an implementation-dependent
representation.
The representation of the set of prefix/URI pairs returned
by the namespace-bindings accessor is
implementation-dependent.
The prefix for the default namespace is the zero length string.
The namespace-bindings accessor is defined on
all seven node kinds.
Note: this accessor and the namespace-nodes accessor provide
two views of the same information.
namespace-nodes Accessor
The namespace-nodes accessor returns the dynamic,
in-scope namespaces associated with a node as a sequence containing
zero or more Namespace Nodes. The order of Namespace Nodes is stable
but implementation dependent.
It is defined on
all seven node kinds.
Note: this accessor and the namespace-bindings accessor provide
two views of the same information. Implementations that do not need to expose
Namespace Nodes might choose not to implement this accessor.
nilled Accessor
The nilled accessor returns true if the
node is nilled.
introduced the nilled mechanism to
signal that an element should be accepted as valid when it has no
content even when it has a content type which does not require or even
necessarily allow empty content.
It is defined on
all seven node kinds.
node-kind Accessor
The node-kind accessor returns a string identifying the
kind of node. It will be one of the following, depending on the kind of
node:
“attribute”,
“comment”,
“document”,
“element”,
“namespace”
“processing-instruction”, or
“text”.
It is defined on
all seven node kinds.
node-name Accessor
The node-name accessor returns the name of the node
as a sequence of zero or one xs:QNames. Note that the
QName value includes an optional prefix as described in
.
It is defined on
all seven node kinds.
parent Accessor
The parent accessor returns the parent of a node
as a sequence containing zero or one nodes.
It is defined on
all seven node kinds.
string-value Accessor
The string-value accessor returns the string value
of a node.
It is defined on
all seven node kinds.
type-name Accessor
The type-name accessor returns the name of the schema type
of a node as a sequence of zero or one xs:QNames.
It is defined on
all seven node kinds.
typed-value Accessor
The typed-value accessor returns the
typed-value of the node as a sequence of zero or more atomic
values.
It is defined on
all seven node kinds.
unparsed-entity-public-id Accessor
The unparsed-entity-public-id accessor returns
the public identifier of an unparsed external entity declared in the
specified document. If no entity with the name specified in
$entityname exists, or if the entity is not an external
unparsed entity, or if the entity has no public identifier, the empty
sequence is returned.
It is defined on
all seven node kinds.
unparsed-entity-system-id Accessor
The unparsed-entity-system-id accessor returns the
system identifier of an unparsed external entity declared in the
specified document. If no entity with the name specified in $entityname
exists, or if the entity is not an external unparsed entity, the empty sequence
is returned.
It is defined on
all seven node kinds.
Nodes
There are seven kinds of
Nodes in the data model:
document,
element,
attribute,
text,
namespace,
processing instruction, and
comment. Each kind of
node is described in the following sections.
A host language based on the Data Model may specify that its usage of the
Data Model does not include namespace nodes. Namespace nodes are used only
in the "namespaces" property of an element node, which records the
bindings of namespace prefixes to namespace URIs. These bindings may be
represented either by means of namespace nodes or by using an alternative,
implementation-dependent representation.
The representation of namespaces, i.e. whether or not they
are represented as nodes, is implementation-dependent.
All nodes must satisfy
the following general constraints:
Every node must have a unique identity,
distinct from all other nodes.
The children property of a node must not
contain two consecutive Text Nodes.
The children property of a node must not
contain any empty Text Nodes.
The children and attributes properties of a node
must not
contain two nodes with the same identity.
Document Nodes
Overview
Document Nodes encapsulate XML documents. Documents have the following
properties:
base-uri, possibly empty.
children, possibly empty.
unparsed-entities, possibly empty.
document-uri, possibly empty.
string-value
typed-value
Document Nodes must satisfy the following constraints.
The childrenmust consist exclusively
of Element, Processing Instruction, Comment, and Text Nodes if it is not empty.
Attribute, Namespace, and Document Nodes can never appear as children
If a node N is among the children of a Document Node
D, then the parent of Nmust be D.
If a node N has a parent Document Node D,
then Nmust be among the children of
D.
In the , a
document information item
must have at least one child, its children must consist exclusively of
element information items,
processing instruction information items
and comment information items,
and exactly one of the children must be
an element information item.
This data model is more permissive: a
Document Node may be empty, it may have more than one Element Node as a
child, and it also permits Text Nodes as children.
Implementations that support DTD processing and access to the
unparsed entity accessors use the
unparsed-entities property to associate
information about an unordered collection of unparsed entities with a
Document Node. This property is accessed indirectly through the
unparsed-entity-system-id and
unparsed-entity-public-id functions.
Accessors
Returns the empty sequence
Returns the value of the base-uri property if it exists and is
not empty, otherwise returns the empty sequence.
Returns the value of the children property.
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 the empty sequence
Returns “document”.
Returns the empty sequence.
Returns the empty sequence
Returns the value of the string-value property.
Returns the empty sequence.
Returns the value of the typed-value property.
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.
Construction from an Infoset
The document information item is
required. A Document Node is constructed for each
document information item.
The following infoset properties are required:
children and
base URI.
The following infoset properties are optional:
unparsed entities.
Document Node properties are derived from the infoset as
follows:
The value of the base URI property.
The sequence of nodes constructed from the information
items found in the children
property.
For each element, processing instruction, and comment found in the
children property, a corresponding
Element, Processing Instruction, or Comment Node is constructed
and that sequence of nodes is used as the value of the children
property.
If present among the
children, the
document type declaration information item
is ignored.
If the unparsed entities property is
present and is not the empty set, the values of the
unparsed entity information items must be used
to support the unparsed-entity-system-id and
unparsed-entity-public-id accessors.
The internal structure of the values of the
unparsed-entities property is implementation
defined.
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 string-value of the node as an
xdt:untypedAtomic value.
The document-uri property
holds the absolute URI for the resource from which the document node
was constructed, if one is available and can be made absolute. For
example, if a collection of documents is returned by the
fn:collection function, the
document-uri property
may serve to distinguish between them even though each has the same
base-uri property.
If the document-uri is not
the empty sequence, then the following constraint must hold: the node returned
by evaluating fn:doc() with the
document-uri as its argument must
return the document node that provided the value of the
document-uri property.
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
Construction from a PSVI is identical to construction
from the Infoset.
Infoset Mapping
A Document Node maps to a
document information item. The mapping fails
and produces no value if the Document Node contains Text Node children
that do not consist entirely of white space or if the Document Node contains
more than one Element Node child.
The following properties are specified by this mapping:
A list of information items obtained by processing each of the
children in order and mapping each to
the appropriate information item(s).
The element information item that is among the
children.
An unordered set of unparsed entity information items
constructed from the
unparsed-entities.
Each unparsed entity maps to an unparsed entity
information item. The
following properties are specified by this mapping:
The name of the entity.
The system identifier of the entity.
The public identifier of the entity.
Implementation defined. In the many cases, the
document-uri
is the correct answer and implementations must
use this value if they have no better information. Implementations that
keep track of the original
declaration base URI
for entities should use that value.
The following properties of the unparsed entity
information item have no value:
notation name,
notation.
The following properties of the document
information item have no value:
notationscharacter encoding schemestandaloneversionall declarations processed.
Element Nodes
Overview
Element Nodes encapsulate XML elements. Elements have the following properties:
base-uri, possibly empty.
node-name
parent, possibly empty
type-name
children, possibly empty
attributes, possibly empty
namespaces
nilled
string-value
typed-value
is-id
is-idrefs
Element Nodes must satisfy the following constraints.
The childrenmust consist exclusively
of Element, Processing Instruction, Comment, and Text Nodes if it is not empty.
Attribute, Namespace, and Document Nodes can never appear as children
The Attribute Nodes of an element must have distinct
xs:QNames.
If a node N is among the children of an element
E, then the parent of Nmust be E.
Exclusive of Attribute and Namespace Nodes, if a node
N has a parent element E, then
Nmust be among the children of
E. (Attribute and Namespace Nodes have a parent, but
they do not appear among the children of their parent.)
The data model permits Element Nodes without parents
(to represent partial results during expression processing, for example).
Such Element Nodes must not
appear among the children of any other node.
If an Attribute Node A is among the attributes
of an element E, then the parent of Amust be E.
If an Attribute Node A has a
parent element E,
then Amust be among the attributes
of E.
The data model permits Attribute Nodes without parents.
Such Attribute Nodes must not
appear among the attributes of any Element Node.
If a Namespace Node N is among the namespaces
of an element E, then the parent of Nmust be E.
If a Namespace Node N has a
parent element E, then Nmust
be among the namespaces of E.
The data model permits Namespace Nodes without parents. Such
Namespace Nodes must not appear among the
namespaces of any Element Node. This constraint
is irrelevant for implementations that do not support Namespace Nodes.
If the type-name of an Element Node is
xdt:untyped, then the type-name of all its
descendant elements must also be xdt:untyped and the
type-name of all its Attribute Nodes must be
xdt:untypedAtomic.
If the type-name of an Element Node is
xdt:untyped, then the
nilled property must be false.
If the nilled property is true, then the
children property must not contain
Element Nodes or Text Nodes.
For every expanded QName
that appears in the node-name of the element,
the node-name of any Attribute Node among the
attributes of the element, or in any value of type
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 must be a prefix binding for this URI among the
namespaces of this
Element Node.
If any of the expanded QNames has an empty URI, then there
must not be any binding among the
namespaces of this
Element Node which binds the empty prefix to a URI.
Every element must include a Namespace Node and/or namespace binding
for the prefix xml bound to the URI
http://www.w3.org/XML/1998/namespace and there must be no other
prefix bound to that URI.
Accessors
Returns the value of the attributes property. The order of
Attribute Nodes is stable but implementation dependent.
Returns the value of the base-uri property if it exists and
is not empty. Otherwise, if the element has a parent, returns the value of the
base-uri of its parent; otherwise, returns
the empty sequence.
Returns the value of the children property.
Returns the empty sequence.
Returns the value of the is-id
property.
Returns the value of the is-idrefs
property.
Returns the value of the namespaces property as a set of prefix/URI
pairs.
Returns the value of the namespaces property as a sequence of
Namespace Nodes. The order of
Namespace Nodes is stable but implementation dependent.
Returns the value of the nilled property.
Returns “element”.
Returns the value of the node-name property.
Returns the value of the parent property.
Returns the value of the string-value property.
Returns the value of the type-name property.
Returns the value of the typed-value property.
Returns the empty sequence.
Returns the empty sequence.
Construction from an Infoset
The element information items are
required. An Element Node is constructed for each
element information item.
The following infoset properties are required:
namespace name,
local name,
children,
attributes,
in-scope namespaces,
base URI, and
parent.
Element Node properties are derived from the infoset as
follows:
The value of the base URI property.
An xs:QName constructed from the
prefix,
local name,
and
namespace name properties.
The node that corresponds to the
value of the parent property or
the empty sequence if there is no parent.
All Element Nodes constructed from an infoset have the type
xdt:untyped.
The sequence of nodes constructed from the information
items found in the children
property.
For
each element, processing instruction, comment, and maximal sequence of
adjacent character information items found in the
children property, a corresponding
Element, Processing Instruction, Comment, or Text Node is constructed
and that sequence of nodes is used as the value of the children
property.
Because the data model requires
that all general entities be expanded, there will never be
unexpanded entity reference information item
children.
A set of Attribute Nodes constructed from the
attribute information items
appearing in the attributes
property. This includes all of the special attributes
(xml:lang, xml:space, xsi:type, etc.)
but does not include namespace declarations (because they are not attributes).
Default and fixed attributes provided by the DTD
are added to the attributes and are
therefore included in the data model attributes of an element.
A set of Namespace Nodes constructed from the
namespace information items
appearing in the in-scope namespaces
property. Implementations that do not support Namespace Nodes may simply
preserve the relevant bindings in this property.
Implementations may ignore
namespace information items for
namespaces which are not known to be used. A namespace is known to be
used if:
It appears in the expanded QName
of the node-name of the element.
It appears in the expanded QName
of the node-name of any of the element's 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.
All Element Nodes constructed from an infoset have a
nilled property of false.
The string-value is constructed from the
character information itemchildren
of the
element and all its descendants. The precise rules for selecting
significant
character information items and
constructing characters from them is described in
of
.
This process is equivalent to concatenating the
string-values
of all of the Text Node descendants of
the resulting Element Node.
If the element has no such descendants, the string-value
is the empty string.
The string-value as an xdt:untypedAtomic.
All Element Nodes constructed from an infoset have a
is-id property of
false.
All Element Nodes constructed from an infoset have a
is-idrefs property of
false.
Construction from a PSVI
The following Element Node properties are affected by PSVI properties.
The type-name is
determined as described in .
The sequence of nodes constructed from the information
items found in the children
property.
For each element, processing instruction, comment, and maximal
sequence of adjacent character information items found in the
children property, a corresponding
Element, Processing Instruction, Comment, or Text Node is constructed
and that sequence of nodes is used as the value of the children
property.
For elements with schema simple types, or complex types with simple content,
if the schema normalized value
PSVI property exists, the processor
may use a sequence of nodes
containing the Processing Instruction and Comment Nodes corresponding
to the
processing instruction and
comment information items found in the
children
property, plus an optional single Text Node whose string value is
the schema normalized value for
the children property.
If the schema normalized value is
the empty string, the Text Node must not be
present, otherwise it must be present.
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.
Because the data model requires
that all general entities be expanded, there will never be
unexpanded entity reference information item
children.
A set of Attribute Nodes constructed from the
attribute information items
appearing in the attributes
property. This includes all of the special attributes
(xml:lang, xml:space, xsi:type, etc.)
but does not include namespace declarations (because they are not attributes).
Default and fixed attributes provided by XML Schema processing
are added to the attributes and are
therefore included in the data model attributes of an element.
A set of Namespace Nodes constructed from the
namespace information items
appearing in the in-scope namespaces
property. Implementations that do not support Namespace Nodes may simply
preserve the relevant bindings in this property.
Implementations may ignore
namespace information items for
namespaces which are not known to be used. A namespace is known to be
used if:
It appears in the expanded QName
of the node-name of the element.
It appears in the expanded QName
of the node-name of any of the element's attributes.
It appears in the expanded QName
of any values of type 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 validity property exists on
an information item and is valid then if
the nil property exists and is true,
then the nilled property is true.
In all other cases, including all cases where schema validity assessment was
not attempted or did not succeed, the
nilled property is false.
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 xdt:untyped, a complex
type with element-only content, or a complex type with mixed content: its
string-value is the concatenation of the string-values of all its
Text Node descendants in document order.
If the element has a simple type or a complex type with simple content:
its string-value is the schema normalized value
of the node.
If an implementation stores only the typed value of an element, it
may use any valid lexical representation of the typed value for the
string-value property.
The typed-value is calculated as follows:
If the element is of type xdt:untyped, its typed-value
is its string-value as an xdt: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
.
The result is a sequence of zero or more atomic values. The
relationship between the type-name, typed-value, and string-value of an
element node is consistent with XML Schema validation.
Note that in the case of dates and times, the timezone is preserved
as described in , and
in the case of xs:QNames and xs:NOTATIONs,
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 string-value as an xdt:untypedAtomic.
Otherwise, the element must be a complex type with element-only content.
The typed-value of such an element is undefined.
Attempting to access this property with the
typed-value accessor always raises an error.
If the type-name is xs:ID or a type derived from
xs:ID, true, otherwise false.
If the type-name is xs:IDREF or xs:IDREFS,
or a type derived from one of those types,
true, otherwise false.
All other properties have values that are consistent with construction
from an infoset.
Infoset Mapping
An Element Node maps to an element information item.
The following properties are specified by this mapping:
The namespace name of the value of node-name.
The local part of the value of node-name.
The prefix associated with the value of node-name.
A list of information items obtained by processing each of the
children in order and mapping each to
the appropriate information item(s).
An unordered set of information items obtained by processing each of the
attributes and mapping each to
the appropriate information item(s).
An unordered set of namespace information items constructed from the
namespaces.
Each in-scope namespace maps to a namespace information item. The
following properties are specified by this mapping:
The prefix associated with the namespace.
The URI associated with the namespace.
The value of base-uri.
If this node is the root of the infoset mapping operation,
unknown.
If this node has a parent, the information item that corresponds
to the node returned by parent.
Otherwise no value.
The following property has no value:
namespace attributes.
Attribute Nodes
Overview
Attribute Nodes represent XML attributes. Attributes have the
following properties:
node-name
parent, possibly empty
type-name
string-value
typed-value
is-id
is-idrefs
Attribute Nodes must satisfy the following constraints.
If an Attribute Node A is among the attributes
of an element E, then the parent of Amust be E.
If a Attribute Node A has a parent element
E, then Amust be among
the attributes of E.
The data model permits Attribute Nodes without parents
(to represent partial results during expression processing, for example).
Such attributes must not
appear among the attributes of any Element Node.
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.
Accessors
Returns the empty sequence.
If the attribute has a parent, returns the value of the
base-uri of its parent; otherwise it returns
the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns the value of the is-id
property.
Returns the value of the is-idrefs
property.
Returns the empty sequence.
Returns the empty sequence.
Returns the empty sequence.
Returns “attribute”.
Returns the value of the node-name property.
Returns the value of the parent property.
Returns the value of the string-value property.
Returns the value of the type-name property.
Returns the value of the typed-value property.
Returns the empty sequence.
Returns the empty sequence.
Construction from an Infoset
The attribute information items are
required. An Attribute Node is constructed for each
attribute information item.
The following infoset properties are required:
namespace name,
local name,
normalized value,
attribute type, and
owner element.
Attribute Node properties are derived from the infoset as
follows:
An xs:QName constructed from the
prefix,
local name,
and
namespace name properties.
The Element Node that corresponds to the value of the
owner element property
or the empty sequence if there is no owner.
The value xdt:untypedAtomic.
The normalized value of the
attribute.
The attribute’s typed-value
is its string-value as an xdt:untypedAtomic.
If the attribute is named xml:id and its
attribute type property does not
have the value ID, then processing
is performed. This will assure that the value does have the type ID
and that it is properly normalized. The
is-id is always true for
attributes named xml:id.
If the attribute type property
has the value ID, true, otherwise false.
If the attribute type property
has the value IDREF or IDREFS,
true, otherwise false.
Construction from a PSVI
The following Attribute Node properties are affected by PSVI properties.
The schema normalized value
PSVI property if that exists.
Otherwise, the normalized value property.
If an implementation stores only the typed value of an attribute, it
may use any valid lexical representation of the typed value for the
string-value property.
The type-name is
determined as described in .
The typed-value is calculated as follows:
If the attribute is of type xdt:untypedAtomic: its typed-value
is its string-value as an xdt:untypedAtomic.
Otherwise, a sequence of zero or more atomic values as described in
. The relationship between the
type-name, typed-value, and string-value of an attribute node is
consistent with XML Schema validation.
If the attribute is named xml:id and its
attribute type property does not
have the value ID, then processing
is performed. This will assure that the value does have the type ID
and that it is properly normalized. The
is-id is always true for
attributes named xml:id.
If the type-name is xs:ID or a type derived from
xs:ID, true, otherwise false.
If the type-name is xs:IDREF or xs:IDREFS,
or a type derived from one of those types,
true, otherwise false.
All other properties have values that are consistent with construction
from an infoset.
Note: attributes from the XML Schema instance namespace,
http://www.w3.org/2001/XMLSchema-instance,
(xsi:schemaLocation,
xsi:type, etc.) appear as ordinary attributes in the data model.
Infoset Mapping
An Attribute Node maps to an attribute information item.
The following properties are specified by this mapping:
The namespace name of the value of node-name.
The local part of the value of node-name.
The prefix associated with the value of node-name.
The value of string-value.
If this node has a parent, the information item that corresponds
to the node returned by parent.
Otherwise no value.
The following properties have no value:
specifiedattribute typereferences.
Namespace Nodes
Overview
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
namespaces property of
an element node.
Namespaces have the
following properties:
prefix, possibly empty
uri
parent, possibly empty
Namespace Nodes must satisfy the following constraints.
If a Namespace Node N is among the namespaces
of an element E, then the parent of Nmust be E.
If a Namespace Node N has a parent element
E, then Nmust be among
the namespaces of E.
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 2.0 the namespace axis is deprecated,
and it is not available at all in XQuery 1.0. XPath 2.0 implementations are
not required to expose the namespace axis, though they may do so if they
wish to offer backwards compatibility.
The information held in namespace
nodes is instead made available to applications using functions defined
in . Some properties of Namespace Nodes are
not exposed by these functions: in particular, properties related to the
identity of Namespace Nodes, their parentage, and their position in document
order. Implementations that do not expose the namespace axis can therefore
avoid the overhead of maintaining this information.
Implementations that expose the namespace axis must provide unique
Namespace Nodes for each element.
Each element has an associated set of Namespace Nodes, one for each
distinct namespace prefix that is in scope for the element (including
the xml prefix, which is implicitly declared by
and one for the default
namespace if one is in scope for the element. The element is the
parent of each of these Namespace Nodes; however, a Namespace Node is
not a child of its parent element. In implementations that expose the
namespace axis, elements never share namespace
nodes.
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.