XQuery 1.0 and XPath 2.0 Data Model (XDM)CR-xpath-datamodel-20060711W3C Candidate Recommendation11July2006http://www.w3.org/TR/2006/CR-xpath-datamodel-20060711/XMLRecent revisionshttp://www.w3.org/TR/xpath-datamodel/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/.
On 3 November 2005, this specification
was
published as a
Candidate
Recommendation,
and a Call for Implementations was announced. This revision is
published in order to give visibility to the technical decisions that
have been made so far during this phase of the process and to allow
review by W3C Members and other interested parties. The maturity level
of the specification remains unchanged, and the work is on track to
move forward to the
Proposed
Recommendation
stage when the exit criteria for the current phase have been met.
Publication as a Candidate Recommendation 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.
This specification will remain a Candidate Recommendation until at
least 28 February 2006.
This document has been jointly produced by the
XML Query Working Group
and the XSL Working Group,
both of which are part of the
XML Activity.
Publication as a Candidate Recommendation 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.
This draft includes corrections and changes based on
public comments
recorded in the W3C public Bugzilla repository
(http://www.w3.org/Bugs/Public/)
used for Last Call issues tracking. A list of substantive changes since the Last
Call Working Draft of 04 April 2005 can be found in
.
This Working Draft has been published primarily to give visibility
to certain changes in XDM resulting from recent decisions made jointly
by the XML Query Working Group and the XSL Working Group. The changes
were made in response to
bug #2768,
recorded in the W3C
public Bugzilla repository.
Comments on this document should be made in W3C's
public Bugzilla
system (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
XSLT/XPath/XQuery mailing list,
public-qt-comments@w3.org.
It will be
very helpful if you include the string [DM] in the subject line of
your comment, whether made in Bugzilla or in email. Each Bugzilla
entry and email message should contain only one comment. Archives of
the comments and responses are available at
http://lists.w3.org/Archives/Public/public-qt-comments/.
The Working Groups solicit user and implementor feedback especially
on the whitespace collapsing semantics imposed by
and
which are incompatible with current
common practice.
The XML Query
and XPath Test Suite is under development.
Implementors are encouraged to run this test suite and report their results.
A preliminary
XQuery Test Suite Result Summary
has been prepared that contains information submitted for several
implementations.
The XML Query and XSL WGs plan to submit this specification for
consideration as a W3C
Proposed Recommendation as soon as both the XQuery 1.0 specification
and the XSLT 2.0 specification have been submitted for consideration as a
W3C Proposed Recommendation.
This document was produced by groups operating under the 5 February 2004 W3C Patent Policy. W3C maintains a public list of any patent disclosures made in connection with the deliverables of the XML Query Working Group and also maintains a public list of any patent disclosures made in connection with the deliverables of the XSL Working Group; those pages also include instructions for disclosing a patent. 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 (XDM),
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
xs:untyped,
xs:untypedAtomic,
xs:anyAtomicType,
xs:dayTimeDuration,
and xs:yearMonthDuration,
defined 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
fn: bound to
http://www.w3.org/2006/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
Post-Schema-Validation
Infoset (PSVI). Information items
and properties are indicated by the styles information
item and infoset property, respectively.
Some aspects of type assignment rely on the ability to access properties of
the schema components. Such properties are indicated by the style
{component property}. Note that this does not mean a lightweight schema processor
cannot be used, it only means that the application must have some mechanism to
access the necessary properties.
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: xs:anyAtomicType,
xs:untyped, xs:untypedAtomic,
xs:dayTimeDuration, and
xs:yearMonthDuration.
These types are defined in the XML Schema namespace with permission
of the XML Schema Working Group, which is expected to add them to
some future version of XML Schema.
The datatype xs: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 xs:untyped.
The datatype xs:untypedAtomic denotes untyped atomic
data, such as text that has not been assigned a more specific type. An
attribute that has been validated in skip mode is represented in the Data
Model by an attribute node with the type xs:untypedAtomic. No
predefined types are derived from xs:untypedAtomic.
The datatype xs:anyAtomicType is an atomic type that
includes all atomic values (and no values that are not atomic). Its
base type is xs:anySimpleType from which all simple
types, including atomic, list, and union types are derived. All
primitive atomic types, such as xs:integer and
xs:string, have xs:anyAtomicType
as their base type.
The type xs:dayTimeDuration is derived from
xs:duration by restricting its lexical representation to
contain only the days, hours, minutes and seconds components. The
value space of xs:dayTimeDuration is the set of
fractional second values. The components of
xs:dayTimeDuration correspond to the day, hour, minute
and second components defined in Section 5.5.3.2 of .
An 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 ,
respectively.
The type xs: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 xs: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
is not always 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,
defines a
type definition property
as well as the
type definition namespace,
type definition name and
type definition anonymous
properties, which are effectively short-cut terms for properties of
the type definition.
Further, the element declaration and
attribute declaration
properties are defined for elements and attributes, respectively.
These declarations in turn will identify the
type definition
declared for the element or attribute. To distinguish the
type definition
given in the PSVI for the element or attribute instance
from the type definition associated
with the declaration, the former is referred to below as the actual
type and the latter as the declared type of the element or attribute
instance in question.
The type depends on the declared type, the actual type, and 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 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 type definition anonymous
is false: the {target namespace} and {name} properties of the actual type.
If type definition anonymous is true:
the namespace and local name of the anonymous type name supplied for
the actual type.
The validity property exists
and is invalid, or the
validation 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
validation attempted property exists
and is none, the schema type of an element is
xs:untyped and the type of an attribute is
xs:untypedAtomic.
The validity or
validation attempted properties do not
exist, the schema type of an element is
xs:untyped and the type of an attribute is
xs: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 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 T, the schema type of
the node itself, as represented in the PSVI. 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
; for union types, the mapping is the
lexical mapping defined in
modified
as appropriate by any applicable rules in
. The mapping, so modified, is a function
(in the mathematical sense) which maps to a single value even
in cases where the lexical mapping proper maps to multiple values.
The typed value is determined 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 or
xs:anyAtomicType, the typed value
is the schema normalized value as
an instance of 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 member
type definition if 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.
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:
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 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.
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
).
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 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.
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 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, ()}”.
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.
The string-value property of a Document Node must
be the concatenation of the string-values of all its
Text Node descendants in document order or,
if the document has no such descendants, the zero-length string.
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
xs: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
xs:untyped, then the type-name of all its
descendant elements must also be xs:untyped and the
type-name of all its Attribute Nodes must be
xs:untypedAtomic.
If the type-name of an Element Node is
xs: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.
The string-value property of an Element Node must
be the concatenation of the string-values of all its
Text Node descendants in document order or,
if the element has no such descendants, the zero-length string.
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
xs: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 xs: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.
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.
also permits an element with mixed
content to take a default or fixed value (which will always be a
simple value), but at the time of this writing it is unclear how such
a defaulted value is represented in the PSVI. Implementations
therefore may represent such a default value by
creating a text node, but are not required to do so.
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 xs: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 xs:untyped, its typed-value
is its string-value as an 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
.
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 xs: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 element has a complex type with element-only content, the
is-id
property is false. Otherwise, if the typed-value of the element
consists of exactly one atomic value that value is of type xs:ID, or
a type derived from xs:ID, the
is-id property is true,
otherwise it is false.
If the element has a complex type with element-only content, the
is-idrefs
property is 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
is-idrefs
property is true, otherwise it is 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 xs:untypedAtomic.
The normalized value of the
attribute.
The attribute’s typed-value
is its string-value as an xs: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 xs:untypedAtomic: its typed-value
is its string-value as an xs: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 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
is-idrefs
property is true, otherwise it is 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.