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 ).

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.

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 ). 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 data model is defined in terms of the 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:

The data model does not support XML documents that are not supported by the XML Information Set, for example, non-well-formed documents and documents 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 ().

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. specifies how such documents are represented in the data model. See .

The (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 (element, attribute, simple type, and complex type), 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 element nodes, attribute nodes, and simple typed values have an associated schema component. We use the term SchemaComponent to collectively refer to the data model's schema component values element-declaration, attribute-declaration, simple-type-definition, and complex-type-definition. The accessors for schema components are defined in . 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 . A simple type is either primitive (e.g., xs:string, xs:boolean, xs:float, xs:double) or derived (e.g., xs:language, xs:NMTOKEN, xs:long, xs:ID, xs:IDREF, etc., or user defined). If a simple typed value is in the value space of the simple type, we say a simple typed value is an instance of a schema simple type. Because the value spaces of schema simple types may overlap, a simple typed 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.

A schema complex type defines the permissible structure and content of an element .

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.

The data model supports two representations of the character data in an XML document: text nodes and simple-typed values. A text node represents a string of consecutive character information items and never has another text node as its immediately following sibling. An element node, for example, has child nodes that may include text nodes, comment nodes, processing instruction nodes, and other element nodes. 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 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.

The data model logically supports both text nodes and simple-typed values, but it does not specify that they both must be implemented. An implementation might choose to only store simple-typed values and reconstruct text nodes on demand, or vice versa. This allows for the efficient storage of and access to simple typed values but it has an impact on interoperability; for instance, searching for leading zeros in nodes with numerical simple typed values may yield results in some implementations but not in others.

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:

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 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.

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 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.

A document node has the constructor document-node, which takes a base URI value and a non-empty sequence of its children nodes. 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.

document-node : (xs:anyURI, Sequence(1,*)<ElementNode | TextNode | ProcessingInstructionNode | CommentNode>) -> DocumentNode

The accessors base-uri and children return a document node's constituent parts:

base-uri : (DocumentNode) -> xs:anyURI children : (DocumentNode) -> Sequence(1,*)<ElementNode | TextNode | ProcessingInstructionNode | CommentNode>

The accessors node-kind and string-value also apply to document nodes and return results other than the empty sequence. The accessors name, typed-value, parent, attributes, namespaces, declaration, type and unique-ID applied to a document node always return the empty sequence.

A document node is constructed from a Document Information Item by the infoitem-to-document-node function:

/* Accessors for document information items: */ infoset-document-children : (DocumentItem) -> Sequence<ElementItem | ProcessingInstructionItem | CommentItem | DocTypeItem> infoset-document-base-uri : (DocumentItem) -> xs:anyURI

infoitem-to-document-node : (DocumentItem) -> DocumentNode function infoitem-to-document-node(d) { let kids := collapse-text-nodes(sequence-map(infoitem-to-node, infoset-document-children(d))) return document-node(infoset-document-base-uri(d), kids) }

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 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 infoitem-to-node function maps an information item to a sequence of zero or one node.

infoitem-to-node : (InfoItem) -> Sequence(0,1)<Node> function infoitem-to-node(i) { return if (infoitem-kind(i) = "element") then infoitem-to-element-node(i) else if (infoitem-kind(i) = "character") then infoitem-to-single-character-text-node(i) else if (infoitem-kind(i) = "processing-instruction") then if (not(ignore-processing-instructions)) then infoitem-to-processing-instruction-node(i) else empty-sequence() else if (infoitem-kind(i) = "comment") then if (not(ignore-comments)) then infoitem-to-comment-node(i) else empty-sequence() else /* infoitem-kind(i) = "doctype" | "notation" | "unparsed-entity" */ empty-sequence() }

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 URI of the expanded-QName of the element node corresponds to the namespace name property.

The parent of the element node corresponds to the node corresponding to the parent property.

An element node has an associated typed-value, which is a sequence of zero or more simple typed values. Examples of such values would be a sequence containing an integer, or user-defined simple value or several dates, etc. 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 (see . For an element in a well-formed document with no associated schema, the element's typed-value is the empty sequence. If the element was created with an xsi:nil attribute set to true, then typed-value returns the empty sequence. See .

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. See .

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 . See .

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.

An element node can be constructed in one of two ways: element-complex-node is useful for constructing an element from the PSVI, element-simple-node is useful when constructing an element via embedded expressions. The difference in the constructors is whether the children of the node are specified as a sequence of nodes or as a sequence of simple typed values.

The constructor element-complex-node 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.

element-complex-node : (xs:QName, Sequence<NamespaceNode>, Sequence<AttributeNode>, Sequence<ElementNode | TextNode | ProcessingInstructionNode | CommentNode>, SchemaComponent) -> ElementNode

The constructor element-simple-node takes an expanded-QName, a sequence of namespace nodes, a sequence of attribute nodes, a sequence of simple typed values, and the node's element declaration, which is a schema component.

element-simple-node : (xs:QName, Sequence<NamespaceNode>, Sequence<AttributeNode>, Sequence<SimpleTypedValue>, SchemaComponent) -> ElementNode

Like all other node constructors, the element node constructors has the effect of creating a new node with a unique identity, distinct from all other nodes.

To guarantee that the parent-child relationship is invertible, 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 .

Neither constructor allows specifying the children of the node as a heterogeneous sequence, i.e. a sequence mixing nodes and simple typed values. It is still prossible to construct an element (with mixed content) from such a sequence in two steps: First the heterogeneous sequence will need to be turned into a homogeneous one by converting the simple typed values to text nodes, then the now homogeneous sequence can be passed to the element-complex-node constructor. Note that the precise type information of the simple typed values is lost in the process, which is inline with XML Schema, that cannot represent the type of such mixed content.

The accessors name, namespaces, attributes and declaration return an element node's constituent parts. The children accessor returns the sequence of children nodes for an element node if it was created with element-complex-node and it returns a singleton sequence containing a text node corresponding to the sequence of simple typed values if it was created with element-simple-node. 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. See .

name : (ElementNode) -> xs:QName namespaces : (ElementNode) -> Sequence<NamespaceNode> attributes : (ElementNode) -> Sequence<AttributeNode> children : (ElementNode) -> Sequence<ElementNode | TextNode | ProcessingInstructionNode | CommentNode> declaration : (ElementNode) -> SchemaComponent type : (ElementNode) -> SchemaComponent

If an element has a simple type, the accessor function typed-value returns a sequence of the simple-typed values of the element; otherwise, it returns the empty sequence. If the element was created with an xsi:nil attribute set to true, then typed-value returns the empty sequence.

typed-value : (ElementNode) -> Sequence<SimpleTypedValue>

The string-value of an element node returns the concatenation of the string-values of all text-node descendants of the element node in document order if it was created with element-complex-node and it returns the string representation of the sequence of simple typed values if it was created with element-simple-node.

string-value : (ElementNode) -> xs:string

If an element has a unique ID, the accessor function unique-ID returns a sequence containing the unique ID of the node; otherwise, it returns the empty sequence.

unique-ID : (ElementNode) -> Sequence(0,1)<xs:ID>

The node accessors base-uri, node-kind, parent, and string-value also apply to element nodes.

An element node is constructed from an Element Information Item by the infoitem-to-element-node function:

/* Accessors for element information items: */ infoset-element-namespace-name : (ElementItem) -> Sequence(0,1)<xs:anyURI> infoset-element-local-name : (ElementItem) -> xs:string infoset-element-children : (ElementItem) -> Sequence<InfoItem> infoset-element-attributes : (ElementItem) -> Sequence<AttributeItem> infoset-element-in-scope-namespaces : (ElementItem) -> Sequence<NamespaceItem> infoset-element-base-uri : (ElementItem) -> xs:anyURI /* unused ? */ psvi-element-validity : (ElementItem) -> xs:string psvi-element-element-declaration : (ElementItem) -> ElementItem psvi-element-type-definition : (ElementItem) -> ElementItem psvi-element-schema-normalized-value : (ElementItem) -> xs:string

infoitem-to-element-node : (ElementItem) -> ElementNode function infoitem-to-element-node(e) { let name := xf:QName-from-uri(infoset-element-namespace-name(e), infoset-element-local-name(e)), nsnodes := sequence-map(infoitem-to-namespace-node, infoset-element-in-scope-namespaces(e)), attrnodes := sequence-map(infoitem-to-attribute-node, infoset-element-attributes(e)), kids := collapse-text-nodes(sequence-map(infoitem-to-node, infoset-element-children(e))), declaration := infoitem-to-schema-component(psvi-element-validity(e), psvi-element-element-declaration(e)), type := infoitem-to-schema-component(psvi-element-validity(e), psvi-element-type-definition(e)) return element-complex-node(name, nsnodes, attrnodes, kids, declaration) }

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.

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 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.

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 .

An attribute node can be constructed in one of two ways: attribute-complex-node is useful for constructing an attribute from the PSVI, attribute-simple-node is useful when constructing an attribute with embedded expressions.

The constructor attribute-complex-node takes the attribute's name, a string value and the node's attribute declaration, which is a schema component.

attribute-complex-node : (xs:QName, xs:string, SchemaComponent) -> AttributeNode

The constructor attribute-simple-node takes the attribute's name, a simple typed value and the node's attribute declaration, which is a schema component.

attribute-simple-node : (xs:QName, Sequence<SimpleTypedValue>, SchemaComponent) -> AttributeNode

Like all other node constructors, the attribute node constructors have 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 accessor string-value returns an attribute's constituent part if it was created with attribute-complex-node and it returns the string representation of the sequence of simple typed values if it was created with attribute-simple-node. 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.

name : (AttributeNode) -> xs:QName string-value : (AttributeNode) -> xs:string declaration : (AttributeNode) -> SchemaComponent type : (AttributeNode) -> SchemaComponent typed-value : (AttributeNode) -> Sequence<SimpleTypedValue>

The node accessors node-kind and parent also apply to attribute nodes and may return results other than the empty sequence. The accessors base-uri, children, attributes, namespaces and unique-ID applied to an attribute node always return the empty sequence.

An attribute node is constructed from an Attribute Information Item by the infoitem-to-attribute-node function:

/* Accessors for attribute information items: */ infoset-attribute-namespace-name : (AttributeItem) -> Sequence(0,1)<xs:anyURI> infoset-attribute-local-name : (AttributeItem) -> xs:string infoset-attribute-normalized-value : (AttributeItem) -> xs:string infoset-attribute-owner-element : (AttributeItem) -> ElementItem psvi-attribute-validity : (AttributeItem) -> xs:string psvi-attribute-attribute-declaration : (AttributeItem) -> ElementItem psvi-attribute-type-definition : (AttributeItem) -> ElementItem psvi-attribute-schema-normalized-value : (AttributeItem) -> xs:string

infoitem-to-attribute-node : (AttributeItem) -> AttributeNode function infoitem-to-attribute-node(a) { let name := xf:QName-from-uri(infoset-attribute-namespace-name(a), infoset-attribute-local-name(a)), declaration := infoitem-to-schema-component(psvi-attribute-validity(a), psvi-attribute-attribute-declaration(a)), type := infoitem-to-schema-component(psvi-attribute-validity(a), psvi-attribute-type-definition(a)) return attribute-complex-node(name, infoset-attribute-normalized-value(a), declaration) }

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 URI of the QName is the empty sequence.

The string-value of the namespace node corresponds to the namespace name property.

A namespace node has no parent.

A namespace node has the constructor 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.

namespace-node : (Sequence(0,1)<xs:string>, xs:string) -> NamespaceNode

A namespace node's constituent parts may be obtained by applying the accessors name (with the function xf:get-local-name) and string-value.

name : (NamespaceNode) -> Sequence(0,1)<xs:QName> string-value : (NamespaceNode) -> xs:string

The node accessor node-kind also applies to namespace nodes and returns a result other than the empty sequence. The accessors base-uri, typed-value, parent, children, attributes, namespaces, declaration, type and unique-ID applied to a namespace node always return the empty sequence.

A namespace node is constructed from a Namespace Information Item by the infoitem-to-namespace-node function:

infoset-namespace-prefix : (NamespaceItem) -> Sequence(0,1)<xs:string> infoset-namespace-namespace-name : (NamespaceItem) -> xs:string

infoitem-to-namespace-node : (NamespaceItem) -> NamespaceNode function infoitem-to-namespace-node(i) { return namespace-node(infoset-namespace-prefix(i), infoset-namespace-namespace-name(i)) }

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 URI 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 ().

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 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.

processing-instruction-node : (xs:NCName, xs:string) -> ProcessingInstructionNode

A processing instruction's constituent parts may be obtained by applying the accessors name (with the function xf:get-local-name) and string-value.

name : (ProcessingInstructionNode) -> xs:QName string-value : (ProcessingInstructionNode) -> xs:string

The node accessors node-kind and parent also apply to processing-instruction nodes and may return results other than the empty sequence. The accessors base-uri, typed-value, children, attributes, namespaces, declaration, type and unique-ID applied to a processing-instruction node always return the empty sequence.

A processing-instruction node is constructed from an Processing Instruction Information Item by the infoitem-to-processing-instruction-node function:

/* Accessors for processing instruction information items */ infoset-processing-instruction-target : (ProcessingInstructionItem) -> xs:string infoset-processing-instruction-content : (ProcessingInstructionItem) -> xs:string

infoitem-to-processing-instruction-node : (ProcessingInstructionItem) -> ProcessingInstructionNode function infoitem-to-processing-instruction-node(i) { return processing-instruction-node(xf:NCName(infoset-processing-instruction-target(i)), infoset-processing-instruction-content(i)) }

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 ().

A comment node has the constructor comment-node, which takes a string value. Like all other node constructors, the comment node constructor has the effect of creating a new node with a unique identity, distinct from all other nodes.

comment-node : (xs:string) -> CommentNode

A comment node's constituent parts may be obtained by applying the accessor string-value.

string-value : (CommentNode) -> xs:string

The node accessors node-kind and parent also apply to comment nodes and may return results other than the empty sequence. The accessors name, base-uri, typed-value, children, attributes, namespaces, declaration, type and unique-ID applied to a comment node always return the empty sequence.

A comment node is constructed from a Comment Information Item by the infoitem-to-comment-node function:

/* Accessors for comment information items */ infoset-comment-value : (CommentItem) -> xs:string

infoitem-to-comment-node : (CommentItem) -> CommentNode function infoitem-to-comment-node(i) { return comment-node(infoset-comment-value(i)) }

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.

text-node : (xs:string) -> TextNode

The string-value of a text node is simply its content.

string-value : (TextNode) -> xs:string

The node accessors node-kind and parent also apply to text nodes and may return results other than the empty sequence. The accessors name, base-uri, typed-value, children, attributes, namespaces, declaration, type and unique-ID applied to a text node always return the empty sequence.

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.

infoset-character-code : (CharacterItem) -> Code

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.

infoitem-to-single-character-text-node : (CharacterItem) -> TextNode function infoitem-to-single-character-text-node(c) { /* convert character code to string of length 1 */ return text-node(code2string(infoset-character-code(c))) }

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.

collapse-text-nodes : (Sequence<Node>) -> Sequence<Node> infoitem-to-text-nodes : (Sequence<Node>) -> Sequence<Node> function collapse-text-nodes(nodes) { let newnodes := infoitem-to-text-nodes(nodes) return if (ignore-whitespace) then sequence-map(delete-whitespace-node, newnodes) else newnodes } function infoitem-to-text-nodes(nodes) { if (xf:empty(nodes)) then return empty-sequence() else let head := op:item-at(nodes, 1), tail := xf:sublist(nodes, 2) return if (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 (node-kind(op:item-at(tail,1)) = "text") then infoitem-to-text-nodes( op:concatenate( text-node(xf:concat(string-value(head), string-value(op:item-at(tail,1)))), xf:sublist(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)) }

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 (attribute-declaration) property 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 infoitem-to-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.

infoitem-to-schema-component : (xs:string, ElementItem) -> SchemaComponent

If its validity property is "valid", infoitem-to-schema-component constructs a schema component that corresponds to the element or attribute declaration or type definition represented by the element information item in its second argument.

If its validity property is "invalid" or "notKnown", infoitem-to-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, infoitem-to-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.

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...