1 Introduction
This document defines the XQuery 1.0 and XPath 2.0 Data Model,
which is the data model of [XSLT 2.0] and
[XQuery 1.0: A Query Language for XML] 1.0.
The XQuery 1.0 and XPath 2.0 Data Model (henceforth "data model")
serves two purposes.
First, it defines precisely 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 a 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 [XML Information Set]
(henceforth "Infoset"), but it requires the following new features to
meet the [XPath Requirements Version 2.0] and [XML Query Requirements]:
-
Support for XML Schema types. The XML Schema recommendations
define features, such as structures ([XMLSchema Part 1])
and simple data types ([XMLSchema Part 2]), that extend
the XML Information Set with precise type information.
-
Representation of collections of documents and of
complex values. ([XML Query Requirements])
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.
Every value handled by the data model is a sequence of
zero or more items. An item is either a
node or an atomic value.
A node is defined in 4 Nodes and is one of seven node kinds.
An atomic value encapsulates an XML Schema atomic type
and a corresponding value of that type. They are defined in
5 Atomic Values.
A sequence is an ordered collection of nodes, atomic values, or any
mixture of nodes and atomic values. 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 6 Sequences.
Note: In XPath 1.0, the data model only
defines nodes. The primitive data types (number, boolean, string,
node-set) are part of the expression language, not
the data model.
The data model can represent various
values including not only the input and the output of a 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 a sequence of integers, dates, QNames or
other XML Schema atomic types (represented as a sequence of
atomic values), etc.
Examples of values that cannot be expressed directly by the data model
include schema components, atomic values whose type
is not an XML Schema atomic type, etc.
In this document, we provide a precise definition of how values in the
XQuery 1.0 and XPath 2.0 Data Model are constructed and accessed, and how
they relate to values in the Infoset. We note wherever the XQuery 1.0 and
XPath 2.0 Data Model differs from that of XPath 1.0.
2 Notation and Pseudo-code Syntax
In addition to using prose, we define the data model using a functional
notation. We chose this notation because it is simple and permits a
precise definition of the data model, suitable for use by the formal
semantics of XQuery. Although the notation has a functional style, we
emphasize that the data model can be realized in a variety of
programming languages and styles, for example, as object classes and
methods in an object-oriented language.
Pseudo-code syntax is highlighted as follows:
In the psuedo-code syntax, the term Node denotes
the category of node values, AtomicValue denotes the
category of atomic values, and Item refers to the
category of either node values or atomic values.
V* denotes the category of sequence
values all of whose members are in category V.
V? and V+ denote subcategories of
V*: The former denotes the category of sequences
containing zero or one items, the latter refers to sequences
containing one or more items.
In a sequence, V may be a Node or
AtomicValue, or the union (choice) of several categories of
Items. For example, the following denotes a category of
sequence containing any combination of comment and processing instruction
nodes:
There are some functions in the data model that are partial
functions. We use the occurrence indicators ? or
* when specifying the return type of such functions.
For example, a node may have one parent node or no parent.
If the node argument has a parent, the
dm:parent accessor returns a singleton sequence. If the node
argument does not have a parent, it returns the empty sequence.
The signature of dm:parent specifies that it returns
an empty sequence or a sequence containing one element or document node:
The pseudo-code syntax defines functions to construct values,
called constructors; and functions to access parts of
values, called accessors (see [Issue-0033: Unclear relationship between values passed to the constructor,
and those returned by the accessor]).
The constructors and accessors defined by the data model are prefixed
with dm
Note: The XPath 1.0 data model defines accessors, but does not
define constructors.
The term signature of a function specifies the
type of its zero or more inputs and the type of its one
output. The following signature denotes a function f that
takes values in the categories V1, ...,
Vm and returns an output value in the category
Vn.
function f(V1 $v1, ..., Vm $vm) returns Vn
A member of a particular category is a permissible argument to any
function that accepts the category, for example, a
ProcessingInstructionNode is a permissible argument to a
function expecting a Node.
This document relies on the [XML Information Set]. Information items
and properties are indicated by the styles information
item and [property], respectively.
This document also provides pseudo-code syntax describing the mapping
from the Infoset to the data model. To facilitate this we introduce accessors
to the required infoset properties through InfoItem objects.
These infoset accessors are for rhetorical purposes only and are not intended to be exposed outside this
specification. We name the accessors of the Infoset using the convention
infoset-<item-name>-<property-name>.
Similarly, accessor functions that return PSV Infoset properties use the
naming convention psvi-<item-name>-<property-name>.
For example, infoset-element-attributes is the accessor that
returns an element information item's [attributes]
property:
An InfoItem is one of eleven kinds of item: document
item, element item, attribute item, processing instruction item,
unexpanded entity item, character item, comment item, document type declaration item,
unparsed entity item, notation item, and namespace item.
The infoitem-kind accessor
returns a string value representing the information item's kind, either
"document", "element", "attribute",
"character", "namespace",
"processing-instruction", "comment",
"document-type-declaration",
"notation", or "unparsed-entity".
function infoitem-kind(InfoItem $ii) returns xs:string
Throughout this document, the namespace prefix xs indicates
the [XMLSchema Part 1] namespace name
http://www.w3.org/2001/XMLSchema.
The namespace prefixes xf and op indicate
the namespace of the functions and operators defined in
Section 1.5 "Namespace Prefix" of [XQuery 1.0 and XPath 2.0 Functions and Operators].
The following is a list of some functions and operators that are used
in this document but precisely defined in [XQuery 1.0 and XPath 2.0 Functions and Operators]:
-
op:concatenate
-
op:item-at
-
op:value-equal
-
xf:anyURI
-
xf:concat
-
xf:count
-
xf:decimal
-
xf:empty
-
xf:get-local-name
-
xf:get-namespace-uri
-
xf:NCName
-
xf:QName
-
xf:QName-from-uri
-
xf:QName-from-string
-
xf:string
-
xf:subsequence
This document frequently uses the term expanded-QName.
An expanded-QName is a pair of values consisting of a namespace URI and
a local name. They belong to the value space of the XML Schema type
xs:QName. When this document refers to xs:QName we always
mean the value space, i.e. a namespace URI, local name pair (and not
the lexical space referring to constructs of the form prefix:local-name).
3 Concepts
3.1 Node Identity
Because XML documents are tree-structured, we define the
data model using conventional terminology for trees. The data model is
a node-labeled, tree-constructor representation, but also includes a
concept of node identity. The identity of a node is established
when a node-constructor is applied to create the node: each
application of a node constructor creates a new node that is
identical to itself, and not identical to any other node
(see 4 Nodes).
The dm:node-equal function takes two nodes as arguments.
It returns true if the arguments are identical and false otherwise.
This concept should not be confused with the concept of
unique ID, which is a unique name assigned to an
element by the author to represent references using ID/IDREF
correlation.
3.2 Document Order
A document order is defined on all the nodes in a
document. The document node is the first node. Element nodes,
comment nodes, and processing instruction nodes occur in the
order of their representation in the XML (after expansion of
entities). Element nodes occur before their children. The
namespace nodes of an element immediately follow the element node
(see [Issue-0051: Document order of shared namespace nodes]).
The relative order of namespace nodes is implementation-dependent.
The attribute nodes of an element immediately follow the
namespace nodes of the element. The relative order of attribute
nodes is implementation-dependent. Reverse document order is the
reverse of document order.
The relative order of nodes in distinct documents is
implementation-dependent but stable. In other words, given
two distinct documents A and B, if a node in document A is
before a node in document B, then every node in document A
is before every node in document B.
The dm:node-before function takes two nodes as arguments.
It returns true if the first argument is before (but not identical
to) the second one in document order and false otherwise
3.3 XML Schemas and the XML Information Set
The data model is defined in terms of the
[XML Information Set] after XML Schema validity assessment.
XML Schema validity assessment is the process of assessing an XML
element information item with respect to an XML Schema and
augmenting it and some or all of its descendants with properties
that provide information about validity and type assignment.
The result of schema validity assessment is an augmented
Infoset, known as the Post Schema-Validation Infoset, or
PSVI.
The data model supports the following classes of XML documents:
-
Schema-validated documents, i.e., those validated with respect
to a schema,
-
DTD-valid documents, i.e., those documents validated with respect
to a DTD, and
-
Well-formed documents with no corresponding DTD or schema.
The data model does not support non-well-formed documents and documents
that don't conform to XML Namespaces. These are not supported by the
XML Information Set. On the other hand the data model does support
some kinds of values that are not supported by the XML Information Set.
Examples of these are well-formed document fragments, sequences of
fragments or sequences of documents. The data model also
supports values that are not nodes. Examples of these are atomic
values, 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.
Schema-validated documents include documents in which some elements
or attributes have been validated by "lax" or "skip" validation
([XMLSchema Part 2]).
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.
See [Issue-0024: Support for Schema-invalid documents].
Note: This implies accommodation for the case where
both a DTD and a schema are applied. This will probably require some
reconciliation of the [attribute type] property with type
information from the PSVI. See issue [Issue-0004: Schema/DTD].
In addition to specifying the transformation from the Post Schema
Validation Infoset (PSVI) to the data model this document also specifies
the transformation from the data model back to the XML Information Set.
This is a useful notion that can be used for defining serialization and
validation.
Serialization can be viewed as a two step process, first transforming
to the XML Infoset and then to an XML document.
Validation is described conceptually as a process of mapping the data
model to the XML Infoset followed by XML Schema validation producing
a PSVI which is then loaded into the data model.
The mapping from the data model to the Infoset is specified
via the function
The function takes a data model Node as an argument and returns
an Information Item. We define this for each data model node type
in the appropriate section below. The returned InfoItem will be
specified by having its type identified and its properties described.
The definition of dm:node-to-infoitem() will be recursive.
Furthermore we will find it convenient to use a second function
dm:nodes-to-infoitems() which takes a sequence of data
model Nodes and returns a sequence of InfoItems by applying
dm:node-to-infoitem() on each member of the sequence of
Nodes in turn and creating a sequence of the resulting InfoItems.
define function dm:nodes-to-infoitems(Node* $seq)
returns InfoItem*
{
for $node in $seq return dm:node-to-infoitem($node)
}
Editorial Note:
There is an open issue about how to map namespaces declared globally
in the query prolog during the data model to infoset transformation.
3.4 Types
The data model supports a representation of named types as
expanded-QNames.
An expanded-QName is a pair consisting of a namespace URI and a local name.
Named types include both the built-in types defined by XML Schema
Part 2 and types declared in a schema and imported by a query.
Since named types in XML Schema are global, an expanded-QName
uniquely identifies such a type, be it simple or complex:
The namespace of the expanded-QName is the target namespace
of the schema and its local name is the name of the type.
The data model does not uniquely identify anonymous types and
represents them by xs:anyType or xs:anySimpleType.
The data model associates type information with element nodes,
attribute nodes and atomic values. If this type information
is something other than xs:anyType or xs:anySimpleType, the item is
guaranteed to be a valid instance of that type as defined by XML Schema.
The data model defines an accessor dm:type() that returns
an expanded-QName corresponding to the type of the element node,
attribute node or atomic value, provided that the type is globally
declared. It returns xs:anyType or xs:anySimpleType if it is
locally declared or if no type information exists.
When no type information exists for an element or an attribute node
we frequently use the terminology "element with unknown type"
or "attribute with unknown simple type".
The data model does not represent element or attribute declaration
schema components, but it supports various type-related operations.
The semantics of such operations, e.g. checking if a particular
instance of an element node has a given type is defined in
[XQuery 1.0 Formal Semantics].
3.5 Typed Value and String Value
The content of a text, attribute, or element node can be interpreted
in either of two ways: as a string value or as a typed value.
For these types of nodes, the typed value can be extracted by the
dm:typed-value accessor, and the string value can be
extracted by the dm:string-value accessor.
The typed value of a node is a sequence of atomic values, and the
string value of a node is a string. The typed value of a node is
derived from its string value and its type in a way that is
consistent with schema validation, as described in the definitions
of the accessor functions for each kind of node.
3.6 Mapping PSV Infoset additions to Types
This section specifies how the type of an element
or attribute node is computed from the PSV Infoset additions
that specify validity and type assessment for the node's corresponding
information item.
A PSV element (attribute) information item has a
[validity] and a
[type definition] property.
The [validity] property may be
"valid", "invalid", or "notKnown"
and reflects the outcome of the element's (attribute's)
schema-validity assessment.
The [type definition]
property contains an element information item that is
isomorphic to the XML Schema type definition of the
element or attribute information item.
Roughly speaking these two properties are used to compute the
type of an element or attribute in the data model, which
corresponds to the {target namespace} and the {name}
of the [type definition]
property if [validity] is
"valid", or to xs:anyType (xs:anySimpleType) otherwise.
Notice that the only information that can be inferred from an
invalid or not known validity value is that the information
item is well-formed, therefore, we must associate some general
type information with the element or attribute node.
The precise definition of the type of an element or attribute
information item is slightly more complex due to the following
factors.
First, XML Schema only guarantees the existence of either the
[type definition] property,
or the
[type definition namespace],
[type definition name] and
[type definition anonymous]
properties.
Second, if the type definition refers to a union type, there
are further properties defined, that refer to the type definition
which actually validated the element item's normalized value.
These properties are either the
[member type definition],
or the
[member type definition namespace],
[member type definition name] and
[member type definition anonymous]
properties.
If these are available the type of an element or attribute will
refer to the member type that actually validated the schema
normalized value.
Having identified all the relevant properties we can now define
how to compute a type.
The type of an element information item is
represented by an expanded-QName whose namespace and local name corresponds
to the first applicable item in the following list:
-
xs:anyType if the [validity]
property is "invalid" or "notKnown", or
-
the {target namespace} and {name} properties of the
[member type definition]
schema component if that exists, or
-
the {target namespace} and {name} properties of the
[type definition]
schema component if that exists, or
-
the [member type definition namespace]
and the [member type definition name]
if [member type definition anonymous]
exists and is false, or
-
the [type definition namespace]
and the [type definition name]
if [type definition anonymous]
exists and is false, or
-
it corresponds to xs:anyType.
Editorial Note:
The last bullet of the above definition is currently under discussion.
It is very likely that a change will be made in a future draft to
reflect a more precise definition covering derived types and the
possible usage of generated type identifiers when no type names
available. See [Issue-0076: PSVI to Type mapping supporting derived types].
The type of an attribute information item is
represented by an expanded-QName. Its definition is the same as for
element information items except for using xs:anySimpleType
instead of xs:anyType above.
We will find it convenient to define the following function
that will be used later in various sections.
The infoitem-to-type function takes an element or
an attribute information item and returns an xs:QName that
corresponds to the type of its argument.
function infoitem-to-type((ElementItem|AttributeItem) $ii)
returns xs:QName
define function infoitem-to-type(ElementItem $ii)
returns xs:QName
{
if (psvi-element-validity($ii) ne "valid") then
return xf:QName-from-string("xs:anyType")
else if (psvi-element-member-type-definition($ii) ne ())
then
let $typedef:= psvi-element-member-type-definition($ii)
let $name:= psvi-typedefinition-name($typedef)
let $ns:= psvi-typedefinition-namespace($typedef)
return xf:QName-from-uri($ns,$name)
else if (psvi-element-type-definition($ii) ne ()) then
let $typedef:= psvi-element-type-definition($ii)
let $name:= psvi-typedefinition-name($typedef)
let $ns:= psvi-typedefinition-namespace($typedef)
return xf:QName-from-uri($ns,$name)
else if (psvi-element-member-type-definition-anonymous($ii)
eq false) then
let $name:= psvi-element-member-type-definition-name($ii)
let $ns:=
psvi-element-member-type-definition-namespace($ii)
return xf:QName-from-uri($ns,$name)
else if (psvi-element-type-definition-anonymous($ii)
eq false) then
let $name:= psvi-element-type-definition-name($ii)
let $ns:= psvi-element-type-definition-namespace($ii)
return xf:QName-from-uri($ns,$name)
else
return xf:QName-from-string("xs:anyType")
}
define function infoitem-to-type(AttributeItem $ii)
returns xs:QName
{
if (psvi-attribute-validity($ii) ne "valid") then
return xf:QName-from-string("xs:anySimpleType")
else if (psvi-attribute-member-type-definition($ii) ne ())
then
let $typedef:= psvi-attribute-member-type-definition($ii)
let $name:= psvi-typedefinition-name($typedef)
let $ns:= psvi-typedefinition-namespace($typedef)
return xf:QName-from-uri($ns,$name)
else if (psvi-attribute-type-definition(a) ne ()) then
let $typedef:= psvi-attribute-type-definition($ii)
let $name:= psvi-typedefinition-name($typedef)
let $ns:= psvi-typedefinition-namespace($typedef)
return xf:QName-from-uri($ns,$name)
else if (psvi-attribute-member-type-definition-anonymous($ii)
eq false) then
let $name:= psvi-attribute-member-type-definition-name($ii)
let $ns:=
psvi-attribute-member-type-definition-namespace($ii)
return xf:QName-from-uri($ns,$name)
else if (psvi-attribute-type-definition-anonymous($ii)
eq false) then
let $name:= psvi-attribute-type-definition-name($ii)
let $ns:= psvi-attribute-type-definition-namespace($ii)
return xf:QName-from-uri($ns,$name)
else
return xf:QName-from-string("xs:anySimpleType")
}
Editorial Note: MF:
Following two cases need to be completed:
Given information items that validate with respect to a DTD, ...
Given information items from
a well-formed document, with no corresponding DTD or Schema...
3.7 Ignoring Comments, Processing Instructions, and Whitespace
Although the data model is able to represent comments, processing
instructions, and insignificant whitespace, preservation of this information
may be unnecessary and onerous for some applications.
Construction of a document from an XML information set is
parameterized by three flags, ignore-comments,
ignore-processing-instructions, and ignore-whitespace.
If the ignore-comments flag is true, comment nodes are not
preserved in the data model. If the ignore-processing-instructions
flag is true, processing-instruction nodes are not preserved in the
data model. If the ignore-whitespace flag is true,
insignificant whitespace is not preserved.
ignore-comments : xs:boolean
ignore-processing-instructions : xs:boolean
ignore-whitespace : xs:boolean
Expressions which rely upon the presence or absence of comments,
processing instructions, or insignificant whitespace may produce different
results for two data models created from the same infoset (XML document),
when each data model is constructed with different settings of these flags.
Insignificant whitespace is defined as a text node that:
-
contains no characters other than whitespace characters
(as defined in XML 1.0), and
-
has a parent element with a [validity]
property with the value "valid", and a
[type definition] property yielding
a complex type with content-type of element-only.
4 Nodes
The category of Node values contains seven distinct
kinds of nodes: document,
element, attribute,
text, namespace,
processing instruction, and
comment. The seven kinds of nodes are
defined in the following subsections.
See [Issue-0078: Data model does not represent CDATA sections].
Each kind of node has its own constructor. The effect of a node
constructor is to create a new node with a unique identity, distinct
from all other nodes.
A set of accessors is defined on all seven kinds of Nodes. Some
accessors return a constant empty sequence on certain node kinds.
-
The dm:node-kind accessor returns a string value
representing the node's kind: either "document",
"element", "attribute", "text",
"namespace", "processing-instruction", or
"comment".
-
The dm:name accessor returns a sequence containing
one expanded QName for node kinds that can have names.
For other node kinds, it always returns an empty sequence.
An expanded QName is in the value space of xs:QName,
and consists of a namespace URI and a local name. See
[Issue-0063: Is prefix preserved?], [Issue-0070: Should the name accessor return "" or ()?].
-
The dm:base-uri accessor returns a sequence containing
zero or one uri references for node kinds that can have a base-uri
(document nodes and element nodes). For other
node kinds, it always returns the empty sequence.
-
The dm:string-value accessor returns the node's
string representation. For some kinds of nodes, this is part of
the node; for other kinds of nodes, it is computed from the
dm:string-value of its descendant nodes.
-
The dm:typed-value accessor returns a sequence of
atomic values corresponding to the node. This may be a non-empty
sequence for element, attribute and text nodes, but it is always
the empty sequence for other node kinds.
The typed value of an element or attribute node is derived from
its string value and its type in a way that is consistent with
schema validation, as described in the definitions of the accessor
functions for these kinds of nodes. See [Issue-0080: Typed value of Document, PI and Comment nodes].
-
The dm:parent accessor returns a sequence containing
zero or one nodes for node kinds that can have parents. For other
node kinds, it always returns the empty sequence.
Every node has at most one parent, which is either
an element node or the document node. A node that has no parent is
regarded as the root of a tree. The one exception is a namespace node,
which never has a parent.
Note: In XPath 1.0, Namespace nodes have parents.
-
The dm:children accessor returns a sequence containing
zero or more nodes for node kinds that can have children (document
nodes and element nodes). For other node kinds, it always returns
the empty sequence.
A document node or an element node is the parent of each of
its child nodes. Nodes never share children: if two nodes have
distinct identities, then no child of one node will be a child of
the other node.
-
The dm:attributes accessor returns a sequence containing
zero or more attribute nodes for element nodes. For other node kinds,
it always returns the empty sequence.
-
The dm:namespaces accessor returns a sequence containing
zero or more namespace nodes corresponding to the in-scope namespaces
for element nodes.
For other node kinds, it always returns the empty sequence.
-
The dm:type accessor returns a sequence containing one
expanded-QName corresponding to the type of the element node or
attribute node, provided that the type is globally declared. It
returns xs:anyType or xs:anySimpleType if it is locally declared
or if no type information exists. For other node kinds, it always
returns the empty sequence.
-
The dm:unique-ID accessor returns a sequence containing
zero or one ID for element nodes. For other node kinds,
it always returns the empty sequence.
The return types of the Node accessors are given below. Some kinds of nodes
further restrict the return types; notably, many node kinds return a
constant empty sequence for some of the accessors.
A tree contains a root plus all nodes that are reachable
directly or indirectly from the root via the dm:children,
dm:attributes, and dm:namespace 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 some other kind of
node is referred to as a fragment.
4.1 Documents
4.1.1 Overview
Document nodes encapsulate XML documents.
The information associated with a document node includes the following.
-
the base-uri of the document as an xs:anyURI
-
the children of the document as a
sequence of one or more element, zero or more processing instruction,
comment or text nodes
The above information associated with a document node is set
during construction and can be accessed later via the accessor functions.
Note: Document nodes and XPath 1.0 root nodes are essentially
identical.
In a well-formed document, the children of the document node consist
exclusively of element nodes, processing-instruction nodes, and comment
nodes, and exactly one of these children is an element node. A document
node in the data model is more permissive: it permits more than one
element node as a child and also permits text nodes as children.
See
[Issue-0074: Do we need Document fragments].
4.1.2 Constructor
A document node can be constructed using dm:document-node.
The constructor takes a base URI value and a non-empty sequence of
children nodes as arguments.
Like all other node constructors, the document-node constructor has the
effect of creating a new node with a unique identity, distinct from all
other nodes.
4.1.3 Accessors
The accessors dm:base-uri and dm:children
return the values passed to the constructor as arguments.
The accessor dm:node-kind returns the string "document".
The accessor dm:string-value returns the string-value
of the document which is defined to be the concatenation of the
string-values of all text-node descendants of the document node in
document order.
The accessors dm:name, dm:typed-value,
dm:parent, dm:attributes,
dm:namespaces,
dm:type and dm:unique-ID
applied to a document node always return the empty sequence.
4.1.4 PSVI to Datamodel Mapping
When a data model fragment is created from the PSVI a
document information item is mapped
to a Document Node. The precise transformation is described
by specifying the PSVI property corresponding to each argument
of the document node constructor.
The base-uri argument
corresponds to the
[base URI] property.
The children argument
corresponds to the information items found in the
[children] property, omitting
any document type declaration information
items.
A document node is constructed from a Document Information
Item by the infoitem-to-document-node function:
The collapse-text-nodes
function synthesizes a single text node from multiple text nodes. The
sequence-map function
applies its first function argument to each member of its second
sequence argument and returns a new sequence containing the result
of applying the function to each member of the sequence. In the pseudo-code
above, infoitem-to-node is applied to each child of the
document information item$ii and a new sequence of children nodes is constructed,
each of which is a Node. The constructor
dm:document-node constructs the document node in the data
model.
function sequence-map(function $map, Item* $seq)
returns Item*
The infoitem-to-node function maps an information item
to a sequence of zero or one node.
4.1.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps a
Document Node to a document information item.
Given a Document Node $n, the properties of the corresponding
document information item are specified
as follows:
| Document Information Item properties |
|
| [children] |
dm:nodes-to-infoitems(dm:children($n)) |
| [notations] |
() |
| [unparsed entities] |
() |
| [base URI] |
dm:base-uri($n) |
The values of the properties
[character encoding scheme],
[standalone],
[version] and
[all declarations processed]
are implementation-defined but must be consistent with the rest of
the InfoItem properties.
Since Document Nodes are permissive, (for instance allow zero or
more than one element node children or allow text node children)
the mapping via dm:node-to-infoitem() may not produce a valid InfoSet.
4.2 Elements
4.2.1 Overview
Element nodes encapsulate XML elements.
The information associated with an element node includes the following.
-
the expanded-QName of the element as an xs:QName
-
the base-uri of the element as an xs:anyURI
-
the type of the element as an xs:QName
-
the children of the element as a sequence of zero or more element, processing instruction, comment or text nodes
-
the parent of the element as a sequence of zero or one element or document node
-
the attributes of the element as a sequence of zero or more attribute nodes
-
the namespaces of the element as a sequence of zero or more namespace nodes
-
the unique ID of the element (if any) as a sequence of zero or one xs:ID
The above information associated with an element node is set
during construction and can be accessed later via the accessor functions.
Element nodes must satisfy the following constraints.
-
An element node's children may not contain two consecutive text
nodes. Consecutive text nodes are collapsed by the
element constructor into one text node. The string value of the text
node is the concatenation of the string values of the consecutive text
nodes.
-
The parent of any child of an element must be the element itself
and any element that has a parent must be among its parent's children.
-
The attributes of an element must have distinct names.
-
The namespaces of an element must have distinct prefixes.
Due to the definition of the element node constructor the first two
constraints above are automatically satisfied .
4.2.2 Constructor
An element node can be constructed using dm:element-node.
The constructor takes an expanded-QName,
a sequence of namespace nodes, a sequence of attribute nodes, a
sequence of child nodes, and the node's type as arguments.
Like all other node constructors, the element node
constructor has the effect of creating a new node with a unique
identity, distinct from all other nodes.
If consecutive text nodes are specified as the children of an element
node they are collapsed into one text node whose string value is the
concatenation of the string values of the consecutive text nodes.
To guarantee that the parent-child relationship is invertible,
(i.e. that the parent of any child of a node is itself and that any
node that has a parent is among its parent's children),
the element constructors logically create a copy of all of their
namespace, attribute, and children arguments and set the parent property
of these nodes to the newly created element node. As long as the parent-child
constraint is satisfied, an implementation of the data model may choose to
use specialized techniques to avoid creating physical copies of the
arguments to an element constructor. See [Issue-0052: Element constructor copies nodes?].
The data model permits element nodes without parents.
In fact element nodes created by the element node constructor never
have parents unless they are enclosed in other node constructors.
Such nodes may represent partial results during expression processing.
4.2.3 Accessors
The accessors return information associated with an element node.
Some accessors simply return the values that were passed in as
arguments to the constructor, while others return values that are
derived from the information associated with the element node.
The accessors dm:name, dm:namespaces,
dm:attributes, dm:children and
dm:type are examples of the former kind.
The accessor dm:node-kind returns the string constant "element".
The accessor dm:parent returns a sequence containing zero
or one nodes representing the parent of the element node.
The accessor dm:base-uri returns a sequence containing zero
or one uri references representing the base URI of the element node.
The accessor dm:unique-ID returns a sequence containing
the unique ID of the element if it has one; otherwise, it returns
the empty sequence.
The accessor dm:string-value returns the string-value
of the element which is defined to be the concatenation
of the string-values of all text-node descendants of the element node in
document order.
Editorial Note:
Note that the dm:string-value($n) and dm:string-value(dm:typed-value($n))
may give different results under this definition.
The issue of whether to allow or possibly mandate dm:string-value to
return the same result as the string-value of the typed value is still
under discussion. See [Issue-0079: String-value vs. string-value of the typed-value].
The accessor function dm:typed-value returns the typed-value
of the node, which is a sequence of zero or more atomic values.
The typed-value is closely related to the node's string-value and its
type. For instance when the node's string-value is "3.14" and its type
is xs:decimal the typed-value is a sequence containing the
atomic value 3.14 of type decimal.
In fact, when the type is an atomic type, typed-value is the
atomic-value constructed from the string-value and the type.
In the general case typed-value is defined via the function
dm:atomic-value-sequence, which constructs a sequence
of atomic values from a string and a type, in such a way to
be consistent with validation.
It is noted that when the element node's type is xs:anyType then
dm:typed-value returns the node's string-value as xs:anySimpleType.
If the type is a complex type with complex content
then invoking dm:typed-value raises an error.
4.2.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI an
element information item is mapped
to an Element Node. The precise transformation is described
by specifying the PSVI property corresponding to each argument
of the element node constructor.
The expanded-QName of the element
is obtained as follows.
Its local part corresponds to the
[local name] property.
Its namespace URI corresponds to the
[namespace name] property.
The children of the element node
correspond to the following:
-
A single text node whose string-value is the
[schema normalized value]
PSVI property if that exists, or
-
The element, comment, processing instruction, and
character information items appearing in the
[children] property with consecutive
character information item children
being coalesced into a single text node.
Because the data model requires
that all general entities be expanded, there will never be
unexpanded entity reference information item
children.
See [Issue-0073: Whitespace normalization of the string-value of elements with simple content].
The attributes of the element node
are nodes corresponding to attribute information
items appearing in the
[attributes] property.
See [Issue-0071: Magic Attributes].
The namespaces of the element node
are nodes
corresponding to namespace information items
appearing in the [in-scope namespaces]
property.
See [Issue-0062: Namespace fixups required].
The type of an element is an
expanded-QName whose namespace and local name is computed as described
in 3.6 Mapping PSV Infoset additions to Types.
It is noted that if the type referenced would be a union type then
type refers to the member type that actually validated the
schema normalized value.
See [Issue-0064: Including type definition in element constructors].
For an element in a well-formed document with no associated schema,
type corresponds to xs:anyType. Consequently the typed-value of such an
element is its string value as an instance of xs:anySimpleType.
The unique ID of the element node
is an identifier optionally assigned by the user. It corresponds to the
[normalized value] property
of the attribute information item
in the [attributes]
property that has a type ID, if one exists.
Editorial Note:
Need to make it clearer how the unique ID works given that the
constructor has no unique ID argument.
An element node is constructed from an
element information item by the
infoitem-to-element-node function:
define function infoitem-to-element-node(ElementItem $ii)
returns ElementNode
{
let $qname:= xf:QName-from-uri(
infoset-element-namespace-name($ii),
infoset-element-local-name($ii)) ,
$nsnodes:= sequence-map(
infoitem-to-namespace-node,
infoset-element-in-scope-namespaces($ii)) ,
$attrnodes:= sequence-map(
infoitem-to-attribute-node,
infoset-element-attributes($ii)) ,
$kids:= collapse-text-nodes(sequence-map(
infoitem-to-node,
infoset-element-children($ii))) ,
$type:= infoitem-to-type($ii)
return dm:element-node(
$qname, $nsnodes, $attrnodes, $kids, $type)
}
4.2.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps an
Element Node to an element information item.
Given an Element Node $n, the properties of the corresponding
element information item are specified
as follows:
| Element Information Item properties |
|
| [namespace name] |
xf:get-namespace-uri(dm:name($n)) |
| [local name] |
xf:get-local-name(dm:name($n)) |
| [prefix] |
get-namespace-prefix(xf:get-namespace-uri(dm:name($n))) |
| [children] |
dm:nodes-to-infoitems(dm:children($n)) |
| [attributes] |
dm:nodes-to-infoitems(dm:attributes($n)) |
| [in-scope namespaces] |
dm:nodes-to-infoitems(dm:namespaces($n)) |
| [base URI] |
dm:base-uri($n) |
| [parent] |
dm:nodes-to-infoitems(dm:parent($n)) |
Editorial Note:
The get-namespace-prefix() function is not yet defined.
The value of the property
[namespace attributes]
is computed based on the difference of the namespaces of this
element node and its parent's. This property contains a namespace
attribute information item for each namespace that occurs in
dm:namespaces($n), but not in
dm:namespaces(dm:parent($n)).
In addition, this property also contains a namespace
attribute information item corresponding to xmlns="",
if dm:namespaces(dm:parent($n)) contains a namespace
node for the empty prefix, but dm:namespaces($n) does not.
4.3 Attributes
4.3.1 Overview
Attribute nodes encapsulate XML attributes.
The information associated with an attribute node includes the following.
-
the expanded-QName of the attribute as an xs:QName
-
the string-value of the attribute as an xs:string
-
the type of the attribute as an xs:QName
-
the parent of the attribute as a sequence of zero or one element node
The above information associated with an attribute node is set
during construction and can be accessed later via the accessor functions.
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.
4.3.2 Constructor
An attribute node can be constructed using
dm:attribute-node. The constructor takes the attribute's
expanded-QName, string value and type.
Like all other node constructors, the attribute node
constructor has the effect of creating a new node with a unique
identity, distinct from all other nodes.
4.3.3 Accessors
The accessors dm:name, dm:string-value
and dm:type return the values passed to the constructor
as arguments.
Editorial Note:
Note that the dm:string-value($n) and dm:string-value(dm:typed-value($n))
may give different results under this definition.
The issue of whether to allow or possibly mandate dm:string-value to
return the same result as the string-value of the typed-value is still
under discussion. See [Issue-0079: String-value vs. string-value of the typed-value].
The accessor dm:node-kind returns the string constant
"attribute".
The accessor dm:parent returns a sequence containing zero
or one element nodes representing the parent of the attribute node.
The accessor function dm:typed-value returns the typed-value
of the node, which is a sequence of zero or more atomic values.
The typed-value is closely related to the node's string-value and its
type. It is defined via the function
dm:atomic-value-sequence, which constructs a sequence
of atomic values from a string and a type, in such a way to
be consistent with validation.
In particular when the type is an atomic type, typed-value is the
atomic-value constructed from the string-value and the type.
When the type of the attribute is xs:anySimpleType
then dm:typed-value returns its string value as
xs:anySimpleType.
The accessors dm:base-uri, dm:attributes,
dm:children, dm:namespaces and
dm:unique-ID
applied to an attribute node always return the empty sequence.
4.3.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI an
attribute information item is mapped
to an Attribute Node. The precise transformation is described
by specifying the PSVI property corresponding to each argument
of the attribute node constructor.
The expanded-QName of the
attribute is obtained as follows.
Its local part corresponds to the
[local name] property.
Its namespace URI corresponds to the
[namespace name] property.
The string value of the attribute
node corresponds to the following:
The type of an attribute is an
expanded-QName whose namespace and local name is computed as described
in 3.6 Mapping PSV Infoset additions to Types.
It is noted that if the type referenced would be a union type then
type refers to the member type that actually validated the
schema normalized value.
For an attribute in a well-formed document with no associated schema,
type corresponds to xs:anySimpleType. Consequently the typed-value of such
an attribute is its string value as an instance of xs:anySimpleType.
An attribute node is constructed from an
attribute information item
by the infoitem-to-attribute-node function:
define function infoitem-to-attribute-node(AttributeItem $ii)
returns AttributeNode
{
let $qname:= xf:QName-from-uri(
infoset-attribute-namespace-name($ii),
infoset-attribute-local-name($ii)),
$type:= infoitem-to-type($ii)
return dm:attribute-node($qname,
infoset-attribute-normalized-value($ii), $type)
}
Editorial Note: JM: Update the above to accommodate the possibility of
schema-less and DTD validation.
4.3.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps an
Attribute Node to an attribute information item.
Given an Attribute Node $n, the properties of the corresponding
attribute information item are specified
as follows:
| Attribute Information Item properties |
|
| [namespace name] |
xf:get-namespace-uri(dm:name($n)) |
| [local name] |
xf:get-local-name(dm:name($n)) |
| [prefix] |
get-namespace-prefix(xf:get-namespace-uri(dm:name($n))) |
| [normalized value] |
dm:string-value($n) |
| [owner element] |
dm:nodes-to-infoitems(dm:parent($n)) |
Editorial Note:
The get-namespace-prefix() function is not yet defined.
The values of the properties
[specified],
[attribute type] and
[references]
are implementation-defined.
4.4 Namespaces
4.4.1 Overview
Namespace nodes encapsulate XML namespaces.
The information associated with a namespace node includes the following.
The above information associated with a namespace node is set
during construction and can be accessed later via the accessor functions.
Each element node has an associated set of namespace nodes
corresponding to its in-scope namespaces.
A namespace node has no parent.
4.4.2 Constructor
A namespace node has the constructor
dm:namespace-node, which takes a namespace prefix and
the absolute URI of the namespace being declared. The namespace prefix may
be the empty sequence. If the URI is the zero-length string, the prefix must
be the empty sequence.
Like all other node constructors, the namespace node
constructor has the effect of creating a new node with a unique identity,
distinct from all other nodes.
4.4.3 Accessors
The accessor dm:name returns the namespace prefix
as the local-part of an xs:QName (whose namespace URI is the empty sequence).
The accessor dm:string-value returns the namespace uri as
an xs:string.
The accessor dm:node-kind returns the string constant
"namespace".
The accessors dm:base-uri, dm:typed-value,
dm:parent, dm:children, dm:attributes,
dm:namespaces, dm:type and
dm:unique-ID applied to a namespace node always return the empty
sequence.
4.4.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI a
namespace information item is mapped
to a Namespace Node. The precise transformation is described
by specifying the PSVI property corresponding to each argument
of the attribute node constructor.
The prefix argument
corresponds to the [prefix] property.
The uri argument corresponds
to the [namespace name] property.
A namespace node is constructed from a
namespace information item by the
infoitem-to-namespace-node function:
4.4.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps a
Namespace Node to a namespace information item.
Given a Namespace Node $n, the properties of the corresponding
namespace information item are specified
as follows:
| Namespace Information Item properties |
|
| [prefix] |
xf:get-local-name(dm:name($n)) |
| [namespace name] |
dm:string-value($n) |
4.5 Processing Instructions
4.5.1 Overview
Processing instruction nodes encapsulate XML processing instructions.
The information associated with a processing instruction node includes
the following.
-
the target of the processing instruction as an xs:NCName
-
the content of the processing instruction as an xs:string
-
the parent of the processing instruction as a sequence of zero or one element or document node
The above information associated with a processing instruction node is set
during construction and can be accessed later via the accessor functions.
The string '?>' may not occur within a processing instruction's
target value ([XML Recommendation]).
4.5.2 Constructor
A processing-instruction node has the constructor
dm:processing-instruction-node, which takes an NCName
representing the target and a string representing the content. Like
all other node constructors, the processing node constructor has the
effect of creating a new node with a unique identity, distinct from
all other nodes.
4.5.3 Accessors
The accessor dm:name returns the target of the
processing instruction as the local-part of an xs:QName (whose namespace
URI is the empty sequence).
The accessor dm:string-value returns the content of the
processing instruction as an xs:string.
The accessor dm:node-kind returns the string constant
"processing-instruction".
The accessor dm:parent returns a sequence containing zero
or one element or document node representing the parent of the
processing instruction node.
The accessors dm:base-uri, dm:typed-value,
dm:children, dm:attributes, dm:namespaces,
dm:type and dm:unique-ID
applied to a processing-instruction node always return the empty sequence.
4.5.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI a
processing instruction information item
is mapped to a Processing Instruction Node. The precise transformation
is described by specifying the PSVI property corresponding to each
argument of the processing instruction node constructor.
There are no processing instruction nodes for processing instructions
that are children of a
document type declaration information item.
The target argument of the
processing instruction constructor corresponds
to the [target] property.
The content argument
corresponds to the [content]
property.
A processing-instruction node is constructed from an
processing instruction information item
by the infoitem-to-processing-instruction-node function:
4.5.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps a
Processing Instruction Node to a
processing instruction information item.
Given a Processing Instruction Node $n, the properties of the corresponding
processing instruction information item
are specified as follows:
| Processing Instruction Information Item properties |
|
| [target] |
xf:get-local-name(dm:name($n)) |
| [content] |
dm:string-value($n) |
| [base URI] |
dm:base-uri(dm:parent($n)) |
| [notation] |
unknown
|
| [parent] |
dm:nodes-to-infoitems(dm:parent($n)) |
4.6 Comments
4.6.1 Overview
Comment nodes encapsulate XML comments.
The information associated with a comment node includes
the following.
The above information associated with a comment node is set
during construction and can be accessed later via the accessor functions.
The string "--" (double-hyphen) must not occur within a comment's
string value ([XML Recommendation]).
4.6.3 Accessors
The accessor dm:string-value return the value passed to
the constructor as the argument.
The accessor dm:node-kind returns the string constant
"comment".
The accessor dm:parent returns a sequence containing zero
or one element or document node representing the parent of the
comment node.
The accessors dm:name, dm:base-uri,
dm:typed-value, dm:children,
dm:attributes,
dm:namespaces, dm:type and
dm:unique-ID applied to a comment node always return the empty
sequence.
4.6.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI a
comment information item
is mapped to a Comment Node. The precise transformation
is described by specifying the PSVI property corresponding to the
argument of the comment node constructor.
There are no comment nodes for comments that are children of a
document type declaration information item.
The content argument of the
comment constructor
corresponds to the [content]
property.
A comment node is constructed from a
comment information item
by the infoitem-to-comment-node function:
4.6.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps a
Comment Node to a comment information item.
Given a Comment Node $n, the properties of the corresponding
comment information item are specified
as follows:
| Comment Information Item properties |
|
| [content] |
dm:string-value($n) |
| [parent] |
dm:nodes-to-infoitems(dm:parent($n)) |
4.7 Text
4.7.1 Overview
Text nodes encapsulate consecutive XML character data.
The information associated with a text node includes the following.
The above information associated with a text node is set
during construction and can be accessed later via the accessor functions.
Text nodes must satisfy the following constraints.
-
A text node cannot contain the empty string as its content.
-
Two consecutive text nodes can never occur as children of a node.
4.7.2 Constructor
A text node has the constructor dm:text-node
and takes a string value. Like all other node constructors, the text
constructor has the effect of creating a new node with a unique identity,
distinct from all other nodes.
4.7.3 Accessors
The accessor dm:string-value return the value passed to
the constructor as the argument.
The dm:typed-value accessor returns the string-value
of the text node as xs:anySimpleType.
The accessor dm:node-kind returns the string constant
"text".
The accessor dm:parent returns a sequence containing zero
or one element or document node representing the parent of the
comment node.
The accessors dm:name, dm:base-uri,
dm:children, dm:attributes,
dm:namespaces, dm:type and
dm:unique-ID applied to a text node always return the empty
sequence.
4.7.4 PSVI to Data Model Mapping
When a data model fragment is created from the PSVI a
sequence of one or more consecutive
character information items
are mapped to a Text Node.
As much character data as possible is grouped into each text node:
a text node never has an immediately following or preceding sibling
that is a text node.
The precise transformation
is described by specifying the PSVI property corresponding to the
argument of the comment node constructor.
The content argument of the
text node is the character data, which corresponds to the concatenated
[character code] properties of
each of the character information items.
The mapping from character information items to text nodes occurs
in the infoitem-to-element-node
function. The infoset-character-code accessor maps a
character information item to the ISO 10646 character code (in the
range 0 to #x10FFFF, though not every value in this range is a legal
XML character code) of the character.
The function infoitem-to-single-character-text-node takes one character
information item and maps it to a text node with a string value of
length one.
define function infoitem-to-single-character-text-node(
CharacterItem $ii)
returns TextNode
{
{-- convert character code to string of length 1 --}
return dm:text-node(
code2string(infoset-character-code($ii)))
}
Editorial Note: JM: need a definition or description of code2string.
The collapse-text-nodes function synthesizes a single text
node from multiple text nodes. It calls infoitem-to-text-nodes
to collapse recursively one or more consecutive text nodes in its argument
sequence. If insignificant whitespace is ignored, any text node containing
only whitespace is eliminated. All other nodes are returned unchanged.
define function collapse-text-nodes(Node* $nodes)
returns Node*
{
let $newnodes:= infoitem-to-text-nodes($nodes)
return
if (ignore-whitespace) then
sequence-map(delete-whitespace-node, $newnodes)
else $newnodes
}
define function infoitem-to-text-nodes(Node* $nodes)
returns Node*
{
if (xf:empty($nodes)) then return empty-sequence()
else
let $head:= op:item-at($nodes, 1),
$tail:= xf:subsequence($nodes, 2)
return
if (dm:node-kind($head) = "text") then
/* Collapse two consecutive text nodes and apply
infoitem-to-text-nodes recursively */
if (xf:empty($tail)) then $head
else if (dm:node-kind(op:item-at($tail,1))="text") then
infoitem-to-text-nodes(
op:concatenate(
dm:text-node(xf:concat(dm:string-value($head),
dm:string-value(op:item-at($tail,1)))),
xf:subsequence($tail, 2)
)
)
else op:concatenate($head,
op:concatenate(op:item-at($tail,1),
infoitem-to-text-nodes($tail)))
else op:concatenate($head, infoitem-to-text-nodes($tail))
}
Editorial Note: JM: need a definition or description of delete-whitespace-node.
4.7.5 Data Model to Infoset Mapping
The mapping of the data model to the XML Information Set maps a Text Node
to a sequence of character information items.
Given a Text Node $n, the properties of the ithcharacter information items in the
sequence are specified as follows
(for $i = 1, 2, ..., xf:string-length(dm:string-value())):
| Character Information Item properties |
|
| [character code] |
The ISO 10646 character code corresponding to
xf:substring(dm:string-value($n),$i,1) |
| [element content whitespace] |
A boolean indicating whether the Text Node consists entirely
of white space.
|
| [parent] |
dm:nodes-to-infoitems(dm:parent($n)) |
5 Atomic Values
[Definition:
An atomic value is a value in the value space
of an XML Schema atomic type labeled with that corresponding
atomic type or it is a string labeled with xs:anySimpleType.
The type xs:anySimpleType marks a value that has been
returned as the typed value of a node whose type is unknown
(for instance because it hasn't been validated).
]
An XMLSchema atomic type [XMLSchema Part 2] may be
primitive or derived.
The primitive atomic types are named:
xs:string,
xs:boolean,
xs:decimal,
xs:float,
xs:double,
xs:duration,
xs:dateTime,
xs:time,
xs:date,
xs:gYearMonth,
xs:gYear,
xs:gMonthDay,
xs:gDay,
xs:gMonth,
xs:hexBinary,
xs:base64Binary,
xs:anyURI,
xs:QName,
xs:NOTATION.
A derived atomic type is derived by restriction and has a primitive
base type and a set of constraining facets.
It is noted that the value space of the atomic values is the
union of the value spaces of the nineteen primitive XML Schema types.
This value space clearly includes those atomic values whose type is
primitive, but it also includes those whose type is derived, as
derivation by restriction always limits the value space.
An XMLSchema simple type [XMLSchema Part 2] may be also
primitive or derived with the method of
derivation being restriction, list or
union.
The atomic types are exactly those types where the derivation method
is restriction only and not list or union. Values corresponding
to such types are represented by atomic values.
XML Schema simple types can be derived by list. Values corresponding
to such types are represented by a sequence of atomic values
whose type is the item type.
XML Schema simple types can be derived by union. Values corresponding
to such types lose the union type information and store one of
the individual types.
An atomic value can be constructed from its lexical representation.
dm:atomic-value takes a string and a
corresponding atomic type and constructs an atomic value in such a
way to be consistent with validation.
In particular the construction takes into
consideration the facets of the type. If the string does not
represent a valid value of the type an error is raised.
When xs:anySimpleType is specified as the type no
validation takes place.
The details of the construction are described in the "Constructor
Functions" and the related "Casting Functions" section of
[XQuery 1.0 and XPath 2.0 Functions and Operators].
This constructor corresponds very closely to the atomic
value constructors specified in [XQuery 1.0 and XPath 2.0 Functions and Operators].
Each of those constructors takes a string in the lexical space of the
given primitive type and returns the corresponding atomic value.
For example, the constructor
xf:decimal(xs:string)
constructs an atomic value of type xs:decimal from a string.
Analogous constructors exist for the other XML Schema primitive types.
Since the above constructor can only be used with atomic
types we define a second one that works with more general types.
The constructor dm:atomic-value-sequence takes a string
and a corresponding type and creates a sequence of atomic values.
The derivation of the sequence of atomic values from the string
and the type is consistent with validation. If the string does not
represent a valid value of the type an error is raised.
Examples of using the constructor include the following.
-
dm:atomic-value-sequence("3.14",xs:decimal)
creates a singleton sequence containing the decimal 3.14.
-
dm:atomic-value-sequence("7 8 9",myns:HatSizeList)
creates a sequence containing the three values 7,8,9 each of type
myns:HatSize; assuming that myns:HatSizeList is defined to be a list
type with the item type being myns:HatSize, which in turn is derived
from xs:integer.
-
dm:atomic-value-sequence("bar baz faz",xs:IDREFS)
creates a sequence containing the three atomic values "bar","baz",
"faz" each of type xs:IDREF.
-
dm:atomic-value-sequence("1 2 3",xs:anySimpleType)
creates a singleton sequence containing "1 2 3" of type xs:anySimpleType
-
dm:atomic-value-sequence("1 2 3",xs:anyType)
creates a singleton sequence containing "1 2 3" of type xs:anySimpleType
If an atomic type is used as the argument to dm:atomic-value-sequence
it constructs the same atomic value as dm:atomic-value.
When a list type is used with dm:atomic-value-sequence the resulting
sequence will contain atomic values whose type is the item type of the
list type.
In particular when any of the types xs:IDREFS, xs:NMTOKENS or xs:ENTITIES
are used as arguments, the resulting sequence will contain atomic values
whose type is xs:IDREF, xs:NMTOKEN or xs:ENTITY respectively.
Using xs:anySimpleType as the argument signals that the type information
is not known. This happens when the typed-value of an unvalidated
attribute is accessed.
Using xs:anyType as the argument results an atomic value of type
xs:anySimpleType. This happens when the typed-value of an unvalidated
element is accessed.
If a complex type with complex content is used to invoke the constructor
an error is raised.
The accessor dm:type returns an atomic value's type.
The accessor dm:string-value can be used to recover a
lexical representation of the atomic value.
The details of converting an atomic value to its
string representation are described in the "Casting Functions"
section of [XQuery 1.0 and XPath 2.0 Functions and Operators].
In particular if the atomic value's type is primitive,
dm:string-value returns the
atomic value's canonical lexical representation for that primitive
type as specified in [XMLSchema Part 2].
If the atomic value's type is derived, the lexical representation
depends on whether a value is supplied for the type's pattern facet:
If no such value is supplied dm:string-value returns the
atomic value's canonical lexical representation for the base type
(which is a primitive type). Otherwise dm:string-value
returns a lexical representation that matches the value specified
for the pattern facet. (This case includes xs:integers.)
See [Issue-0072: Lexical representation of Schema primitive types].
Note: Using the canonical lexical representation for atomic values
as described above may not always be compatible with XPath 1.0.
Note that the data model does not currently represent
key values and key reference values as described in XML Schema Part 1 :
Structures [XMLSchema Part 1]. In a future draft of this
document, keys and key references may be represented in the data
model (see [Issue-0032: Keys and key references not represented]).
6 Sequences
A sequence is an ordered collection of zero or more
items. An item may be a node or an atomic value, i.e.
a sequence may contain nodes, atomic values, or any mixture of
nodes and atomic values (see [Issue-0035: Eliminate heterogeneous sequences]).
When a node is added to a sequence its identity remains the same.
Consequently one node may be contained in more than one sequence
and a sequence may contain duplicate items.
Unlike conventional lists, sequences are "flat", i.e., sequences may not
contain other sequences.
An important characteristic of the data model is that there is no
distinction between an item (i.e., a node or an atomic value) and a
singleton sequence containing that item, i.e., an item is
equivalent to a singleton sequence containing that item and vice
versa.
Note: Sequences replace node-sets from XPath 1.0. In XPath 1.0,
node-sets do not contain duplicates. In generalizing node-sets to
sequences in XPath 2.0, duplicate removal is provided by functions
on node sequences.
A collection of documents is represented in the data model as a
sequence of document nodes (see [Issue-0023: Support for document repositories]).
A sequence has no identity. Equality comparison of sequences is
performed only by comparing the items of the sequences.
The constructor empty-sequence constructs the empty
sequence. The n-ary op:concatenate constructor creates a
new sequence containing the values in its first argument followed by
the concatenated values of its second through final arguments.
In the function signatures below Item refers to a
nodes or an atomic value.
Since an item is equivalent to a singleton sequence containing the
item, op:concatenate may be applied to items.
function empty-sequence() returns Item*
function op:concatenate(Item*, ..., Item*) returns Item*
A sequence has several accessors. They are defined in [XQuery 1.0 and XPath 2.0 Functions and Operators].
In this document the following four accessors are used.
The empty accessor returns a boolean indicating whether or
not the specified sequence is empty.
The item-at accessor returns the item in the sequence that
is located at the specified index.
The subsequence accessor returns the contiguous sequence of items
beginning at the specified position and continuing to the end of the
sequence.
The count function returns the number of items in the sequence.
function empty(Item*) returns xs:boolean
function item-at(Item*,xs:decimal) returns Item
function subsequence(Item*,xs:decimal) returns Item*
function count(Item*) returns xs:unsignedInt
