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, SimpleValue denotes the
category of simple values, and Sequence<V> denotes
the category of sequence values whose members are in category
V. A UnitValue refers to a node or a
simple value. In a sequence, V may be any Node
or SimpleValue, or the union (choice) of several
unit values. For example, the following denotes a sequence containing
comment or processing instruction nodes:
Sequence<CommentNode | ProcessingInstructionNode>
There are some functions in the data model that are partial
functions, for example, a node may have one parent node or no
parent. We use bounded sequences,
Sequence(m,n)<V>, to denote a sequence of at least
m and at most nV values.
The unbounded sequence Sequence<V> is
equivalent to Sequence(0,*)<V>, where *
denotes unbounded. For example, the parent accessor
returns a singleton sequence, if its node argument has a parent,
or the empty sequence, if its argument has no parent.
The signature of parent specifies that it returns
an empty sequence or a sequence containing one element or document node:
parent : Node -> Sequence(0,1)<ElementNode | DocumentNode>
A SchemaComponent denotes the category of
schema-component values.
The pseudo-code syntax defines functions to construct values,
called constructors; and functions to access parts of
values, called accessors.
Note: The XPath 1.0 data model defines accessors, but does not
define constructors.
The term signature of a
function specifies the value category of its zero or more inputs
and the value category 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.
f : (V1, ..., Vm) -> 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.
In the pseudo-code syntax describing the mapping from the
Infoset to the data model, we name accessors of the Infoset
using the convention infoset-<item-name>-<property>. For example,
infoset-elem-attributes is the accessor that returns an
element item's attributes property:
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. Node identity simplifies the representation
of XML reference values, e.g., IDREF, XPointer, and URI values.
Two nodes have the same identity if only if they were created by the
same application of a node constructor (see 4 Nodes).
3.2 Document Order
A document order is defined on all the nodes in a
document. It corresponds to the order in which the first
character of the XML representation of each node occurs in the XML
representation of the document after expansion of general
entities. Thus, the document node is the first node. Element
nodes occur before their children. Thus, document order means that
element nodes occur in the order of their start-tag in the
XML (after expansion of entities). The namespace nodes of an
element occur before its attribute nodes, and the
element's attribute nodes occur before its children.
The relative order of namespace nodes and the relative order of
attribute nodes are 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, if n1 and n2 are in
one document, and m is in a different document, then
either 'n1 before m' is true
or 'm before n2' is true,
but both may not be true.
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. We use the naming convention convention
psvi-<item-name>-<property> to identify
the accessor functions that return the PSV Infoset additions.
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 XML documents, nor
documents that otherwise don't have an XML Information Set; for
example, that don't conform to XML Namespaces.
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. 8 Schema Components specifies how such documents are represented in
the data model.
Editorial Note: JM: 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.
3.4 Schema Components and Values
The [XML Schema: Formal Description] (henceforth "XSFD") is a formal, declarative system for
describing and naming XML Schema information, specifying XML
instance type information, and validating instances against
schemas. XSFD includes a component model that defines four
schema components (simple type
, complex type, element, and
attribute), and
it defines the mapping from the XML Schema component model to the XSFD
model. In addition, it specifies "normalized, universal" names
for all components of an XML Schema, so that they can be uniquely
identified by URIs.
The data model provides a representation for schema components,
which are used to represent the types of values.
All simple values, element nodes, and attribute
nodes have an associated schema component. We use the term
SchemaComponent to collectively refer to the data
model's
schema component values simple-type-definition, complex-type-definition,
element-declaration, and
attribute-declaration. The
accessors for schema components are defined in 8 Schema Components.
The schema component of element and
attribute nodes is derived from the PSV Infoset additions of
the nodes' corresponding element and attribute information items.
A schema simple type consists of a lexical space,
a value space, and a set of facets [XMLSchema Part 2].
A simple type is either primitive (e.g., xs:string,
xs:boolean, xs:float, xs:double, xs:ID, xs:IDREF) or
derived (e.g., xs:language, xs:NMTOKEN,
xs:long, etc., or user defined). We say a simple value is
an instance of a schema simple type if the simple value is
in the value space of the simple type. Because the value spaces of
schema simple types may overlap, a simple value may be an instance
of more than one schema simple type, e.g., an instance of
xs:integer is also an instance of a xs:long.
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.
A schema complex type defines the permissible
structure and content of an element [XMLSchema Part 1].
A schema attribute declaration specifies an
attribute's name and the simple type of its value.
A schema element declaration specifies an
element's name and the simple or complex type of its content.
3.5 Text Nodes and Simple-Typed Values
The data model supports two representations of the character data in
an XML document: text nodes and simple-typed values. An element node,
for example, has child nodes that may include text nodes, comment
nodes, processing instruction nodes, and other element nodes. A text
node contains a string of consecutive character data items and is
never followed or preceded by another text node. In addition, the
text content of an element may be interpreted as a simple-typed value,
such as an integer, a date, or a sequence of prices. To illustrate,
consider an element node whose complex type is a sequence of
double-precision numbers. The element's children are three nodes: a
text node with string contents " 12.00 ", followed by a comment node,
followed by a text node with contents " 13.0", whereas its
simple-typed value is a sequence containing the double-precision numbers
12.0 and 13.0.
We note that the data model logically supports both
text nodes and simple-typed values,
but it does not specify they should be implemented.
An implementation might choose
to only store simple-typed values and reconstruct text nodes on
demand, vice versa.
We note, however, that a simple-typed value
does not always have
a unique lexical representation ([Issue-0027: Lexical representation of simple-typed values]).
3.6 Ignoring Comments, Processing Instructions, and Whitespace
Although the data model can preserve all comments, processing
instructions, and whitespace characters in the Infoset, preservation of
these values may be unnecessary and onerous for some applications.
The data model is parameterized by three flags, ignore-comments,
ignore-processing-instructions, and ignore-whitespace,
which affect the construction of the data model from the Infoset. 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 white space is not preserved.
ignore-comments : xs:boolean
ignore-processing-instructions : xs:boolean
ignore-whitespace : xs:boolean
Insignificant whitespace is defined as a text node that:
-
contains no characters other than white space 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 eight distinct
kinds of nodes: document,
element, attribute,
text, namespace,
processing instruction,
comment, and
reference. The eight kinds of nodes are defined in the following
subsections.
Note: The XPath 1.0 data model does not
have reference nodes. Document nodes and XPath 1.0 root nodes serve
many of the same purposes, but are not identical. In XPath 1.0,
root nodes served as containers of document fragments.
XPath 2.0 supports sequences as first-class objects in the data model.
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.
Document nodes and element nodes have a sequence of child nodes. 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.
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. A tree contains a root plus all nodes that are reachable
directly or indirectly from the root via the children,
attributes, and 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.
Note: In XPath 1.0, Namespace nodes have parents.
There is also a way of determining the string-value of
each kind of node. For some kinds of node, the string-value
is part of the node; for other kinds of node, the string-value
is computed from the string-value of its descendant nodes.
Element and attribute nodes contain a typed value,
i.e., values that have associated schema simple type.
An attribute contains a sequence of simple-typed values.
An element contains either a complex-typed value, i.e., a sequence
of nodes, a simple-typed value, or a sequence of simple-typed values.
4.2 Elements and 4.3 Attributes specify
how the simple-typed value (typed-value) of an element or
attribute is accessed.
The following accessors are defined on all eight
kinds of Nodes. The node-kind accessor returns a
string value representing the node's kind: either "document",
"element", "attribute", "text",
"namespace", "processing-instruction",
"comment", or "reference". The
name accessor returns the empty sequence, if the
node has no name, otherwise, it returns a sequence containing one
expanded QName. An expanded QName is in the value space
of xs:QName, and contains a namespace URI and a local name.
The parent accessor returns an empty sequence, if the
node has no parent, otherwise, it returns a sequence containing one node.
The string-value accessor returns the node's string
representation.
The basic concept in the Infoset is an InfoItem. 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, doctype
item, unparsed entity item, notation item, and namespace item.
Constructors
are provided by an Infoset processor.
The infoitem-kind accessor
returns a string value representing the information item's kind:
infoitem-kind : InfoItem -> xs:string
4.1 Documents
A document is represented by a document node, which corresponds
to a document information item.
A document node does not have an expanded-QName.
The children of the document node are nodes corresponding
to the information items found in the
[children] property, omitting
any document type declaration information
items.
In a well-formed document,
the children of the document node consist
exclusively of element, processing-instruction, or 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.
The base URI of the document corresponds to the
[base URI] property.
The string-value of the document node is the
concatenation of the string-values of all text-node descendants of
the document node in document order.
The parent of the document node is always the empty sequence. A document node always represents the root of a tree.
A document node has the constructor document-node,
which takes a base URI value and a non-empty sequence of its children nodes:
The accessors base-uri and children return a
document node's constituent parts:
The node accessors
node-kind, parent, and
string-value also apply to document nodes.
A document node does not have an expanded-QName; the following
signature specifies that name applied to a document
node returns the empty sequence:
name(DocumentNode) : Sequence(0,0)<xs:QName>
A document node is constructed from a Document Information
Item by the dm-document-node function:
dm-document-node : DocumentItem -> DocumentNode
function dm-document-node(d) {
kids = dm-collapse-text-nodes(sequence-map(dm-node,
infoset-doc-children(d)))
return document-node(infoset-doc-base-uri(d), kids)
}
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. Below, dm-node is
applied to each child of the Document Information Item
value d and a new sequence
of children nodes is constructed, each of which is a
Node. The constructor
document-node constructs the document node in the
data model.
sequence-map : ((UnitValue1 -> UnitValue2), Sequence<UnitValue1)
-> Sequence<UnitValue2>
The dm-node function maps an information item
to a sequence of zero or one data-model node.
dm-node : InfoItem -> Sequence<(0,1)Node>
function dm-node(i) {
return
if (infoitem-kind(i) = "element") then
dm-element-node(i)
else if (infoitem-kind(i) = "character") then
dm-char-to-text(i)
else if (infoitem-kind(i) = "processing-instruction") then {
if (not(ignore-processing-instructions)) then
dm-pi-node(i)
else empty-sequence()
}
else if (infoitem-kind(i) = "comment") {
if (not(ignore-comments)) then
dm-comment-node(i)
else empty-sequence()
}
else if (infoitem-kind(i) = "doctype") then
empty-sequence()
else if (infoitem-kind(i) = "notation-item") then
empty-sequence()
else if (infoitem-kind(i) = "unparsed-entity-item") then
empty-sequence()
}
4.2 Elements
Each element node corresponds to an element
information item.
An element node has an expanded-QName. The local part
of the expanded-QName corresponds to the
[local name] property.
The namespace name of the expanded-QName of the element node
corresponds to the [namespace name]
property, if it has a value.
The children nodes of the element node
correspond to the element, comment, processing instruction, and
character information items appearing in the
[children] property.
This correspondence is not one-to-one, as consecutive
character information item children
are 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.
The attributes of the element node are nodes
corresponding to attribute information
items appearing in the
[attributes] property. The
attributes of an element always have distinct names.
The namespaces of the element node are nodes
corresponding to namespace information items
appearing in the [in-scope namespaces]
property. The namespaces of an element always have distinct prefixes.
The declaration of an element is a schema component
and corresponds to the [element
declaration] PSVI property. The type of an
element is a schema component and corresponds to the [type definition] PSVI property. The
representation of schema component information is defined in
8 Schema Components.
An element node has an associated simple
typed-value, e.g., an integer,
date, or user-defined simple value. For a document with a
schema, the element's typed-value corresponds to the [schema normalized value] PSVI
property. If the element has a complex type, the typed-value is the
empty sequence. For an element in a well-formed document with no
associated schema, the element's typed-value is the empty
sequence.
The unique ID of the element node corresponds to the
[normalized value] property
of the attribute information item
in the [attributes]
property that has a type ID.
Editorial Note: JM: Need to augment attribute typing to accommodate DTD types
and Schema types in a unified manner. For instance, what is the namespace of
the ID type from a DTD?
Editorial Note: JM: Not incorporated from XPath 1.0: "If an XML processor
reports two elements in a document as having the same unique ID (which is
possible only if the document is invalid) then the second element in
document order must be treated as not having a unique ID."
The parent of the element node corresponds to the node
corresponding to the [parent] property.
The string-value of an element node is the concatenation of
the string-values of all text-node descendants of the element node in
document order.
An element node has a constructor element-node,
which takes an expanded-QName, a sequence of namespace nodes, a sequence
of attribute nodes, a sequence of child nodes, and
the node's element declaration, which is a schema component.
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.
Editorial Note: MF: The constructor only takes the element
declaration, because it's possible to derive
the type of an element or attribute from its corresponding
declaration. But would it be cleaner to include the type in the
constructor as well?
To guarantee that the parent-child relationship is
invertible, the element constructor logically creates a copy of all of its
namespace, attribute, and children arguments and sets 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.
The accessors name,
namespaces, attributes,
children, and declaration return an
element node's constituent parts. The type
accessor returns the schema component corresponding to the type of
the element's content: either a complex-type-definition or
simple-type-definition. It is possible to derive the element's type
from its declaration.
The accessor function typed-value returns
a sequence of the simple-typed values of an element, if the
element has a simple type, otherwise if the
element has a complex type, it returns the empty sequence.
typed-value : ElementNode -> Sequence<SimpleValue>
The accessor function unique-id returns
a sequence containing the unique ID of a node, if one exists,
otherwise, it returns the empty sequence.
unique-id : ElementNode -> Sequence(0,1)<xs:ID>
The node accessors
node, node-kind,
parent, and string-value also apply to
element nodes.
An element node is constructed from an Element Information
Item by the dm-element-node function:
dm-element-node : ElementItem -> ElementNode
function dm-element-node(e) {
name = xfo:expanded-QName(infoset-elem-namespace-name(e),
infoset-elem-local-name(e))
nsnodes = sequence-map(dm-namespace-node,
infoset-elem-in-scope-namespaces(e))
attrnodes = sequence-map(dm-attribute-node, infoset-elem-attributes(e))
kids = dm-collapse-text-nodes(sequence-map(dm-node, infoset-elem-children(e)))
declaration = dm-schema-component(psvi-elem-validity(e),
psvi-elem-element-declaration(e))
type = dm-schema-component(psvi-elem-validity(e),
psvi-elem-type-definition(e))
return element-node(name, nsnodes, attrnodes, kids, declaration)
}
Editorial Note: MF: Even though its possible to derive
the type of an element from its corresponding element declaration,
it seems cleaner to compute explicitly the schema components for
both the element declaration and its simple or complex type.
Editorial Note: JM: Update the above to accomodate the possibility of
schema-less and DTD validation.
4.3 Attributes
Each element node has an associated set of attribute nodes, each
corresponding to an attribute
information item.
An attribute node has an expanded-QName. The local part
of the expanded-QName corresponds to the
[local name] property. The namespace
name of the expanded-QName corresponds to the
[namespace name] property.
An attribute node has an associated string-value,
which corresponds to the
[normalized value] property.
The declaration of an attribute is a schema component
and corresponds to the [attribute
declaration] PSVI property. The type of an
attribute is a schema component and corresponds to the [type definition] PSVI property. The
representation of schema component information is defined in
8 Schema Components.
An attribute node also has a typed-value. For a
document with a schema, the attribute's typed-value corresponds to
the [schema normalized value]
PSVI property. For an attribute in a well-formed document with no
associated schema, the attribute's typed-value is the empty
sequence.
Editorial Note: JM: What about in the presence of a DTD? We need to
recognize ID attribute types at a minimum.
For convenience, the element node is called the "parent" of each of
these attribute nodes even though an attribute node is not a "child" of
its parent element. The parent of the attribute node
corresponds to the [owner element]
property.
An attribute node has the constructor attribute-node,
which takes the attribute's name, a string value, and the node's
attribute declaration, which is a schema component.
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.
The accessors name and
declaration return an
attribute's constituent parts. The accesor string-value
returns its value. The type accessor
returns the schema component corresponding to the simple type of the
attribute's value. It is possible to derive the attribute's type
from its declaration.
The accessor function typed-value returns
a sequence of the simple-typed values of an attribute.
typed-value : AttributeNode -> Sequence<SimpleValue>
The node accessors
node-kind, parent, and string-value also apply to
attribute nodes.
An attribute node is constructed from an Attribute Information
Item by the dm-attribute-node function:
dm-attribute-node : AttributeItem -> AttributeNode
function dm-attribute-node(a) {
name = xfo:expanded-QName(infoset-attr-namespace-name(a),
infoset-attr-local-name(a))
declaration = dm-schema-component(psvi-attr-validity(a),
psvi-attr-attribute-declaration(a))
type = dm-schema-component(psvi-attr-validity(a),
psvi-attr-type-definition(a))
return attribute-node(name, infoset-attr-normalized-value(a), declaration)
}
Editorial Note: JM: Update the above to accomodate the possibility of
schema-less and DTD validation.
4.4 Namespaces
Each element node has an associated set of namespace nodes, each
corresponding to a namespace information item.
A namespace node has an expanded-QName. The local part of the
QName corresponds to the [prefix]
property. The namespace name of the QName is the empty
sequence.
The string-value of the namespace node corresponds to
the [namespace URI] property.
A namespace node has no parent.
Editorial Note: From XPath 1.0 : "The parent of the
namespace node is the element node in whose namespaces collection
this node appears." This is still the subject of debate.
A namespace node has the constructor
namespace-node, which takes a namespace prefix and
the absolute URI of the namespace being declared, either of which
may be the empty sequence. If the URI is empty, the prefix must
be empty too.
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.
The accessors prefix and namespace-uri
return a namespace node's constituent parts:
The accessors
name, node-kind and string-value also apply to
comment nodes.
The parent accessor applied to a namespace-node returns
the empty sequence:
parent(NamespaceNode) : Sequence(0,0)<ElementNode | DocumentNode>
A namespace node is constructed from a Namespace Information
Item by the dm-namespace-node function:
4.5 Processing Instructions
A processing instruction node corresponds to a processing
instruction information item. There are no processing instruction
nodes for processing instructions that are children of a
document type declaration information item.
A processing instruction node has an expanded-QName. The local part of the
expanded-QName corresponds to the [target]
property. The namespace name of the expanded-QName is
the empty sequence.
The local part is a string value that must be an NCName.
The string '?>' may not occur within a processing instruction's
target value ([XML Recommendation]).
The string-value of the processing instruction node
corresponds to the [content]
property.
The parent of the processing instruction node
corresponds to the [parent]
property.
A processing-instruction node has the constructor
processing-instruction-node, which takes a string
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.
The string-value of the processing-instruction node corresponds to
the [content] property.
The node accessors
name, node-kind, parent, and string-value also apply to
processing-instruction nodes.
A processing-instruction node is constructed from an Processing
Instruction Information Item by the dm-pi-node function:
4.6 Comments
A comment node corresponds to a comment
information item. There are no comment nodes for comments
that are children of a document type declaration
information item.
A comment node does not have an expanded-QName.
The string-value of the comment node corresponds to
the [content] property.
The parent of the comment node
corresponds to the [parent]
property.
The string "--" (double-hyphen) must not occur within a comment's
string value ([XML Recommendation]).
The node accessors
node-kind, parent, and string-value also apply to
comment nodes.
A comment node does not have an expanded-QName; the following
signature specifies that name applied to a comment
node returns the empty sequence:
name(CommentNode) : Sequence(0,0)<xs:QName>
A comment node is constructed from a Comment Information
Item by the dm-comment-node function:
4.7 References
The data model provides reference nodes as a general mechanism
for referring to arbitrary nodes and preserving their identity.
We assume that the representation of a reference node is defined by the
query system that implements the data model.
The mechanism for implementing
a reference node is implementation dependent, for example,
a reference node might be represented by a ID or key value, an object
identifier, an XPointer value [XML Pointer Language (XPointer)], etc. Node references are not serialized, i.e.,
they exist only for use by the query system. To serialize a node reference,
an implementation may require that the reference be transformed
explicitly to a valid
XML value, such as an IDREF or URI reference, or the implementation may
transform a reference node automatically.
Reference nodes are not guaranteed to be globally unique or persistent,
although some implementation of the data model may choose to support
persistent node references. Multiple techniques may exist for implementing
reference nodes, and there may be multiple techniques for implementing node
identity.
A reference node does not correspond to any information item.
A reference node does not have an expanded-QName.
The string-value of a reference node is implementation-defined.
A reference node has the constructor reference-node,
which takes a document, element, attribute, text, processing-instruction,
or comment node. Like all other node constructors, the reference node
constructor has the effect of creating a new node with a unique identity,
distinct from all other nodes.
The accessor dereference returns the node referred to by a
reference node.
The node accessors node-kind, parent, and
string-value also apply to reference nodes. The following
signature specifies that name applied to a reference node
node returns the empty sequence:
name(ReferenceNode) : Sequence(0,0)<xs:QName>
4.8 Text
A text node corresponds to a sequence of one or more consecutive
character information items. 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.
A text node does not have an expanded-QName.
The string-value of a text node is the character data,
which corresponds to the concatenated [character
code] properties of each of the character
information items.
The parent of the text node corresponds to
the [parent] property of
any one of the consecutive character
information items (consecutive characters always have
the same parent).
A text node has the constructor 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.
The string-value of a text node is simply its content.
The node accessors
node-kind, parent, and string-value also apply to
text nodes.
The mapping from character information items to
text nodes occurs in the dm-element-node function.
The infoset-char-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 dm-char-to-text takes one character
information item and maps it to a text node with a string value of
length one.
dm-char-to-text : CharacterItem -> TextNode
function dm-char-to-text(c) {
/* convert character code to string of length 1 */
text-node(code2string(infoset-char-code c))
}
The dm-collapse-text-node function synthesizes a single text
node from multiple text nodes. It calls dm-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.
dm-collapse-text-nodes : Sequence<Node> -> Sequence<Node>
dm-text-node : Sequence<Node> -> Sequence<Node>
function dm-collapse-text-node(nodes) {
let newnodes := dm-text-nodes(nodes)
return
if (ignore-whitespace) then
sequence-map(delete-whitespace-node, newnodes)
else newnodes
}
function dm-text-nodes(nodes) {
if (empty(nodes)) then empty-sequence()
else
let h := head(nodes),
t := tail(nodes)
return
if (node-kind(h) = "text") then {
/* Collapse two consecutive text nodes and apply
dm-text-nodes recursively */
if (empty(t)) then h
else if (node-kind(head(t)) = "text") then
dm-text-nodes(
append(
text-node(xfo:concat(string-value(h), string-value(head(t))),
tail(t)))
}
else append(h, dm-text-nodes(t))
}
8 Schema Components
This section requires some familiarity with the [XML Schema: Formal Description].
In the data model, the [XML Schema: Formal Description] (XFSD) components are
represented by four kinds of schema-component values:
element-declaration,
attribute-declaration,
simple-type-definition, and
complex-type-definition.
A schema component collectively refers to these four kinds
of values.
We use the notation [f]
to refer to the XSFD component field named f.
The [name] of an XSFD component has
the form
i#sn1/.../snk,
where
snk =
ss::j.
The symbol i is a namespace, ss is one of six symbol
spaces (element, attribute, type, attribute group, model group, or notation), and j is a local name.
Given an XSFD component with a [name] as above,
the corresponding schema-component value has the following properties.
A schema component has an expanded-QName
The namespace name of its expanded-QName is equal to i, and
local part is equal to the empty string if j = *, otherwise
it is equal to j.
The parent property is
equal to the empty sequence if k = 1, otherwise
it is the schema component with corresponding
[name] equal to
i#sn1/.../sn(k-1).
The base property is
the component whose name is [base].
The derived-by-extension property
is true if [derivation] is "extension", otherwise false.
The derived-by-refinement property
is true if [derivation] is "restriction", otherwise false.
Editorial Note: MF cite James:
(An alternative to (d), (e) and (f) would be to have an extends accessor
that returns deref([base]) if [derivation] is extension and empty
sequence otherwise, and a restricts accessor that returns deref([base])
if [derivation] is restriction and empty sequence otherwise.)
The [abstract], [refinement] and [content] fields of a XSFD component
are not represented in this proposal (at least for the first two it
would be easy to extend the proposal to cover them).
A SchemaComponent has the following
accessors.
The component-kind accessor returns the string
"element-declaration", "attribute-declaration",
"simple-type-definition", or
"complex-type-definition".
The other accessors are defined above.
component-kind : SchemaComponent -> xs:string
name : SchemaComponent -> xs:QName
parent : SchemaComponent -> Sequence(0,1)<SchemaComponent>
base : SchemaComponent -> SchemaComponent
derived-by-extension : SchemaComponent -> xs:boolean
derived-by-refinement : SchemaComponent -> xs:boolean
8.1 Mapping PSV Infoset additions to Schema Components
This section specifies how
the schema component of an element or attribute
node is constructed from
the PSV Infoset additions that specify
validity and type assessment for the node's corresponding information
item.
We note that each kind of XSFD component has a corresponding
"top-most" or "root"
component, named xs:AnyElement, xs:AnyAttribute,
xs:AnySimpleType, xs:AnyComplexType.
These root components represent the most general element,
attribute, simple type, and complex type.
We assume these components are pre-defined and rely on them in the
definitions below.
A PSV element (attribute) information item has a
[validity],
an [element-declaration]
([attribute-declaration]), and
a [type-definition] property.
The [validity] property may be
"valid", "invalid", or "notKnown".
The [element-declaration]
and [attribute-declaration]
properties contains an element information item that is
isomorphic to the XML Schema element or attribute declaration of the
element or attribute information item.
Similarly,
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.
These properties are used to construct the schema
component of an element or attribute in the data model.
The dm-schema-component function
takes a string-valued validity property and an element information item
that corresponds to an element or attribute declaration or a type
definition. It constructs a schema-component value that
corresponds to the schema component represented by its
arguments.
If its [validity] property is
"valid", dm-schema-component constructs a
schema component that corresponds to the element or attribute
declaration or type definition represented by the information item
in its second argument.
If its [validity] property is
"invalid" or "notKnown",
dm-schema-component returns the "root" schema component
that corresponds to the element or attribute declaration or type
definition represented by the information item in its second
argument. For example, if the information item is an element
declaration, dm-schema-component returns
xs:AnyElement, and similarly, for the other three
components. 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 the most general type
information with the element or attribute node.
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 document
a well-formed document, with no corresponding DTD or Schema...
Editorial Note: MF cite James' notes:
Given an XSFD normalized attribute or element x[t types d], the
declaration accessor would return deref(x) and the type accessor would
return deref(t).
Note that for any element or attribute node nd, if declaration(x) is not
null, then
local-name(x) = local-name(declaration(x)), and
namespace-uri(x) = namespace-uri(declaration(x))