XML Query Data Model. W3C Working Draft 11 May Abstract. Status of this document

Transcription

1 XML Query Data Mode W3C Working Draft 11 May 2000 This version: Latest version: Editors: Mary Fernandez (AT&T Labs) < > Jonathan Robie (Software AG) Copyright 2000 W3C (MIT, INRIA, Keio), A Rights Reserved. W3C iabiity, trademark, document use and software icensing rues appy. Abstract This document defines the W3C XML Query Data Mode, which is the foundation of the W3C XML Query Agebra; the XML Query Agebra wi be specified in a future document. Together, these two documents [wi] provide a precise semantics of the XML Query Language. Status of this document This section describes the status of this document at the time of its pubication. Other documents may supersede this document. The atest status of this document series is maintained at the W3C. This is a First Pubic Working Draft for review by W3C Members and other interested parties. It is a draft document and may be updated, repaced or made obsoete by other documents at any time. It is inappropriate to use W3C Working Drafts as reference materia or to cite them as other than "work in progress". This is work in progress and does not impy endorsement by the W3C membership. This document has been produced as part of the W3C XML Activity, foowing the procedures set out for the W3C Process. The document has been written by the XML Query Working Group. The XML Query Working Group fees that the contents of this Working Draft are reasonaby stabe, and therefore encourages feedback.

2 Comments on this document shoud be sent to the W3C maiing ist (archived at A ist of current W3C Recommendations and other technica documents can be found at Tabe of contents 1 Introduction 2 Concepts 2.1 Types and Signatures Reference Type Schema Types 2.2 Post Schema-Vaidated Infoset 3 Nodes 3.1 Data Mode Instance 3.2 Document 3.3 Eements 3.4 Attributes 3.5 Namespaces 3.6 Processing Instructions 3.7 Comments 3.8 Vaues 3.9 Information Items 4 Exampe 5 Constraints on the Data Mode 6 References Appendices A XML Information Set Mapping A.1 Notation and Pseudo-code Syntax A.2 Information Items A.3 Document Item A.4 Eement Items A.5 Attribute Items A.6 Namespace Items A.7 Processing Instruction Items A.8 Comment Items A.9 Other Information Items B Candidate Operators for XML Query Agebra B.1 Equaity Operators B.2 Seriaization Operators B.3 Order Operators B.4 Accessors for Reference Vaues 1 Introduction

3 This document defines the W3C XML Query Data Mode, which is the foundation of the W3C XML Query Agebra; the XML Query Agebra wi be specified in a future document. Together, these two documents [wi] provide a precise semantics of the XML Query Language. Severa XML data modes have been deveoped in the W3C Activities. The XML Information Set ( provides a description of the information avaiabe in a weformed XML document. The XPath Recommendation ( which is used by both XSLT ( and XPointer ( contains a data mode and a mapping that reates the XPath data mode to the XML Information Set (hence Infoset ). The Document Object Mode ( is an API for HTML and XML documents, but it does impy an underying abstract data mode. The XML Schema Working Group is defining features, such as structures ( and datatypes ( that extend an instance of the XML Information Set with more precise type information. The XML Query Data Mode defines formay the information contained in the input to an XML Query processor; in other words, an XML Query processor evauates a query on an instance of the XML Query Data Mode. Our mode is based on the XML Information Set, but it requires the foowing new features to meet the XML Query Working Group s requirements: Support for XML Schema types. ( ) Representation of Coections of Documents and of Simpe and Compex Vaues. ( Representation of References. ( #references) In this document, we provide a precise and forma definition of how vaues in the XML Query Data Mode are constructed and accessed; these operators are the foundation of the XML Query Agebra, and therefore, require a more forma treatment than is provided in the definitions of the XPath and Infoset data modes. For comparison, we note wherever the XML Query Data Mode differs from that of XPath, and we provide a forma definition of the mapping from the Infoset to the XML Query Data Mode in Appendix A. An instance of the XML Query data mode represents one or more compete XML documents or document parts. As with the Infoset, the XML Query Data Mode specifies what information in the documents is accessibe, but it does not specify the programming-anguage interfaces or bindings used to represent or access the data. We assume that the information contained in an instance of the XML Query Data Mode is static for the duration query evauation; in particuar, the meaning of a query appied to input data that changes during query evauation is undefined. We define the data mode using a functiona notation. We chose this notation because it is simpe and permits a precise and concise definition of the data mode. The notation is presented in the next section. Athough the notation has a functiona stye, we emphasize that the data mode can be reaized in a variety of programming anguages and styes, for exampe, as object casses and methods in an object-oriented anguage.

4 There is a cose correspondence between the data mode and the agebraic operations that are appied to instances of the data mode. In the definition of the data mode, we mention severa agebraic operators. These and other candidate operators are identified in the Candidate Operators for XML Query Agebra appendix. The compete agebra wi be defined in a future document. 2 Concepts Because XML documents are tree-structured, we define the XML Query data mode using conventiona terminoogy for trees. Various mathematica representations of trees exist (see [CLR]). The graph-theoretic representation modes a tree as a tupe (N, E, r), where N is a set of tree nodes, E is a one-to-many reation of edges from parent nodes to chidren nodes, and r is the distinguished root node of the tree. The tree-constructor representation modes a tree by recursive appication of a tree-creation function to a ist of chidren trees [Knuth]. In either representation, a tree can have data associated with its nodes (node-abeed), with its edges (edge-abeed), or with both. The XPath and Infoset data modes are exampes of node-abeed, tree-constructor representations. The XML Query Data Mode (hence data mode ) is a node-abeed, tree-constructor representation, but aso incudes a concept of node identity. The addition of node identity simpifies the representation of XML reference vaues, e.g., IDREF, XPointer, and URI vaues. Unike the graph mode, the data mode does not support both nodes and edges as first-cass concepts. We note, however, whenever a graph mode may be more fexibe or concise. 2.1 Types and Signatures The data mode defines the structure of various kinds of tree nodes; functions to construct tree nodes, caed constructors; and functions to access nodes structure, caed accessors. This presentation is simiar to that in the definition of the XSLT data mode [Wader]. We use the terms node type to refer to the kind of a tree node; schema type to refer to an XML Schema type; and coection type to refer to tupes, ists, sets, and disjoint unions. The term type refers to any node, schema, or coection type. The term signature refers to a constructor s or accessor s function type, i.e., the function s zero or more input types and its one output type. To make the definition of the data mode concise, we use the foowing notation: N ranges over node types. U ranges over the union of node types, schema types, and coection types. [ U ] denotes a ist of vaues with type U; a ist is ordered and may contain dupicates. { U } denotes a set of vaues with type U; a set is unordered and does not contain dupicate vaues. { U } denotes a bag of vaues with type U; a bag is unordered and may contain dupicate vaues.

5 (U1, U2,..., Un) denotes a tupe whose first component has type U1, second component has type U2, etc. U1 U2... Un denotes the disjoint union of vaues with types U1,..., Un, etc. TN = U denotes that the string TN is a type name that represents the type U. A type name may appear wherever its associated type is expected. An occurrence of the type symbo U denotes a vaue or instance of that type. The signatures of constructors and accessors use the foowing notation: f : U1 -> U2 denotes a function f that takes an input vaue with type U1 and returns an output vaue with type U Reference Type The data mode provides node references as a mechanism to test and bind the identity of nodes in a given instance of the data mode. The actua mechanism for impementing node identity is impementation dependent, for exampe, node identity might be represented by a key vaue, an object identifier, an XPointer vaue, etc. Ref(N) denotes a reference to a node with type N. The data mode provides the function ref to create a reference to a node and the function deref to produce the node referent of a reference vaue. Their signatures are: ref : Node -> Ref(Node) deref : Ref(Node) -> Node The function ref is surjective, i.e., it is onto. The function deref is the inverse of ref, i.e., for a nodes n, node_equa(deref(ref(n)), n) is true, where node_equa is an impementation-dependent equaity operator over nodes. Some accessors map vaues (e.g., IDREF or key vaues) into reference vaues. If a key vaue does not represent a vaid reference, the not a reference vaue, NaR, may be used Schema Types Nodes contain vaues that are instances of schema types. The foowing symbos denote schema types: T ranges over XML schema types, which are either simpe or compex. ST ranges over simpe types. CT ranges over compex types.

6 A simpe type is either primitive (e.g., string, booean, foat, doube, ID, IDREF) or derived (e.g., anguage, NMTOKEN, ong, etc., or user defined). A compex type defines the structure and content of an eement. It may be necessary for a query to have access to a vaue s type during query execution, i.e., at run time. Because an instance of an XML Schema is aso an XML document (see XML Representation of Schemas and Schema Components in [XMLSchema Part 1]), a document s schema can be represented as an instance of the data mode. Def_T = EemNode denotes the data mode representation of schema type T. Because Def_T is an eement vaue in the data mode, i.e., an EemNode, a of the accessors defined for EemNode can be appied to Def_T vaues. 2.2 Post Schema-Vaidated Infoset We assume that an instance of the data mode is derived from an instance of the XML Information Set [XML Infoset] after XML Schema vaidation. Such an instance is caed a PSV Infoset, for post schema-vaidated Infoset. A we-formed document may have an associated schema, derived from one or more XML Schema documents; it may have an associated DTD; or it may have no schema, i.e., it is schemaess. For a document with a schema, the PSV Infoset provides the schema. For a document with a DTD, we assume a mapping from the DTD to an equivaent schema is provided. For a schemaess document, a defaut schema is provided by the data mode, and we specify in this document that defaut schema. In a three cases, a schema can be provided for the input document and corresponding data-mode instance. 3 Nodes The basic concept in the data mode is a Node. A Node is one of eight node types: document, eement, vaue, attribute, namespace (NS), processing instruction (PI), comment, or information item. This definition specifies that a Node is the disjoint union of eight node types: Node = DocNode EemNode VaueNode AttrNode NSNode PINode CommentNode InfoItemNode The eight node types are defined in the foowing subsections. Note that an impementation of the data mode in an object-oriented anguage might choose to make Node an interface (or an abstract cass) and to make each node type a concrete cass that impements the Node interface (or a sub-cass of the abstract cass Node). A Node has eight accessors, each of which returns true if the Node vaue is of the specified type. isdocnode iseemnode isvauenode isattrnode isnsnode ispinode : Node -> booean : Node -> booean : Node -> booean : Node -> booean : Node -> booean : Node -> booean

7 iscommentnode : Node -> booean isinfoitemnode : Node -> booean 3.1 Data Mode Instance An XML document is represented by its distinguished document node, which is a DocNode. A document part is a sub-tree of a document and is represented by an EemNode, VaueNode, PINode, or CommentNode. An instance of the data mode represents one or more compete documents or document parts and may be unordered or ordered. Therefore, a data-mode Instance is a set, a ist, or a bag of one or more nodes: Instance = { DocNode EemNode VaueNode PINode CommentNode } [ DocNode EemNode VaueNode PINode CommentNode ] { DocNode EemNode VaueNode PINode CommentNode } 3.2 Document A document is represented by a unique DocNode, which corresponds to a document information item in the Infoset. A DocNode has the constructor docnode, which takes a URI reference vaue and a non-empty ist of its chidren nodes: docnode : (URIRefVaue, [ Ref(EemNode) Ref(PINode) Ref(CommentNode) ]) -> DocNode The ist of chidren nodes may contain zero or more references to PINodes and CommentNodes and must contain exacty one reference to an EemNode. The accessor uri returns a DocNode s URI reference vaue, and the accessor chidren returns a DocNode s ist of chidren: uri : DocNode -> URIRefVaue chidren : DocNode -> [ Ref(EemNode) Ref(PINode) Ref(CommentNode) ] The root accessor returns a reference to the unique EemNode in a DocNode s chidren ist: root : DocNode -> Ref(EemNode) 3.3 Eements An EemNode has the constructor eemnode, which takes a tag vaue, a set of NSNode namespaces, a set of AttrNode attributes, a ist of chidren nodes, and a reference to the node s type: eemnode : (Ref(QNameVaue), { Ref(NSNode) }, { Ref(AttrNode) }, [ Ref(EemNode) Ref(VaueNode) Ref(PINode) Ref(CommentNode) Ref(InfoItemNode) ], Ref(Def_T)) -> EemNode An EemNode s tag is a quaified name vaue, QNameVaue. An EemNode s set of namespaces contain one namespace node for each distinct namespace that is decared expicity on the eement. The node s chidren is a ist of references to EemNode, VaueNode, PINode,

8 CommentNode, and InfoItemNode vaues. We assume that the eement is an instance of the type represented by Def_T, i.e., the document type checks or is vaid with respect to the given schema. For a schemaess document, the data mode defines a defaut schema; in this case, the Def_T vaue for a EemNodes is the ur-type definition [XMLSchema Part 1]. The accessors name, namespaces, attributes, chidren, and type returns an EemNode s constituent parts: name : EemNode -> Ref(QNameVaue) namespaces : EemNode -> { Ref(NSNode) } attributes : EemNode -> { Ref(AttrNode) } chidren : EemNode -> [ Ref(EemNode) Ref(VaueNode) Ref(PINode) Ref(CommentNode) Ref(InfoItemNode) ] type : EemNode -> Ref(Def_T) The accessor parent returns a reference to the unique parent of an EemNode. If an EemNode is the root node of a document, parent wi return a reference to the corresponding DocNode, uness a document node does not exist, in which case parent returns NaR, the not a reference vaue. parent : EemNode -> Ref(EemNode) Ref(DocNode) NaR NOTE: The XPath data mode does not mode the compex type of a node. This definition adds Def_T to an eement node, and it aso adds VaueNode and InfoItemNode as permissibe chidren of an eement node. 3.4 Attributes An AttrNode has the constructor attrnode, which takes the attribute s name and vaue: attrnode : (Ref(QNameVaue), Ref(VaueNode)) -> AttrNode The accessors name and vaue, return an attribute s constituent parts: name vaue : AttrNode -> Ref(QNameVaue) : AttrNode -> Ref(VaueNode) For a schemaess document, the data mode defines a defaut schema; in this case, the type of a AttrNode s vaues is the simpe type <simpetype base="string"/>. The accessor parent returns a reference to the containing eement of an AttrNode. parent : AttrNode -> Ref(EemNode) NOTE: The XPath data mode ony permits attribute vaues to be strings. This definition permits attribute vaues to be of any simpe type.

9 3.5 Namespaces An NSNode has the constructor nsnode, which takes an namespace prefix, which may be nu, and the absoute URI of the namespace being decared, which may be nu: nsnode : (Ref(StringVaue) nu, Ref(URIRefVaue) nu) -> NSNode The accessors prefix and uri return a NSNode s constituent parts: prefix : NSNode -> Ref(StringVaue) nu uri : NSNode -> Ref(URIRefVaue) nu A namespace node may contain: a non-nu prefix and a non-nu uri; a nu prefix and a non-nu uri; or a nu prefix and a nu uri. A namespace node may not contain a non-nu prefix and a nu uri. The accessor parent returns a reference to the containing eement of an NSNode. parent : NSNode -> Ref(EemNode) 3.6 Processing Instructions A PINode has the constructor pinode, which takes a oca name that is the processing instruction s target and a string vaue: pinode : (Ref(StringVaue), Ref(StringVaue)) -> PINode The oca name is a string vaue that must have type NCNAME, i.e., its type vaue refers to the definition of the derived type NCName : <simpetype name="ncname" base="name"/> The accessors target, vaue return a PINode s constituent parts. target : PINode -> Ref(StringVaue) vaue : PINode -> Ref(StringVaue) The accessor parent returns a PINode s unique parent: parent : PINode -> Ref(EemNode) Ref(DocNode) NaR 3.7 Comments A CommentNode has the constructor commentnode, which takes a string vaue: commentnode : Ref(StringVaue) -> CommentNode The accessor vaue returns a CommentNode s vaue, and the accessor parent returns a CommentNode s unique parent:

10 vaue parent : CommentNode -> Ref(StringVaue) : CommentNode -> Ref(EemNode) Ref(DocNode) NaR 3.8 Vaues A VaueNode is the disjoint union of fourteen kinds of simpe-type vaues; each vaue kind has an associated constructor. VaueNode = StringVaue BooVaue FoatVaue DoubeVaue DecimaVaue TimeDurVaue RecurDurVaue BinaryVaue URIRefVaue IDVaue IDREFVaue QNameVaue ENTITYVaue NOTATIONVaue The data mode provides constructors for the fourteen primitive XML Schema datatypes: stringvaue : (string, Ref(Def_string), [Ref(InfoItemNode)]) -> StringVaue boovaue : (booean, Ref(Def_booean)) -> BooVaue foatvaue : (foat, Ref(Def_foat)) -> FoatVaue doubevaue : (doube, Ref(Def_doube)) -> DoubeVaue decimavaue : (decima, Ref(Def_decima)) -> DecimaVaue timedurvaue : (timeduration, Ref(Def_TimeDuration)) -> TimeDurVaue recurdurvaue: (recurringduration, Ref( Def_recurringDuration))-> RecurDurVaue binaryvaue : (binary, Ref(Def_binary)) -> BinaryVaue urirefvaue : (urireference, Ref(Def_uriReference)) -> URIRefVaue idvaue : (ID, Ref(Def_ID)) -> IDVaue idrefvaue : (IDREF, Ref(Def_IDREF)) -> IDREFVaue qnamevaue : (urireference nu, string, Ref( Def_QName)) -> QNameVaue entityvaue : (ENTITY, Ref(Def_ENTITY)) -> ENTITYVaue notationvaue: (NOTATION, Ref(Def_NOTATION)) -> NOTATIONVaue Ed. Note: We note here that the data mode does not currenty represent key vaues and key reference vaues as described in XML Schema Part 1 : Structures [XMLSchema Part 1]. In a future draft of this document, keys and key references wi be represented in the data mode. Derived datatypes are modeed as instances of their primitive base type. In particuar, wherever an instance of Def_ST is expected, we assume an instance of ST is permitted if and ony if ST is derived from simpe type ST. For exampe, the derived simpe type ong has base type integer, so an instance of ong can be modeed by an IntegerVaue whose type is Ref(Def_ong), i.e., it refers to the definition of the derived type ong: <simpetype name="ong" base="integer"/> The expicit enumeration of each kind of vaue guarantees that the type of the vaue s instance and its type representation correspond. For exampe, a StringVaue aways contains a string vaue and a reference to the representation of a primitive or derived type whose base type is string. For exampe, a product s Sku number coud be represented by the string vaue: StringVaue("926-AA", Ref(Def_Sku), []) where the Sku type is derived from string:

11 <simpetype name="sku" base="string"> <pattern vaue="\d{3}-[a-z]{2}"/> </simpetype> The accessor type returns a VaueNode s type: type : VaueNode -> Ref(Def_ST) The accessor string returns a VaueNode s string representation: string : VaueNode -> StringVaue The accessor infoitems returns the ist of information items associated with a StringVaue; this ist may contain the character information items from which the string vaue was created: infoitems : StringVaue -> [ Ref(InfoItemNode) ] The accessors ocapart and uripart return a QNameVaue s constituent parts: uripart : QNameVaue -> urireference nu ocapart : QNameVaue -> string The accessor referent returns a ist of eement-node references associated with an IDREFVaue or URIRefVaue: referent : (IDREFVaue URIRefVaue) -> [ Ref(EemNode) NaR ] If a referent is not in the data-mode instance, referent returns NaR, the not a reference vaue. In a data-mode instance of a PSV infoset, every IDREF and keyref vaue is guaranteed to refer to a EemNode in the data-mode instance. This may not be the case for a URI vaue, which coud refer to an eement in an arbitrary document that is not contained in the data-mode instance. In this case, referent may return a ist containing NaR. A VaueNode has fifteen additiona accessors, each of which returns true if the VaueNode is of the specified type. isstringvaue : VaueNode -> booean isboovaue : VaueNode -> booean isfoatvaue : VaueNode -> booean isdoubevaue : VaueNode -> booean isdecimavaue : VaueNode -> booean istimedurvaue : VaueNode -> booean isrecurdurvaue : VaueNode -> booean isbinaryvaue : VaueNode -> booean isurirefvaue : VaueNode -> booean isidvaue : VaueNode -> booean isidrefvaue : VaueNode -> booean isqnamevaue : VaueNode -> booean isentityvaue : VaueNode -> booean isnotationvaue : VaueNode -> booean NOTE: VaueNode repaces the XPath data mode s text node.

12 3.9 Information Items An InfoItemNode has the constructor infoitemnode: infoitemnode : Ref(InfoItem) -> InfoItemNode An InfoItemNode is an opaque vaue that preserves those information items that are not of interest to the data mode or query anguage, but are required by the underying Infoset impementation. It has no accessors. 4 Exampe We use the foowing XML document to iustrate the information contained in an instance of the data mode: <?xm version=1.0?> <p:part xmns:p=" xsi:schemalocation = " name="nutbot"> <mfg>acme</mfg> <price>10.50</price> </p:part> The XML schema for this document is: <xsd:schema xmns:xsd=" targetnamespace=" <xsd:eement name="part" type="part_type"> <xsd:compextype name="part_type"> <xsd:eement name = "mfg" type="xsd:string"/> <xsd:eement name = "price" type="xsd:decima"/> <xsd:attribute name = "name" type="xsd:string"/> </xsd:compextype> </xsd:eement> </xsd:schema> For this exampe, we chose a XML document that incudes an XML Schema to iustrate the reationship between document content and its associated schema type information. In genera, an XML Schema is not required, that is, the data mode can represent a schemaess, we-formed XML document with the defaut typing described in this document. The XML document is represented by the data-mode accessors beow. The vaue D1 represents a DocNode; the vaues E1, E2, etc. represent EemNodes; the vaues A1, etc. represent AttrNodes; the vaues N1, etc. represent NSNodes. chidren(d1) = [ Ref(E1) ] root(d1) = Ref(E1) name(e1) = QNameVaue(" "part", Ref(Def_QName)) chidren(e1) = [ Ref(E2), Ref(E3) ] attributes(e1) = { Ref(A1) } namespaces(e1) = { Ref(N1) }

13 type(e1) parent(e1) name(a1) vaue(a1) parent(a1) prefix(n1) uri(n1) parent(n1) = Ref(Def_part_type) = Ref(D1) = QNameVaue(nu, "name", Ref(Def_QName)) = Ref(StringVaue("nutbot", Ref(Def_string))) = Ref(E1) = Ref(StringVaue("p", Ref(Def_string))) = URIRefVaue(" Ref(Def_uriReference)) = Ref(E1) name(e2) = QNameVaue(nu, "mfg", Ref(Def_QName)) chidren(e2) = [ Ref(StringVaue("Acme", Ref(Def_string))) ] attributes(e2) = {} namespaces(e2) = {} type(e2) = Ref(Def_string) parent(e2) = Ref(E1) name(e3) = QNameVaue(nu, "price", Ref(Def_QName)) chidren(e3) = [ Ref(DecimaVaue(10.50, Ref(Def_decima))) ] attributes(e3) = {} namespaces(e3) = {} type(e3) = Ref(Def_decima) parent(e3) = Ref(E1) A graphica depiction of the data-mode instance, containing the information described in the text above, is aso incuded. Reca that an XML schema is aso an XML document, which can be represented in the data mode. The compex and simpe types in the exampe schema are represented beow: name(def_part_type) = QNameVaue(" "compextype", Ref(Def_QName)) chidren(def_part_type) = [ Ref(E4), Ref(E5), Ref(E6) ] attributes(def_part_type) = { Ref(A2) } namespaces(def_part_type) = {}

14 type(def_part_type) = Ref(Def_compexType) name(a2) = QNameVaue(nu, "name", Ref(Def_QName)) vaue(a2) = Ref(StringVaue("part_type", Ref(Def_NCName), [])) name(e4) = QNameVaue(" "eement", Ref(Def_QName)) chidren(e4) = [] attributes(e4) = { Ref(A3), Ref(A6) } namespaces(e4) = {} type(e4) = Ref(Def_eement) name(a3) = QNameVaue(nu, "name", Ref(Def_QName)) vaue(a3) = Ref(StringVaue("mfg", Ref(Def_NCName), [])) name(a6) vaue(a6) = QNameVaue(nu, "type", Ref(Def_QName)) = Ref(QNameVaue(" "string", Ref(Def_QName), [])) name(e5) = QNameVaue(" "eement", Ref(Def_QName)) chidren(e5) = [] attributes(e5) = { Ref(A4), Ref(A7) } namespaces(e5) = {} type(e5) = Ref(Def_eement) name(a4) vaue(a4) name(a7) vaue(a7) = QNameVaue(nu, "name", Ref(Def_QName)) = Ref(StringVaue("price", Ref(Def_NCName))) = QNameVaue(nu, "type", Ref(Def_QName)) = Ref(QNameVaue(" "decima", Ref(Def_QName), [])) name(e6) = QNameVaue(" "attribute", Ref(Def_QName)) chidren(e6) = [] attributes(e6) = { Ref(A5), Ref(A8) } namespaces(e6) = {} type(e6) = Ref(Def_attribute) name(a5) = QNameVaue(nu, "name", Ref(Def_QName)) vaue(a5) = Ref(StringVaue("name", Ref(Def_NCName), [])) name(a8) vaue(a8) = QNameVaue(nu, "type", Ref(Def_QName)) = Ref(QNameVaue(" "string", Ref(Def_QName), [])) For conciseness, we eiminate the definitions of buitin schema components, e.g., compextype, and of primitive simpe types, e.g., string. 5 Constraints on the Data Mode A data-mode instance must satisfy the foowing constraints: Node references: We assume that the representation of a node reference is defined by the query system that impements the data mode, not by the query anguage itsef. Node references are not seriaized, i.e., they exist ony for use by the query system, and they are not guaranteed to be gobay unique or persistent, athough some impementation of the data mode may choose to support persistent node references. Mutipe techniques may exist for impementing references, and there may be mutipe techniques for impementing

15 identity. Node identity: the function ref is one-to-one and onto, i.e., ref_equa(ref(n1), ref(n2)) hods if and ony if n1 and n2 are the same node. We assume that the operator ref_equa is an impementation-dependent equaity operator over node references. Unique parent: the parent accessor is a many-to-one function, i.e., a node has exacty one parent. Parent-chid reationships: Given two EemNode references ref(p) and ref(n), ref_equa (parent(n), ref(p)) hods if and ony if ref(n) is in chidren(p). Simiary, given a DocNode reference ref(d) and a node reference ref(n), ref_equa(parent (n), ref(d)) if and ony if ref(n) is in chidren(d). Finay, given a AttrNode (or NSNode) reference ref(a) and a node reference ref(n), ref_equa(parent(a), ref(n)) if and ony if ref(a) is in attributes(n) (namespaces(n)). Dupicate-free ist of chidren: Given a node n and any two node references r1 and r2 at distinct positions in chidren(n), not ref_equa(r1, r2) must hod i.e., the ordered ist of chidren nodes is dupicate free. 6 References CLR T. Cormen, C. Leiserson, R. Rivest, Introduction to Agorithms, MIT Press, Knuth D. Knuth, The Art of Computer Programming, Vo. 1, Addison-Wesey, Wader P. Wader, A forma semantics of patterns in XSLT. Avaiabe at: XML Infoset Word Wide Web Consortium, XML Information Set (Infoset). Avaiabe at: XPath Word Wide Web Consortium, XML Path Language (XPath). Avaiabe at: XMLSchema Part 1 Word Wide Web Consortium, XML Schema Part 1 : Structures. Avaiabe at: XMLSchema Part 2 Word Wide Web Consortium, XML Schema Part 2 : Datatypes. Avaiabe at: A XML Information Set Mapping The XML Information Set ( provides a description of the

16 information avaiabe in a we-formed XML document. In this appendix, we define the Infoset in the same notation as the data mode, and we define functions that map from an instance of the Infoset to an instance of the data mode in a pseudo-code notation. Ed. Note: In a future draft of this document, a mapping from the XML Query data mode into the Infoset wi be provided. A.1 Notation and Pseudo-code Syntax We name accessors of the PSV Infoset using the convention psv_<item-name>_<property>. For exampe, psv_eem_attributes is the accessor that returns an eement item s attributes property. The comments in the accessor definitions specify whether a property is core or periphera. The foowing operations are defined on ists and are used in the function definitions: [] constructs the empty ist. [n] constructs a ist with one eement n. h :: t constructs a ist with head eement h and tai ist t. It is often necessary to deconstruct a ist vaue, for exampe, into its head eement and tai ist. We use the same notation to match and deconstruct ist vaues. For exampe, this function maps a "a" vaues in a ist to "b" vaues by deconstructing and matching the argument ist L: fun a2b(l) { case L of [] => [] [ "a" ] :: t => [ "b" ] :: (a2b t) h :: t => h :: (a2b t) } a2b [ "a", "c", "a" ] = [ "b", "c", "b" ] The case expression matches its ist argument L against each ist pattern and evauates the righthand-side of the first pattern that matches L. The function concat_ist concatenates two ists, and concat_string concatenates two strings: concat_ist : ([ U ], [ U ]) -> [ U ] concat_string : (string, string) -> string For exampe, concat_ist [ 1, 2 ] [ 3, 4 ] = [ 1, 2, 3, 4 ] concat_string "First" "Last" = "FirstLast" The function fat_ist takes a ist of ists and returns the fattened ist: fat_ist : [ [ U ] ] -> [ U ] For exampe,

17 fat_ist([ [1], [2, 3] ]) = [ 1, 2, 3 ] The function map_set appies a function to every member of a set and returns the transformed set; map_ist is anaogous for ists: map_set : ((U1 -> U2), { U1 }) -> { U2 } map_ist : ((U1 -> U2), [ U1 ]) -> [ U2 ] For exampe, given the function addone: fun add_one(x) { return x + 1 } map_set add_one { 1, 2 } = { 2, 3 } map_ist add_one [ 1, 2 ] = [ 2, 3 ] A.2 Information Items The basic concept in the Infoset is an InfoItem. An InfoItem is one of ten item types: InfoItem = DocItem EemItem CDATAItem AttrItem NSItem PIItem CommentItem SkipEntityItem EntityMarker CDATAMarker No constructors are defined for Item vaues, because they are constructed by an Infoset processor, not the data mode. A.3 Document Item The foowing accessors are defined on a document information item: /* core */ psv_doc_chidren : DocItem -> [ /* core */ Ref(PIItem) Ref(EemItem) /* periphera */ Ref( CommentItem) Ref(DocTypeItem) ] psv_doc_notations : DocItem-> { Ref(NotationItem) } psv_doc_base_uri : DocItem -> urireference /* core : unparsed entities; periphera : parsed entities */ psv_doc_entities : DocItem -> { Ref(EntityItem) } Exacty one EemItem is required in the psv_doc_chidren ist and it is the root eement of the document tree. The foowing pseudo-code documents the mapping from an instance of the PSV infoset to an instance of the data mode. The function dm_docnode maps a document information item (DocItem) to a document node (DocNode): dm_docnode : DocItem -> DocNode fun dm_docnode(d) { kids = map_ist dm_node (psv_doc_chidren d) return docnode(urivaue(psv_doc_base_uri d, ref(def_urireference)), kids) }

18 In the definition of kids, map_ist appies the function dm_node to each chid of the DocItem vaue d; this constructs a new ist of chidren nodes, each of which has type Node. The appication of the constructor docnode constructs the document node in the data mode. A.4 Eement Items The foowing accessors are defined on eement information items: /* core */ psv_eem_uri : EemItem -> urireference psv_eem_oca_name: EemItem -> string psv_eem_chidren : EemItem -> [ /* core */ Ref(PIItem) Ref(EemItem) Ref(SkipEntityItem) Ref( CDATAItem) /* periphera */ Ref(CommentItem) /* start, end marker pairs : */ (Ref(EntityMarker), Ref(EntityMarker)) (Ref( CDATAMarker), Ref(CDATAMarker)) ] /* core */ psv_eem_attrs : EemItem -> { AttrItem } psv_eem_dec_ns : EemItem -> { NSItem } /* decared namespaces */ psv_eem_base_uri : EemItem -> urireference psv_eem_parent : EemItem -> (Ref(EemItem) Ref(DocItem)) /* Infoset item for schema type */ psv_eem_schema_type : EemItem -> Ref(EemItem) /* periphera */ psv_eem_inscope_ns : EemItem -> { NSItem } /* in-scope namespaces */ The function dm_eemnode maps an EemItem to an EemNode: dm_eemnode : EemItem -> EemNode fun dm_eemnode(e) { name = qnamevaue(psv_eem_uri e, psv_eem_oca_name e, Ref( Def_QName)) nsnodes = map_set dm_nsnode (psv_eem_dec_ns e) attrnodes = map_set dm_attrnode (psv_eem_attrs e) kids = dm_coapse_strings(map_ist dm_node (psv_eem_chidren e)) type = dm_schema_type(psv_eem_schema_type e) newkids = if (issimpetype(type)) (map_ist (dm_coerce_string type) kids) ese kids return eemnode(name, nsnodes, attrnodes, newkids, type) } This function extracts components from the EemItem, transforms them into instances of datamode vaues, and then constructs an EemNode vaue. The function dm_schema_type returns a reference to the Def_T vaue that corresponds to the schema type represented by its information-item argument. dm_schema_type : Ref(EemItem) -> Ref(Def_T)

19 We assume above that if an eement s type is a simpe type, its ist of chidren must contain one string vaue. The function dm_coerce_string coerces its string-vaued second argument into an instance of the simpe type referenced by its first argument. dm_coerce_string : (Ref(Def_ST), StringVaue) -> ST Ed. Note: This mapping does not capture an eement item s keyref vaues, which are maintained in the eement item s identity constraints tabe. The identity constraints tabe is created for bookkeeping purposes by an XML Schema processor (see [XMLSchema Part 1]). The mapping of an eement item s identity constraints tabe into keyref vaues wi be specified in a future draft of this document. The function dm_node maps an information item to a reference to a data-mode node. A information items are preserved in the data mode, but the document type, skipped entity reference, entity markers, and character data markers are represented by the opaque data type InfoItemNode. dm_node : InfoItem -> Ref(Node) fun dm_node(i) { case i of Ref(PIItem e) => ref(dm_pinode e) Ref(EemItem e) => ref(dm_eemnode e) Ref(CommentItem) => ref(dm_commnode e) Ref(CharDataItem e) => ref(dm_char2string e) r as Ref(DocTypeItem) => ref(infoitemnode r) r as Ref(SkipEntityItem) => ref(infoitemnode r) p as (Ref(EntityMarker), Ref(EntityMarker)) => ref(infoitemnode p) p as (Ref(CDATAMarker), Ref(CDATAMarker)) => ref(infoitemnode p) } The function dm_char2string takes one CDATA item and maps it to a StringVaue with a string vaue of ength one. Note that the StringVaue constructor preserves the origina CDATA item in a InfoItemNode. dm_char2string : CDATAItem -> StringVaue fun dm_char2string(c) { /* convert (psv_cdata_code c) to string of ength 1 */ stringvaue(code2string(psv_cdata_code c), Ref(Def_string), [infoitemnode (ref c)]) } The function dm_coapse_strings synthesizes a singe string vaue from mutipe CDATA items. It does this by coapsing one or more consecutive StringVaues in its argument ist, each of which must have the simpe schema type string, into one StringVaue whose content is the concatenation of the vaues of the consecutive StringVaues. A other node vaues are returned unchanged. dm_coapse_strings : [ Ref(Node) ] -> [ Ref(Node) ] fun dm_coapse_strings(nodeist) { case nodeist of : [] => return [] [ n ] => return [ n ] h1 as Ref(StringVaue(s1, Ref(Def_string), i1)) :: t1 => { case t1 of : [] => return [ h1 ]

20 } } /* Coapse two consecutive strings and appy dm_coapse_strings recursivey */ Ref(StringVaue(s2, Ref(Def_string), i2)) :: t2 => return dm_coapse_strings( ref(stringvaue(concat_string(s1, s2), Ref(Def_string), concat_ist(i1, i2))) :: t2) h :: t => return (h :: (dm_coapse_strings t)) A.5 Attribute Items The foowing accessors are defined for attribute information items: /* core */ psv_attr_chidren : AttrItem -> [ Ref(CDATAItem) ] psv_attr_uri : AttrItem -> urireference psv_attr_oca_name : AttrItem -> string psv_attr_owner_eem : AttrItem -> Ref(EemItem) /* Infoset item for schema type */ psv_attr_schema_type : AttrItem -> Ref(EemItem) /* periphera */ psv_attr_type : AttrItem -> string psv_attr_spec_fag : AttrItem -> SpecifiedFag psv_attr_defaut : AttrItem -> [ Ref(CDATAItem) ] psv_attr_start_entity : AttrItem -> Ref(EntityMarker) psv_attr_end_entity : AttrItem -> Ref(EntityMarker) The function dm_attrnode maps an AttrItem to an AttrNode: dm_attrnode : AttrItem -> AttrNode fun dm_attrnode(a) { name = qnamevaue(psv_attr_uri a, psv_attr_oca_name a, ref( Def_QName)) /* An attribute vaue shoud be one string */ vaue = head(dm_coapse_strings(map_ist dm_node (psv_attr_chidren a))) type = dm_schema_type(psv_attr_schema_type a) /* convert vaue to appropriate type */ return attrnode(name, (dm_coerce_string type vaue)) } A.6 Namespace Items The foowing accessors are defined for namespaces: /* core */ psv_ns_prefix : NSItem -> string psv_ns_uri : NSItem -> urireference psv_ns_vaue : NSItem -> [ Ref(CDATAItem) Ref(EntityMarker) ] psv_ns_owner_eem : NSItem -> Ref(EemItem) The function dm_nsnode maps an NSItem to an NSNode: dm_nsnode : NSItem -> NSNode fun dm_nsnode(i) { /* what happens to NS node s CDATA chidren? */

21 } return nsnode(stringvaue(psv_ns_prefix i, ref(def_string), []), urirefvaue(psv_ns_uri i, ref( Def_uriReference)) A.7 Processing Instruction Items The foowing accessors are defined on processing-instruction information items: /* core */ psv_pi_target psv_pi_vaue psv_pi_base_uri psv_pi_parent : PIItem -> string : PIItem -> string : PIItem -> urireference : PIItem -> (Ref(EemItem) Ref(DocItem) Ref(DocTypeItem)) The function dm_pinode maps an PIItem to an PINode: dm_pinode : PIItem -> PINode fun dm_pinode(i) { return pinode(stringvaue(psv_pi_target i, ref(def_ncname), []), stringvaue(psv_pi_vaue i, ref(def_string), [])) } A.8 Comment Items The foowing accessor is defined on comment information items: /* core */ psv_comm_vaue psv_comm_parent : CommentItem -> string : CommentItem -> (Ref(EemItem) Ref(DocItem) Ref(DocTypeItem)) The function dm_commnode maps an CommentItem to an CommentNode: dm_commnode : CommentItem -> CommentNode fun dm_commnode(i) { return commnode(stringvaue(psv_comm_vaue i, ref(def_string), [])) } A.9 Other Information Items The data mode represents document type, skipped entity reference, entity markers, and character data markers as instances of the opaque data type InfoItemNode. For competeness, the foowing accessors are defined for these information items. /* Skip Entity Item : core */ psv_skip_entity_item : SkipEntityItem -> string psv_skip_entity_ref : SkipEntityItem -> Ref(EntityItem) psv_skip_entity_parent : SkipEntityItem -> Ref(EemItem) /* CDATA Item : core */ psv_cdata_code : CDATAItem -> Code psv_cdata_parent : CDATAItem -> Ref(EemItem) /* CDATA Item : periphera */ psv_cdata_whitespace : CDATAItem -> booean

22 psv_cdata_predefined : CDATAItem -> booean /* Document Type Item : periphera */ psv_doctype_entity : DocTypeItem -> Ref(EntityItem) psv_doctype_chidren : DocTypeItem -> [ Ref(CommentItem) Ref(PIItem) ] psv_doctype_parent : DocTypeItem -> Ref(DocItem) /* Entity Item : core */ psv_entity_name : EntityItem -> string psv_entity_sysid : EntityItem -> string psv_entity_pubid : EntityItem -> string psv_entity_notat : EntityItem -> Ref(NotationItem) psv_entity_base_uri : EntityItem -> urireference /* Entity Item : periphera */ psv_entity_type : EntityItem -> string psv_entity_content : EntityItem -> string psv_entity_encoding : EntityItem -> string psv_entity_standaone: EntityItem -> string /* "yes", "no", "notpresent" */ /* Entity Marker : core */ psv_entity_marker_entity : EntityMarker -> Ref(EntityItem) psv_entity_marker_parent : DocTypeItem -> (Ref(EemItem) Ref(AttrItem) Ref(NSItem)) /* Notation Item : core */ psv_notation_name : NotationItem -> string psv_notation_sysid : NotationItem -> string psv_notation_pubid : NotationItem -> string psv_notation_base_uri: NotationItem -> urireference /* CDATA Marker : core */ psv_cdata_marker_parent : CDataMarker -> (Ref(EemItem) Ref(AttrItem) Ref(NSItem)) B Candidate Operators for XML Query Agebra There is a cose correspondence between the data mode and the agebraic operations that are appied to instances of the data mode. In this appendix, we identify those agebraic operators that are candidate operators for the agebra. B.1 Equaity Operators An agebra typicay defines at east one equaity operator for a types in the data mode. We assume the agebra incudes two equaity operators: node_equa and ref_equa, which define equaity on node vaues and on node references. We assume that these operators are provided by the data-mode impementation and conform to the constraints specified in Constraints on the Data Mode. The agebra may define other equaity operators, for exampe, that perform coercions between vaues of different types. B.2 Seriaization Operators In the XPath data mode, every kind of node has an associated string vaue, i.e., a string seriaization of the node s vaue. The data mode aready provides an operator for seriaizing a VaueNode as a string. The agebra aso may incude one or more operators to seriaize a Node as a string:

23 seriaize : Node -> StringVaue One seriaization operator may emit a node vaue in Canonica XML. Other operators may choose other seriaizations. B.3 Order Operators Given an instance of the data mode, an ordering reation on its nodes can be defined. For exampe, document order, i.e., the absoute order of nodes in an input document, is a property that a user of the XML Query Language may want to query. Given a singe input document, a goba, tota order can be defined on nodes. In genera, however, it may not be possibe to define a goba order, for exampe when a data mode instance contains nodes from mutipe input documents. Therefore, it may be usefu and necessary to have mutipe ordering reations, e.g., one that is goba and one that is partia: gobaorder : (Instance, Node) -> IntegerVaue partiaorder : (Instance, Node) -> IntegerVaue Order operators must be defined over a particuar instance of the data mode. The functions return an integer order vaue given an instance of the data mode and a node contained in that instance. B.4 Accessors for Reference Vaues Athough reference vaues are often contained in attribute nodes, they typicay represent eement-to-eement reationships. For convenience, the agebra may define additiona accessor functions that produce the references associated with a particuar eement. For exampe, the idrefs function takes an EemNode and returns a ist of references to eement nodes that are referenced by IDREF vaues in the eement s attribute and chidren components; this accessor is defined in terms of existing accessors: idrefs : EemNode -> [ Ref(EemNode) ] fun idrefs(n) { concat_ist( fat_ist [ referent(v) a <- ist(attributes(n)), v = vaue(a), isidrefvaue(v) ], fat_ist [ referent(c) c <- chidren(n), isidrefvaue(c) ]) ) } The function is defined using a ist comprehension, which is based on a famiiar notation for sets. The second expression above: [ referent(c) c <- chidren(n), isidrefvaue(c) ] is read as foows: return the ist of the referent vaues of each node c such that c is a chid of n and c is a IDREFVaue. Since referent produces a ist, the resut of this expression is a ist of ists: fat_ist takes a ist of ists and returns the fattened ist, and concat_ist concatenates the two ists into one. The attributes accessor returns a set, not a ist, so the ist function converts

24 (non-deterministicay) a set to a ist. The inks accessor is anaogous to idrefs, but returns non-nu URI vaues that occur in the eement s attributes and chidren components; it is defined as: inks : EemNode -> [ Ref(EemNode) ] fun inks(n) { concat_ist( fat_ist [ referent(v) a <- ist(attributes(n)), v = vaue(a), isurirefvaue(v), not( referent(v) = NaR) ], fat_ist [ referent(v) c <- chidren(n), isurirefvaue(c), not(referent(c) = NaR)]) }