This document contains the XPath 2.0 and XQuery 1.0 Issues List that records pre-Last Call issues.
XPath 2.0 and XQuery 1.0 Issues
Values for Status has the following meaning:
resolved: a decision has been finalized and the document updated to reflect the decision.
decided: recommendations and decision(s) has been made by one or more of the following: a task-force, XPath WG, or XQuery WG.
draft: a proposal has been developed for possible future inclusion in a published document.
active: issue is actively being discussed.
unassigned: discussion of issue deferred.
subsumed: issue has been subsumed by another issue.
Cl has the values:
D for Document and Collections
T for basic type issues
TF for types in the context of functions
Priorities prefixed by "o-" are old, unreviewed, priority assignments.
Priority 1 is the highest, 4 is the lowest.
(stylesheet parameters used: kwSort: numeric, kwFull: full, kwDate: 00000000, kwLocus: all).
| Num | Cl | Pr | Cluster | Status | Locus | Description | Responsible |
|---|---|---|---|---|---|---|---|
| 1 | o-1 | grammar | resolved | xpath | XPath Productions | ||
| 2 | o-1 | grammar | subsumed | xquery | Precedence of Operators | ||
| 3 | o-3 | grammar | resolved | xpath | What should be the precedence of a RangeExpr be? | ||
| 4 | o-1 | grammar | resolved | xquery | Abstract Syntax | ||
| 5 | o-2 | reserved-words | resolved | xpath | Reserved words | ||
| 6 | o-2 | reserved-words | subsumed | xpath | 5. Reserved Words: | ||
| 7 | o-1 | reserved-words | subsumed | xquery | Keywords in XQuery | ||
| 8 | o-1 | reserved-words | resolved | xpath | Case-Sensitivity in Keywords | ||
| 9 | o-1 | type-conversions | resolved | xpath | Should implicit conversions be used? | ||
| 10 | o-2 | type-conversions | resolved | xpath | Conversions for Arithmetic | ||
| 11 | o-1 | type-conversions | resolved | xpath | XPath Type Coercions | ||
| 12 | o-2 | arithmetic-operators | resolved | xpath | Arithmetic on Sequences. | ||
| 13 | o-1 | arithmetic-operators | resolved | xpath | Arithmetic operators among sequences | ||
| 14 | o-1 | type-conversions | resolved | xpath | Should type error checking be part of the context? | ||
| 15 | TF | 1 | choice-context | resolved | xpath | Implicit conversion of node-sets to boolean for comparisons. | |
| 16 | o-1 | choice-context | subsumed | xpath | 2. Converting node sets to Boolean | ||
| 17 | o-1 | choice-context | subsumed | xpath | Converting general expressions to Boolean | ||
| 18 | o-1 | choice-context | subsumed | xpath | 1. Arithmetic on node sets | ||
| 19 | o-1 | nulls-empty | resolved | xpath | How should null be treated in the data model? | ||
| 20 | o-1 | nulls-empty | subsumed | xpath | Representation of Missing Data | ||
| 21 | o-1 | nulls-empty | resolved | datamodel | Handling of xsi:nil on Input | ||
| 22 | o-1 | 3-value-logic | resolved | xpath | Three-valued logic | ||
| 23 | o-1 | 3-value-logic | subsumed | xpath | Three-valued Logic | ||
| 24 | o-1 | 3-value-logic | subsumed | xpath | 3. Three-valued logic | ||
| 25 | o-1 | 3-value-logic | subsumed | xpath | Nulls, nil, and three-valued logic | ||
| 26 | o-3 | 3-value-logic | resolved | xpath | Should we default then to return an empty sequence? | ||
| 27 | o-1 | 3-value-logic | subsumed | xpath | IF and WHERE | ||
| 28 | o-1 | 3-value-logic | postponed | xpath | Do we need and3(), or3(), not3() built in? | ||
| 29 | o-1 | 3-value-logic | subsumed | xpath | Not() on Empty Sequence | ||
| 30 | o-2 | 3-value-logic | resolved | xfo | Should comparison operations always return null if either of the arguments are null? | ||
| 31 | o-2 | 3-value-logic | resolved | xpath | Empty sequence comparisons | ||
| 32 | o-1 | for-expr | resolved | xpath | Do we really require for at the XPath expression level? | ||
| 33 | o-2 | for-expr | subsumed | xpath | Do we need a simple form of for? | ||
| 34 | o-3 | for-expr | subsumed | xpath | Does XPath require range variables in for expressions? | ||
| 35 | o-1 | FLWR-expr | resolved | xquery | Separation of clauses in FLWR | ||
| 36 | o-1 | SOME-expr | resolved | xpath | Quantifiers with multiple bindings? | ||
| 37 | o-1 | datatypes | resolved | xpath | 6. Datatypes: | ||
| 38 | o-1 | datatypes | resolved | xfo | XML Schema Datatypes Constructors | ||
| 39 | o-1 | datatype promotions | resolved | xfo | Promotion Hierarchy for XML Schema Types | ||
| 40 | T | 1 | type-semantics | resolved | xquery | Correspondence of Types | |
| 41 | T | 1 | type-semantics | resolved | xquery | Static type-checking vs. Schema validation | |
| 42 | T | 1 | type-semantics | resolved | xquery | Implementation of and conformance levels for static type checking | |
| 43 | T | 1 | type-semantics | decided | xquery | Defining Behavior for Well Formed, DTD, and Schema Documents | |
| 44 | T | 1 | type-semantics | subsumed | xquery | Support for schema-less and incompletely validated documents | |
| 45 | T | 1 | type-semantics | resolved | xquery | Names in Type Definitions | |
| 46 | T | 3 | type-semantics | postponed | xquery | typeof() function | |
| 47 | T | 2 | type-semantics | decided | xquery | Subtype Substitutability | |
| 48 | T | 3 | type-semantics | decided | algebra | CASE not a subtype | |
| 49 | T | 1 | type-semantics | resolved | xquery | Substitution Groups | |
| 50 | TF | 1 | type-semantics | resolved | xquery | Function Definition | |
| 51 | TF | 1 | type-semantics | resolved | xquery | Function Resolution | |
| 52 | o-1 | type-semantics | resolved | xquery | Collection types | ||
| 53 | o-1 | type-semantics | resolved | xquery | Support for Unordered Collections | ||
| 54 | o-1 | type-errors | resolved | xquery | Queries with Invalid Content | ||
| 55 | o-1 | type-errors | resolved | xquery | Static versus Dynamic Errors | ||
| 56 | T | 3 | type-syntax | decided | xquery | Human-Readable Syntax for Types | |
| 57 | T | 3 | type-syntax | postponed | xquery | Inline XML Schema Declarations | |
| 58 | T | 3 | type-syntax | resolved | xquery | Importing Schemas and DTDs into query | |
| 59 | T | 1 | INSTANCEOF-expr | resolved | xpath | We need precise semantics for instanceof. | xquery |
| 60 | o-1 | CAST-expr | resolved | xquery | CAST expression | ||
| 61 | o-3 | CAST-expr | resolved | xpath | Do we need an explicit cast operator (or instead treat as)? | ||
| 62 | o-1 | CAST-expr | resolved | algebra | Mapping CAST AS | ||
| 63 | o-1 | TREAT-expr | resolved | xquery | Type Guard | ||
| 64 | o-1 | TREAT-expr | resolved | algebra | Is TREAT AS necessary? | ||
| 65 | o-1 | CAST/TREAT-expr | resolved | xquery | CAST and TREAT AS Syntax | ||
| 66 | o-1 | TYPESWITCH-expr | resolved | xquery | Typeswitch | ||
| 67 | o-1 | ASSERT-expr | resolved | xquery | Static Type Assertions | ||
| 68 | o-2 | context | resolved | xpath | Do we need a Context Item, and, if so, how should it work? | ||
| 69 | o-1 | context | resolved | xquery | Mapping Input Context | ||
| 70 | o-2 | context | resolved | xpath | Does the context include a default namespace declaration? | ||
| 71 | o-3 | context | resolved | xpath | Do we need a datatype names binding in the context? | ||
| 72 | o-2 | context | resolved | xpath | How should qname-to-collation bindings be handled? | ||
| 73 | o-1 | context | subsumed | xpath | Collation Sequences | ||
| 74 | o-1 | module-semantics | decided | xquery | Module syntax | ||
| 75 | o-1 | module-semantics | decided | xquery | Importing Modules | ||
| 76 | o-1 | module-semantics | resolved | xquery | What is a Query | ||
| 77 | o-1 | module-semantics | resolved | xquery | Namespace Prefix Redefine | ||
| 78 | o-1 | module-syntax | resolved | xquery | Semicolon as Query Module Separator | ||
| 79 | o-1 | module-syntax | decided | xquery | Encoding | ||
| 80 | o-1 | typed-value/data() | resolved | xpath | Accessing Element Data | ||
| 81 | T | 1 | typed-value/data() | resolved | datamodel | What should the typed value of a complex type be? | |
| 82 | o-2 | node-equality | resolved | xfo | What should the semantics be for == and !== in regards to nodesets and sequences? | ||
| 83 | o-1 | sequences | subsumed | xfo | Sequence comparisons need to be defined in the F&O spec. | ||
| 84 | o-1 | sequences | subsumed | xquery | Comparing Collections | ||
| 85 | o-1 | node-equality | resolved | xfo | Identity-based equality operator | ||
| 86 | o-2 | node-equality | resolved | xpath | Set operations based on value | ||
| 87 | o-2 | value-identity | resolved | xfo | What is the identity of a simple value? | ||
| 88 | o-1 | (in)equality-operators | resolved | xpath | 8. Implied existential quantifiers: | ||
| 89 | o-1 | (in)equality-operators | subsumed | xpath | Comparing Sequences | ||
| 90 | o-1 | (in)equality-operators | subsumed | xpath | Node-set comparisons | ||
| 91 | o-1 | (in)equality-operators | resolved | xpath | 9. String comparisons: | ||
| 92 | o-1 | (in)equality-operators | resolved | xpath | Deep equality | ||
| 93 | o-1 | (in)equality-operators | subsumed | xpath | 4. Element-equality: | ||
| 94 | o-1 | (in)equality-operators | subsumed | xpath | Node equality | ||
| 95 | o-1 | (in)equality-operators | resolved | xpath | Equality will not be compatible with some string conversions | ||
| 96 | o-1 | (in)equality-operators | decided | xpath | Normalized Equality | ||
| 97 | o-2 | error | resolved | xpath | How should the error object be supported? | ||
| 98 | o-2 | error | resolved | xpath | General discussion of errors | ||
| 99 | o-1 | error | resolved | xquery | TRY/CATCH and error() | Dana | |
| 100 | o-1 | datamodel | resolved | datamodel | Should an empty sequence and an empty node-set be distinguishable? | ||
| 101 | o-1 | datamodel | resolved | datamodel | Should sequences be allowed to have nodes? | ||
| 102 | o-1 | function-app | resolved | xpath | Functions on Empty Sequences | ||
| 103 | o-1 | function-app | resolved | xpath | Functions on Sequences | ||
| 104 | o-1 | function-app | subsumed | xquery | Sequences for single parameters | ||
| 105 | o-1 | function-app | resolved | xpath | Implicit current node for functions? | ||
| 106 | o-2 | function-app | subsumed | xpath | Problem with default context node for functions? | ||
| 107 | o-1 | function-app | resolved | xpath | Path iteration | ||
| 108 | o-1 | function-app | resolved | xpath | Aggregate functions on empty sequences. | ||
| 109 | o-3 | syntax | resolved | xpath | Need text to disambiguate Lexical Structure? | ||
| 110 | o-4 | syntax | resolved | xpath | Should we use is and isnot instead of == and !==. | ||
| 111 | o-3 | syntax | resolved | xpath | What is the best sequence concatenation operator? | ||
| 112 | o-1 | syntax | resolved | xpath | Leading Minus | ||
| 113 | o-1 | axes | resolved | xpath | What should the mechanism be for axis subsetting? | ||
| 114 | o-1 | axes | decided | xquery | XPath Axes | ||
| 115 | o-1 | path-semantics | resolved | xpath | General Expressions in Path Steps | ||
| 116 | o-1 | path-semantics | subsumed | algebra | Full Expression Syntax in Steps | ||
| 117 | o-4 | path-semantics | resolved | xpath | Disallow variables on right side of slash? | ||
| 118 | o-4 | path-semantics | resolved | xpath | Disallow obvious non-node sequences on left of slash? | ||
| 119 | o-4 | path-semantics | resolved | xpath | Should nonsense nodetests be disallowed? | ||
| 120 | o-1 | path-semantics | resolved | xpath | 7. Duplicates and ordering: | ||
| 121 | o-1 | path-semantics | subsumed | xquery | Path Expression Order | ||
| 122 | o-1 | path-semantics | subsumed | xpath | Duplicates and ordering | ||
| 123 | o-1 | serialization | resolved | xquery | Linearization/Serialization | ||
| 124 | o-1 | functions | decided | xquery | External Functions | ||
| 125 | o-4 | editorial | resolved | xpath | Should we say something about the abstractness of XPath? | ||
| 126 | o-4 | editorial | resolved | xpath | Should we re-explain path expressions? | ||
| 127 | o-1 | operators | resolved | xpath | Definitions of Operators | ||
| 128 | o-1 | operators | resolved | xfo | Operators and functions | ||
| 129 | o-2 | algebra | resolved | xquery | Alignment of Syntax | ||
| 130 | o-1 | xquery-alignment | resolved | algebra | Algebra Mapping | Jerome | |
| 131 | o-1 | xquery-alignment | resolved | algebra | Alignment of Precedence | ||
| 132 | o-1 | attribute accessors | resolved | xfo | Attribute Name, Attribute Content | ||
| 133 | o-1 | (de)reference-expr | resolved | xquery | Reference Constructor | ||
| 134 | o-1 | (de)reference-expr | resolved | xquery | Dereference Operator and Links | ||
| 135 | o-1 | constructor-syntax | resolved | algebra | Empty End Tags in Element Constructors | ||
| 136 | o-2 | constructor-syntax | resolved | xquery | Lists of Element Constructors | ||
| 137 | o-1 | constructor-syntax | resolved | xquery | Attribute Constructor Function | ||
| 138 | o-1 | constructor-syntax | resolved | xquery | Quotes for computed attribute values | ||
| 139 | o-1 | constructor-syntax | resolved | xquery | Computed element and attribute names | ||
| 140 | o-1 | constructor-syntax | subsumed | xquery | Alternative syntax for element construction | ||
| 141 | o-1 | constructor-syntax | resolved | xquery | Productions for Comments and Processing Instructions | ||
| 142 | o-1 | constructor-syntax | subsumed | xquery | Comments to end-of-line | ||
| 143 | o-1 | constructor-syntax | postponed | algebra | XML Constructor | ||
| 144 | o-1 | syntax | decided | xquery | Escaping Quotes and Apostrophes | ||
| 145 | o-1 | constructor-expr | subsumed | xquery | Copy and Reference Semantics | ||
| 146 | o-1 | constructor-expr | resolved | xquery | |||
| 147 | o-1 | constructor-expr | resolved | xquery | Empty Attributes | ||
| 148 | o-1 | constructor-expr | resolved | xquery | Namespace Attributes in Element Constructors | xquery | |
| 149 | o-1 | literal-XML | resolved | xquery | Embedding XML in XQuery | ||
| 150 | o-1 | literal-XML | subsumed | xquery | Embedding XQuery in XML | ||
| 151 | o-1 | literal-XML | resolved | xquery | Cutting and pasting XML into XQuery | ||
| 152 | o-1 | xqueryx | decided | xqueryx | XML-based Syntax | ||
| 153 | o-1 | xqueryx | postponed | xquery | Escape between syntaxes | ||
| 154 | o-1 | sort | resolved | xquery | Ordering of empty values. | ||
| 155 | o-1 | sort | decided | xquery | Sorting by Non-exposed Data | ||
| 156 | o-1 | BEFORE/AFTER-expr | resolved | xpath | Meaning of BEFORE and AFTER | ||
| 157 | o-1 | functions | decided | xquery | Function Libraries | ||
| 158 | o-1 | functions | resolved | xquery | Unqualified Function Names | ||
| 159 | o-1 | functions | resolved | algebra | Recursion | ||
| 160 | o-2 | execution-model | resolved | xquery | Naive Implementation Strategy | ||
| 161 | o-1 | fusion | abandoned | xquery | Fusion | ||
| 162 | o-1 | filter | resolved | algebra | Filter as a Function | ||
| 163 | o-1 | filter | resolved | algebra | Typing of Filter | Jerome Simeon | |
| 164 | o-1 | updates | resolved | xquery | Updates | Jonathan | |
| 165 | o-1 | views | resolved | algebra | View Definition | ||
| 166 | o-1 | miscellaneous | resolved | xquery | Excluding Undesired Elements | ||
| 167 | o-1 | miscellaneous | resolved | algebra | Eval | ||
| 168 | o-1 | groupby | resolved | xquery | GROUPBY | ||
| 169 | o-1 | conformance | resolved | xquery | Missing conformance section | ||
| 170 | D | 1 | documents | resolved | xquery | Document collections | |
| 171 | o-1 | path-semantics | resolved | xpath | Operands of "/" | ||
| 172 | T | 2 | typed-value/data() | resolved | xpath | Some functions taking node sequences and implicitly map? | |
| 173 | o-1 | type exception | resolved | xpath | Polymorphic operator; only one fallback? | ||
| 174 | T | 1 | type exception | resolved | xpath | Support for UnknownSimpleType | |
| 175 | o-2 | 3-value-logic | subsumed | xpath | What should "not3()" be called? | ||
| 176 | o-1 | choice-context | resolved | xpath | What is a node sequence? | ||
| 177 | TF | 2 | choice-context | abandoned | xpath | Consistency of functions that take boolean formal argument | |
| 178 | o-1 | type-conversions | resolved | xpath | Semantics of positional predicates in XPath | ||
| 179 | o-1 | type-conversion | resolved | xpath | Function call rules needed | ||
| 180 | o-1 | functions | resolved | xpath | Functions expecting complex-valued arguments | ||
| 181 | o-1 | type-system | resolved | xpath | Should literals include integers & integer be treated as primitive type? | ||
| 182 | o-1 | operators | resolved | xpath | Mapping XPath Operators to F&O Functions | ||
| 183 | T | 1 | text-nodes | resolved | xpath | Text nodes - lexical structure and typed form | |
| 184 | T | 3 | node-types | resolved | xpath | Need ability to test for Comments, PIs | xquery |
| 185 | o-2 | type exception | resolved | xpath | Always explicit cast? | ||
| 186 | o-1 | node order | resolved | xpath | Ordering of result of union, intersect, and except operators | ||
| 187 | o-1 | operators | subsumed | xfo | Operations supported on date/time types | ||
| 188 | o-1 | operators | resolved | xpath | Comparison operators - concrete syntax | ||
| 189 | o-1 | operators | resolved | xpath | Supported combinations of types for comparison operators | ||
| 190 | o-1 | operators | resolved | xpath | Operators for order comparisons | ||
| 191 | o-1 | whitespace | decided | xquery | Whitespace handling in element constructors | ||
| 192 | T | 2 | type constructed element | resolved | xquery | Type of a newly constructed element | |
| 193 | T | 2 | xml non representable | resolved | xquery | Construction of non representable XML | |
| 194 | o-1 | sort | resolved | xquery | Support for stable and unstable sort? | ||
| 195 | o-1 | sort | resolved | xquery | Semantics of sorting heterogeneous sequences | ||
| 196 | T | 2 | types | resolved | xpath | Concrete syntax for datatype declarations | xquery |
| 197 | T | 2 | types | resolved | xpath | Need "attribute of type"? | xquery |
| 198 | T | 3 | types | resolved | xpath | Syntax for named typing | xquery |
| 199 | T | 2 | types | resolved | xpath | Support for locally declared types? | xquery |
| 200 | T | 1 | types | postponed | xpath | Semantics of "only" | xquery |
| 201 | o-1 | namespaces | resolved | xquery | Scope of namespace declaration | ||
| 202 | o-1 | namespaces | resolved | xquery | In-scope namespaces and bindings | ||
| 203 | o-1 | namespaces | resolved | xquery | Non declared namespace prefix | ||
| 204 | o-1 | namespaces | resolved | xquery | How do default element namespaces affect attributes | ||
| 205 | TF | 1 | types | resolved | xquery | Default function parameter type | |
| 206 | T | 2 | types | decided | xpath | Typing support in XPath | |
| 207 | o-1 | variables | resolved | xpath | Variable names: QNames or NCnames? | ||
| 208 | o-1 | syntax curly brace | resolved | xquery | Multiple curly braces allowed? | xquery | |
| 209 | o-1 | syntax attribute values | resolved | xquery | Syntax for attribute values - more than one? | xquery | |
| 210 | o-1 | order sequences | postponed | xpath | Order of sequences | ||
| 211 | T | 1 | types | resolved | xpath | Treat and structural vs named typing | xquery |
| 212 | o-1 | syntax | resolved | xpath | Is "datatype" a suitable production name? | xquery | |
| 213 | o-1 | syntax quotes | resolved | xpath | How to get quotes etc in string literals? | ||
| 214 | o-1 | syntax strings in attributes | resolved | xquery | Strings in attributes | xquery | |
| 215 | o-1 | 3-value-logic | postponed | xpath | Should we have a 3-valued form of quantifiers? | ||
| 216 | o-1 | focus | abandoned | xpath | Description of focus is very procedural | ||
| 217 | o-1 | focus | resolved | xpath | Context document in focus | ||
| 218 | o-1 | wildcards | resolved | xpath | What wildcards; namespaceprefix? | xquery | |
| 219 | o-1 | namespaces | resolved | xquery | Context: namespaces | ||
| 220 | o-1 | sort | subsumed | xpath | Should there be a way to explicitly sort in document order? | ||
| 221 | o-1 | namespaces | resolved | xquery | Where should namespace prefixes apply? | ||
| 222 | o-1 | namespaces | resolved | xquery | Allow redefinition of namespace prefixes? | ||
| 223 | o-1 | functions external | decided | xquery | We need a way to declare external functions | ||
| 224 | T | 2 | types | decided | xquery | Why do we want to allow optional returns and DataType? | |
| 225 | o-1 | variables | resolved | xpath | Variable redefinition allowed? | ||
| 226 | o-1 | existential expressions | resolved | xpath | Existential Expressions | ||
| 227 | o-2 | syntax dereference | resolved | xpath | Syntax for dereference? | ||
| 228 | o-2 | namespace functions | decided | xpath | Should we keep the default function namespace, and the xf: namespace? | ||
| 229 | o-2 | syntax | resolved | xpath | Do we need both << and precedes? | ||
| 230 | D | 1 | context | resolved | xpath | Context document adequate for multiple docuemnts? | |
| 231 | o-1 | fallback | resolved | xpath | data(SimpleValue) is error or no-op? | ||
| 232 | o-1 | syntax operators date | resolved | xpath | Use "+" and "-" on dates and durations? | ||
| 233 | o-1 | syntax | resolved | xquery | Simpler FLWR syntax? | ||
| 234 | o-1 | order sequences | resolved | xpath | Who defines sorting order of ()? | ||
| 235 | o-1 | syntax | resolved | xpath | Need parenthesis in conditional expression? | ||
| 236 | o-1 | syntax | resolved | xpath | SimpleType preceded by a keyword? | xquery | |
| 237 | o-1 | syntax | resolved | xquery | Need parenthesis in type switch expression? | ||
| 238 | o-1 | consistency | resolved | xpath | Consistency: tradeoff between interoperability and efficiency | ||
| 239 | o-1 | consistency | resolved | xpath | Consistency: bracketing of nested expressions | ||
| 240 | o-1 | consistency | resolved | xpath | Consistency: parenthesizing test expressions | ||
| 241 | o-1 | consistency | resolved | xpath | Consistency: keywords | ||
| 242 | 3 | sort | resolved | xquery | Sortby on partially ordered values? | ||
| 243 | 3 | sort | decided | xpath | Provide an example of sorting "disappearing" | ||
| 244 | 2 | serialization | decided | xquery | CDATA sections and serialization | ||
| 245 | 2 | syntax curly brace | resolved | xquery | Are {} in text evaluated? | ||
| 246 | 2 | syntax | decided | xquery | Nested XQuery comments allowed? | ||
| 247 | 2 | namespaces | decided | xpath | What does default namespace(s) affect? | ||
| 248 | 4 | evaluate | postponed | xpath | Evaluate function | ||
| 249 | 4 | higher-order-functions | postponed | xpath | Higher-order functions | ||
| 250 | 2 | variables | decided | xquery | Declaring Variables in Prolog | ||
| 251 | 2 | sort | decided | xquery | Sorting "input to loop", not the result | ||
| 252 | 2 | consistency | resolved | xquery | "sort by" rather than "sortby" for consistency? | ||
| 253 | TF | 2 | type-semantics | resolved | xpath | CAST as simple type of a node type | |
| 254 | 2 | grammar | resolved | xpath | Should the lexical details be in document? | ||
| 255 | T | 1 | type-semantics | resolved | xpath | What are the operators on a derived type? | |
| 256 | D | 1 | collections | resolved | xpath | What is return type of colections? | |
| 257 | D | 1 | collections | decided | xpath | Does collection() always return same result? | |
| 258 | D | 2 | documents | decided | xpath | Identity of Document Nodes | |
| 259 | T | 1 | type-semantics | resolved | xpath | Arithmetic operation rules for unknown simpletype | |
| 260 | T | 2 | type-semantics | resolved | xpath | Implicit data() on instanceof? | |
| 261 | 2 | syntax quotes | resolved | xquery | Quoting rules in nested expressions in attribute value construction | ||
| 262 | T | 1 | type-semantics | resolved | xpath | Definition of data() on elements with known complex type | |
| 263 | T | 1 | type-semantics | resolved | xpath | Definition of data() on elements with unknown type, whose content may be simple or complex | |
| 264 | 1 | variables | resolved | xpath | Shadowing of Variables | ||
| 265 | 2 | FTTF-xml:lang | decided | xpath-fulltext | How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node? | ||
| 266 | 2 | FTTF-xml:lang | decided | xpath-fulltext | Do we support the sublanguage portion of xml:lang? | ||
| 267 | 1 | syntax | resolved | xpath | Syntax problems with "validate" | ||
| 268 | T | 1 | type-semantics | resolved | xpath | xsd:string and anySimpleType'd data behave the same? | |
| 269 | T | 1 | type-semantics | resolved | xpath | Can we get rid of the unknown keyword | |
| 270 | T | 1 | type-semantics | resolved | xpath | Typing, coercions, and conformance | |
| 271 | T | 1 | type-semantics | resolved | xpath | Type compatibility of heterogeneous union types | |
| 272 | 1 | external-functions | decided | xpath | External Functions | ||
| 273 | 1 | external-objects | decided | xpath | External Objects | ||
| 274 | T | 1 | type-semantics | resolved | xpath | Text-node-only implementation possible? | |
| 275 | T | 1 | type-semantics | resolved | xpath | Should validation also check identity constraints? | |
| 276 | T | 1 | type-semantics | resolved | xpath | Does validation introduce new xsi:type attributes? | |
| 277 | T | 1 | type-semantics | resolved | xpath | Should validate introduce xsi:type? | |
| 278 | T | 1 | type-semantics | resolved | xpath | Does //@xsi:type match an xsi:type attribute? | |
| 279 | T | 1 | type-semantics | decided | xpath | Should there be a lightweight cast? | |
| 280 | T | 1 | type-semantics | resolved | xpath | Do we need to distinguish atomic simple types and list simple types? | |
| 281 | T | 1 | type-semantics | resolved | xpath | Representing the type name of untyped character data | |
| 282 | T | 1 | type-semantics | resolved | xpath | xs:numeric type | |
| 283 | 1 | syntax-productions | resolved | xpath | Is the DocumentElement syntax production necessary? | ||
| 284 | T | 1 | type-semantics | resolved | xpath | Static Named Typing | |
| 285 | T | 1 | type-semantics | resolved | xpath | Is the QName denoting type information optional or required? | |
| 286 | 1 | constructor-expr | decided | xquery | Element Construction vs Streaming | ||
| 287 | 1 | syntax | resolved | xpath | Functional Status of Comma | ||
| 288 | 1 | constructor-expr | resolved | xquery | Element Constructor Attribute Order | ||
| 289 | T | 1 | constructor-expr | resolved | xquery | Attribute Value Construction from Elements | |
| 290 | 1 | constructor-expr | decided | xquery | Element Attribute Constructor Name Type | ||
| 291 | T | 1 | constructor-expr | resolved | xquery | Element Construction anySimpleType Sequence Content | |
| 292 | 1 | constructor-expr | resolved | xquery | Element Construction Sequence vs Multi-expr | ||
| 293 | 1 | decided | xquery | Cdata and CharRef Semantics | |||
| 294 | T | 1 | type-semantics | resolved | xquery | Should all elements and attributes have type annotations? | |
| 295 | 1 | lexical-representation | decided | xquery | Lexical Representation of Atomic Values | ||
| 296 | 1 | path-semantics | resolved | xpath | What is definition of leading "/"? | ||
| 297 | T | 1 | types | decided | xpath | Should XPath have "type binding" in variable? | |
| 298 | T | 1 | types | resolved | xpath | Add Schema type names for sequences of homogeneous types? | |
| 299 | 1 | whitespace | resolved | xquery | Does character reference to whitespace change whitespace handling? | ||
| 300 | 1 | sort | resolved | xquery | Should sorting of untyped data be prohibited? | ||
| 301 | T | 1 | types | resolved | xpath | Supporting SQL/XML mappings in Basic XQuery | |
| 302 | T | 1 | types | resolved | xpath | Support for arbitrary XML documents | |
| 303 | T | 1 | types | resolved | xpath | Define "scale-down" mappings? | |
| 304 | T | 1 | types | resolved | xpath | Declare required conformance features? | |
| 305 | T | 1 | types | resolved | xpath | Schema Import Feature prerequisite for Static Typing Feature? | |
| 306 | T | 1 | types | resolved | xpath | PSVI to Data Model mapping part of normative text? | |
| 307 | T | 1 | types | decided | xpath | Schema Types from input documents? | |
| 308 | T | 1 | types | decided | xpath | Type Soundness | |
| 309 | T | 1 | types | resolved | xpath | What should be the type of an error value? | |
| 310 | T | 1 | types | decided | xquery | Are the children of a newly constructed element typed? | |
| 311 | 1 | whitespace | decided | xquery | Whitespace and Attribute Constructors | ||
| 312 | T | 1 | types | resolved | xquery | What to do about list types? | |
| 313 | T | 1 | types | resolved | xquery | What to do about union types? | |
| 314 | T | 1 | types | subsumed | xquery | Partial support for SCHEMA IMPORT in Basic XQuery? | |
| 315 | 1 | syntax | resolved | xpath | Whitespace allowed in the name of a variable! | ||
| 316 | T | 1 | types | decided | xpath | Is anySimpleType = anySimpleType*? | |
| 317 | 1 | extensions | decided | xquery | XQuery Extension Mechanisms | ||
| 318 | 1 | sort | decided | xquery | Add 'order by' clause to FLWR? | ||
| 319 | 1 | namespaces | decided | xquery | Namespace definitions and in-scope namespaces | ||
| 320 | T | 1 | types | decided | xquery | Should different conformance levels give the same result for the same query and data? | |
| 321 | 1 | validate | decided | xquery | Is validate strict or lax? | ||
| 322 | 1 | validate | decided | xquery | "validate" strict/lax override? | ||
| 323 | 1 | resolved | xpath | Should "unordered" be included in XPath? | |||
| 324 | 1 | variables | resolved | xquery | How can variables be bound external to XQuery itself? | ||
| 325 | T | 1 | types | decided | xpath | Refering to element that is not in the in-scope schema def. | |
| 326 | T | 1 | types | subsumed | xpath | Semantics of element foo of type T | |
| 327 | 1 | functions | decided | xpath | Evaluate unused function parameters? | ||
| 328 | 1 | cdata section | decided | xquery | What does CDATA section constructor construct? | ||
| 329 | 1 | constructors | decided | xquery | Duplicate attribute constructors | ||
| 330 | T | 1 | types | resolved | xquery | Should "some" do type filtering? | |
| 331 | T | 1 | types | resolved | xpath | Static vs. dynamic dispatch for arithmetics | |
| 332 | 1 | types | resolved | xpath | Schema Import, Static Typing: what is interoperable? | ||
| 333 | 1 | conformance | subsumed | xpath | Optional Features vs. Conformance Levels | ||
| 334 | T | 1 | type-semantics | decided | xpath | How are documents for which validation has failed processed? | |
| 335 | 1 | formal-semantics | decided | xpath | XPath/XQuery's current semantics greatly interferes with optimization | ||
| 336 | 1 | editorial | postponed | all | Markup in documents for errors | ||
| 337 | 1 | editorial | postponed | all | Add markup in documents for errors | ||
| 338 | 1 | whitespace | decided | xquery | Handling of whitespace and character references | ||
| 339 | 2 | errors | decided | xquery | Error type for attributes constructed too late | ||
| 340 | 1 | errors | decided | xpath | How to identify errors? | ||
| 341 | 1 | syntax | decided | xpath | Problems with SequenceType | ||
| 342 | o-1 | grammar | resolved | xquery | Prolog syntax | ||
| 343 | 1 | namespaces | decided | xpath | Do functions in the null namespace clash with functions in the default namespace? | ||
| 344 | 1 | resolved | formal-semantics | Attributes | |||
| 345 | 1 | resolved | formal-semantics | Namespaces | |||
| 346 | 1 | resolved | formal-semantics | Document Order | |||
| 347 | 1 | resolved | formal-semantics | References vs containment | |||
| 348 | 1 | resolved | formal-semantics | Element identity | |||
| 349 | 1 | resolved | formal-semantics | Source and join syntax instead of "for" | |||
| 350 | 1 | resolved | formal-semantics | References: IDREFS, Keyrefs, Joins | |||
| 351 | 1 | resolved | formal-semantics | Fixed point operator or recursive functions | |||
| 352 | 1 | resolved | formal-semantics | Externally defined functions | |||
| 353 | 1 | resolved | formal-semantics | Construct values by copy | |||
| 354 | 1 | Static typing | resolved | formal-semantics | XPath tumbler syntax instead of index? | ||
| 355 | 1 | resolved | formal-semantics | GroupBy - needs second order functions? | |||
| 356 | 1 | resolved | formal-semantics | Collations | |||
| 357 | 1 | resolved | formal-semantics | Polymorphic types | |||
| 358 | 1 | resolved | formal-semantics | 3-valued logic to support NULLs | |||
| 359 | 1 | resolved | formal-semantics | Mixed content | |||
| 360 | 1 | resolved | formal-semantics | Unordered content | |||
| 361 | 1 | resolved | formal-semantics | Align algebra types with schema | |||
| 362 | 1 | resolved | formal-semantics | Support derived types | |||
| 363 | 1 | resolved | formal-semantics | Structural vs. name equivalence | |||
| 364 | 1 | resolved | formal-semantics | Syntax | |||
| 365 | 1 | resolved | formal-semantics | Indentation, Whitespaces | |||
| 366 | 1 | resolved | formal-semantics | Catch exceptions and process in algebra? | |||
| 367 | 1 | resolved | formal-semantics | Value for empty sequences | |||
| 368 | 1 | resolved | formal-semantics | Treatment of empty results at type level | |||
| 369 | 1 | resolved | formal-semantics | Project - one tag only | |||
| 370 | 1 | resolved | formal-semantics | Case syntax | |||
| 371 | 1 | resolved | formal-semantics | Fusion | |||
| 372 | 1 | resolved | formal-semantics | Views | |||
| 373 | 1 | resolved | formal-semantics | Automatic type coercion | |||
| 374 | 1 | resolved | formal-semantics | Recursive functions | |||
| 375 | 1 | resolved | formal-semantics | Full regular path expressions | |||
| 376 | 1 | resolved | formal-semantics | Metadata Queries | |||
| 377 | 1 | resolved | formal-semantics | Fusion | |||
| 378 | 1 | resolved | formal-semantics | Exception handling | |||
| 379 | 1 | resolved | formal-semantics | Global-order based operators | |||
| 380 | 1 | resolved | formal-semantics | Copy vs identity semantics | |||
| 381 | 1 | resolved | formal-semantics | Copy by reachability | |||
| 382 | 1 | resolved | formal-semantics | Dereferencing semantics | |||
| 383 | 1 | resolved | formal-semantics | Case Syntax | |||
| 384 | 1 | resolved | formal-semantics | Sorting | |||
| 385 | 1 | resolved | formal-semantics | GroupBy | |||
| 386 | 1 | resolved | formal-semantics | Recursive Descent for XPath | |||
| 387 | 1 | resolved | formal-semantics | Keys and IDREF | |||
| 388 | 1 | resolved | formal-semantics | Global Order | |||
| 389 | 1 | resolved | formal-semantics | FOR Syntax | |||
| 390 | 1 | resolved | formal-semantics | Attributes | |||
| 391 | 1 | resolved | formal-semantics | Explicit Type Declarations | |||
| 392 | 1 | resolved | formal-semantics | Unordered Collections | |||
| 393 | 1 | resolved | formal-semantics | Recursive Descent for XPath | |||
| 394 | 1 | resolved | formal-semantics | Project redundant? | |||
| 395 | 1 | resolved | formal-semantics | Axes of XPath | |||
| 396 | 1 | resolved | formal-semantics | Global vs. local elements | |||
| 397 | 1 | resolved | formal-semantics | Global vs. local complex types | |||
| 398 | 1 | resolved | formal-semantics | Types with non-wellformed instances | |||
| 399 | 1 | resolved | formal-semantics | Operators on Simple Types | |||
| 400 | 1 | resolved | formal-semantics | More precise type system; choice in path | |||
| 401 | 1 | resolved | formal-semantics | Downward Navigation only? | |||
| 402 | 1 | resolved | formal-semantics | Testing Subtyping | |||
| 403 | 1 | resolved | formal-semantics | Internationalization aspects for strings | |||
| 404 | 1 | resolved | formal-semantics | Model for References | |||
| 405 | 1 | resolved | formal-semantics | Open questions for constructing elements by reference | |||
| 406 | 1 | resolved | formal-semantics | Do we need (user defined) higher order functions? | |||
| 407 | 1 | resolved | formal-semantics | Error code handling in Query Algebra | |||
| 408 | 1 | resolved | formal-semantics | Built-In GroupBy? | |||
| 409 | 1 | resolved | formal-semantics | Shallow or Deep Equality? | |||
| 410 | 1 | resolved | formal-semantics | Runtime Casts | |||
| 411 | 1 | resolved | formal-semantics | Document Collections | |||
| 412 | 1 | resolved | formal-semantics | Organization of Document | |||
| 413 | 1 | resolved | formal-semantics | Stable vs. Unstable Sort/Distinct | |||
| 414 | 1 | resolved | formal-semantics | Alignment with the XML Query Datamodel | |||
| 415 | 1 | Language | resolved | formal-semantics | Facet value access in Query Algebra | ||
| 416 | 1 | Static typing | resolved | formal-semantics | Facets for simple types and their role for typechecking | ||
| 417 | 1 | resolved | formal-semantics | Operational semantics for expressions | |||
| 418 | 1 | resolved | formal-semantics | Overloading user defined functions | |||
| 419 | 1 | resolved | formal-semantics | Unordered types | |||
| 420 | 1 | resolved | formal-semantics | Interleaved repetition and closure | |||
| 421 | 1 | resolved | formal-semantics | Generation of ambiguous types | |||
| 422 | 1 | resolved | formal-semantics | Global order between nodes in different documents | |||
| 423 | 1 | Static typing | postponed | formal-semantics | Typing of parent | ||
| 424 | 1 | resolved | formal-semantics | Lexical representation of Schema simple types | |||
| 425 | 1 | resolved | formal-semantics | Type and expression operator precedence | |||
| 426 | 1 | resolved | formal-semantics | Expressive power and complexity of typeswitch expression | |||
| 427 | 1 | resolved | formal-semantics | Execution model | |||
| 428 | 1 | resolved | formal-semantics | Semantics of Wildcard type | |||
| 429 | 1 | resolved | formal-semantics | Syntactic rules | |||
| 430 | 1 | resolved | formal-semantics | More examples of Joins | |||
| 431 | 1 | resolved | formal-semantics | Align [XPath/XQuery] types with XML Schema : Formal Description. | |||
| 432 | 1 | subsumed | formal-semantics | Syntax for types in XQuery | |||
| 433 | 1 | resolved | formal-semantics | Static type-assertion expression | |||
| 434 | 1 | resolved | formal-semantics | Attribute expression | |||
| 435 | 1 | resolved | formal-semantics | Error expression | |||
| 436 | 1 | resolved | formal-semantics | Representation of Text Nodes in type system | |||
| 437 | 1 | Semantics | resolved | formal-semantics | Static type errors and warnings | ||
| 438 | 1 | resolved | formal-semantics | Importing Schemas and DTDs into query | |||
| 439 | 1 | resolved | formal-semantics | Support for schema-less and incompletely validated documents | |||
| 440 | 1 | resolved | formal-semantics | Static type-checking vs. Schema validation | |||
| 441 | 1 | Semantics | decided | formal-semantics | Implementation of and conformance levels for static type checking | ||
| 442 | 1 | resolved | formal-semantics | Incomplete/inconsistent mapping from [XPath/XQuery] to core | |||
| 443 | 1 | Semantics? | resolved | formal-semantics | Namespace resolution | ||
| 444 | 1 | resolved | formal-semantics | Support for mixed content in the type system | |||
| 445 | 1 | resolved | formal-semantics | Indentation, Whitespace | |||
| 446 | 1 | Typing | resolved | formal-semantics | Complexity of interleaving | ||
| 447 | 1 | resolved | formal-semantics | Support for named typing | |||
| 448 | 1 | resolved | formal-semantics | Types for nodes in the data model. | |||
| 449 | 1 | Typing | resolved | formal-semantics | Constraint on attribute and element content models | ||
| 450 | 1 | Semantics | decided | formal-semantics | Semantics of data() | ||
| 451 | 1 | resolved | formal-semantics | Principal node types in XPath | |||
| 452 | 1 | Semantics | decided | formal-semantics | Semantics of order by | ||
| 453 | 1 | Semantics | resolved | formal-semantics | Semantics of element and attribute constructors | ||
| 454 | 1 | resolved | formal-semantics | Semantics of instance of ... only | |||
| 455 | 1 | Static typing | resolved | formal-semantics | Typing for the typeswitch default clause | ||
| 456 | 1 | Semantics | resolved | formal-semantics | Incomplete specification of type conversions | ||
| 457 | 1 | Semantics | resolved | formal-semantics | Dynamic context for current date and time | ||
| 458 | 1 | Language | decided | formal-semantics | What is in the default context? | ||
| 459 | 1 | Language | resolved | formal-semantics | Serialization | ||
| 460 | 1 | Language | resolved | formal-semantics | Data model constructor for error values | ||
| 461 | 1 | Semantics | resolved | formal-semantics | Data model syntax and literal values | ||
| 462 | 1 | Semantics | resolved | formal-semantics | Semantics of op:to | ||
| 463 | 1 | Language | resolved | formal-semantics | Sequence operations: value vs. node identity | ||
| 464 | 1 | Semantics | resolved | formal-semantics | Casting functions | ||
| 465 | 1 | resolved | formal-semantics | Overloaded functions | |||
| 466 | 1 | Semantics | resolved | formal-semantics | Semantics of / | ||
| 467 | 1 | resolved | formal-semantics | Binding position in FLWR expressions | |||
| 468 | 1 | resolved | formal-semantics | Operations on node only in XPath | |||
| 469 | 1 | resolved | formal-semantics | Semantics of effective boolean value | |||
| 470 | 1 | Language | resolved | formal-semantics | SequenceType limitations | ||
| 471 | 1 | Semantics | resolved | formal-semantics | Casting based on the lexical form | ||
| 472 | 1 | Static typing | resolved | formal-semantics | Static typing of union | ||
| 473 | 1 | Semantics | resolved | formal-semantics | When to process the query prolog | ||
| 474 | 1 | resolved | formal-semantics | Boolean node test and sequences | |||
| 475 | 1 | Static typing | resolved | formal-semantics | Typing for descendant | ||
| 476 | 1 | Semantics | resolved | formal-semantics | Should to also be described in the formal semantics? | ||
| 477 | 1 | Semantics | resolved | formal-semantics | Should we define for with head and tail? | ||
| 478 | 1 | Semantics | resolved | formal-semantics | Semantics of special functions | ||
| 479 | 1 | Semantics | resolved | formal-semantics | Non-determinism in the semantics | ||
| 480 | 1 | Static typing | subsumed | formal-semantics | Typing of input functions | ||
| 481 | 1 | Semantics | decided | formal-semantics | Semantics of Schema Context | ||
| 482 | 1 | Semantics | resolved | formal-semantics | Type equivalence rules | ||
| 483 | 1 | resolved | formal-semantics | Dependency in normalization and function resolution | |||
| 484 | 1 | Semantics | resolved | formal-semantics | Treatment of nillability and xsi:nil | ||
| 485 | 1 | resolved | formal-semantics | Treatment of xsi:type in validation | |||
| 486 | 1 | Typing | resolved | formal-semantics | Support for PI, comment and namespace nodes | ||
| 487 | 1 | Semantics | resolved | formal-semantics | Representation of text nodes in formal values | ||
| 488 | 1 | Static typing | resolved | formal-semantics | Static typing of path expressions in the presence of derivation by extension | ||
| 489 | 1 | resolved | formal-semantics | Support for substitution groups | |||
| 490 | 1 | resolved | formal-semantics | What should be the type annotation in the data model for anonymous types? | |||
| 491 | 1 | Semantics | resolved | formal-semantics | Validation of an empty string against a string list | ||
| 492 | 1 | Language | decided | formal-semantics | Derivation by extension in XQuery | ||
| 493 | 1 | Language | resolved | formal-semantics | May the content of a text node be the empty string? | ||
| 494 | 1 | resolved | formal-semantics | Should type annotations be optional? | |||
| 495 | 1 | subsumed | formal-semantics | What is the type of the input functions? | |||
| 496 | 1 | Semantics | decided | formal-semantics | Support for lax and strict wildcards | ||
| 497 | 1 | resolved | formal-semantics | Semantics of => | |||
| 498 | 1 | resolved | formal-semantics | Common primes for incomparable types | |||
| 499 | 1 | Language | resolved | formal-semantics | Casting and validation | ||
| 500 | 1 | Semantics | resolved | formal-semantics | Support for wildcard namespaces | ||
| 501 | 1 | Typing | resolved | formal-semantics | Support for XML Schema groups | ||
| 502 | 1 | Language | resolved | formal-semantics | Element and attribute declarations in the static context | ||
| 503 | 1 | Semantics | resolved | formal-semantics | Collations in the static environment | ||
| 504 | 1 | resolved | formal-semantics | Type promotion in Atomization | |||
| 505 | 1 | resolved | formal-semantics | How to describe the semantics of built-in functions | |||
| 506 | 1 | resolved | formal-semantics | Normalization of XPath predicates | |||
| 507 | 1 | resolved | formal-semantics | Coalescing text nodes in element constructors | |||
| 508 | 1 | Semantics | resolved | formal-semantics | Namespaces in element constructors | ||
| 509 | 1 | Static typing | resolved | formal-semantics | Static typing for validate | ||
| 510 | 1 | Language | resolved | formal-semantics | Is validate working on sequences? | ||
| 511 | 1 | Language | resolved | formal-semantics | Sorting by document order | ||
| 512 | 1 | Semantics | resolved | formal-semantics | Conformance Levels | ||
| 513 | 1 | Static typing | resolved | formal-semantics | Imprecise static type of constructed elements | ||
| 514 | 1 | Semantics | resolved | formal-semantics | Raising errors | ||
| 515 | 1 | Language | resolved | formal-semantics | Element constructors aligned with XSLT | ||
| 516 | 1 | Typing | resolved | formal-semantics | Typeswitch and type substitutability | ||
| 517 | 1 | resolved | formal-semantics | Semantics of 'element foo of type T' | |||
| 518 | 1 | resolved | formal-semantics | Static typing for atomization, effective boolean values, and function arguments. | |||
| 519 | 1 | Typing | resolved | formal-semantics | Type of document node | ||
| 520 | 1 | Semantics | decided | formal-semantics | Coercion between untyped and atomic values | ||
| 521 | 1 | Semantics | resolved | formal-semantics | Semantics of XPath 1.0 compatibility | ||
| 522 | 1 | Semantics | resolved | formal-semantics | Primitive function applications | ||
| 523 | 1 | type-semantics | decided | xpath | input(), collection(), document(); validation semantics | ||
| 524 | 1 | type semantics | decided | xpath | Plural datatypes different from Singular *? | ||
| 525 | 1 | Semantics | resolved | formal-semantics | Static context accessible from the dynamic context | ||
| 526 | 1 | types | decided | xpath | Semantics for anySimpleType and untypedAtomic | ||
| 527 | 1 | types | resolved | formal-semantics | Static typing of XPath index expressions | ||
| 528 | 1 | semantics | decided | xpath | Semantics of text constructor on empty sequence | ||
| 529 | 1 | constructor-expr | decided | xquery | Node identity in the formal semantics | ||
| 530 | 1 | validation | decided | xquery | Default default validation mode | ||
| 531 | 1 | type-semantics | decided | xquery | Should discard the type of copied subelement | ||
| 532 | 1 | syntax | decided | xpath | Alignment between path expressions and sequence types | ||
| 533 | 1 | type-semantics | resolved | formal-semantics | Strict static typing for automatic coercion of untyped atomic to atomic values | ||
| 534 | 1 | type-semantics | decided | formal-semantics | Semantics of function calls and notion of "expected type" | ||
| 535 | 1 | syntax | decided | xpath | Lexical state tables | ||
| 536 | 1 | types | resolved | xpath | Data model to infoset mapping and type information | ||
| 537 | 1 | modules | decided | xquery | What happens to imported schemas that are used in function signatures? | ||
| 538 | 1 | extensions | decided | xquery | Can (and should) keyword extensions be allowed in XQuery by equipping them with a namespace prefix? | ||
| 539 | 1 | types | decided | formal-semantics | Semantics of fs:cast-untypedAtomic in backward compatibility mode | ||
| 540 | 1 | types | decided | formal-semantics | How does the static semantics works in the case where the input types are unions? | ||
| 541 | 1 | type-semantics | decided | formal-semantics | Should it be a static error if an expression other than () has type empty? | ||
| 542 | 1 | type-semantics | resolved | formal-semantics | What should be the type of an attribute or element that is well-formed but not validated, or is validated in skip mode? | ||
| 543 | 1 | type-semantics | decided | xpath | How can a path expression match elements in the substitution group of a given element? | ||
| 544 | 1 | type-semantics | decided | xpath | How can a path expression match nodes of a given type? | ||
| 545 | 1 | types | resolved | xpath | Are XS element/attribute declarations implicitly added to the schema context? | ||
| 546 | 1 | conformance-levels | postponed | xpath | Are there more processing model options that could make sense as consistent features and thus as conformance levels? | ||
| 547 | 1 | syntax | decided | xquery | Use "declare" for declarations | ||
| 548 | 1 | syntax | decided | xpath | Lexical Rules: states normative? | ||
| 549 | 1 | namespaces | decided | xquery | Computed namespace-constructor | ||
| 550 | 1 | syntax | decided | xquery | Location of Comments | ||
| 551 | 1 | types | decided | xpath | Constructor functions for unprefixed user defined types | ||
| 552 | 1 | syntax | decided | xpath | Should the quotes in processing-instruction("...") be optional? | ||
| 553 | 1 | errors | decided | xpath | Rules for reporting dynamic errors statically | ||
| 554 | 1 | editorial | decided | xpath | What is the really normative text? | ||
| 555 | 1 | formal semantics | active | formal-semantics | Formal Semantics of Module Import | ||
| 556 | 1 | formal semantics | decided | formal-semantics | Formal Semantics of Variable Definitions | ||
| 557 | 1 | formal semantics | decided | formal-semantics | Formal semantics of Validation Declaration | ||
| 558 | 1 | formal semantics | decided | formal-semantics | The content of element types should always allow PI's and comment node types | ||
| 559 | 1 | formal semantics | active | formal-semantics | New Sequence Type needs to be fully implemented in Formal Semantics | ||
| 560 | 1 | formal semantics | resolved | formal-semantics | Exactness of Type Inference | ||
| 561 | 1 | conformance | decided | xpath | Normativity of External Mappings | ||
| 562 | 1 | static typing | decided | formal-semantics | What static typing for fn:root? | ||
| 563 | 1 | errors | decided | xquery | Is dynamic evaluation performed if error in static analysis? | ||
| 564 | 1 | schema-import | decided | xquery | Loading same schema-component twice | ||
| 565 | 1 | context | resolved | xquery | XQuery context: default attribute declarations? | ||
| 566 | 1 | types | decided | xpath | "treat" should work up and down type hierarchy |
XPath can't be treated as a terminal symbol in our grammar. We intend XQuery to be a superset of the abbreviated syntax of XPath. We do not use the grammar of XPath directly because it needs to be integrated into our other productions. For example, operators like the union operator, which occur in path expressions, also occur in other contexts in XQuery, and it makes little sense to define two different operators. This raises issues of coordination with XPath.
This is the charter of the XPath task force.
The XQuery editorial team is working through a number of cases to determine the best precedence of operators. Our current precedence rules are shown in Appendix B.
Operator precedenced subsumed by XPath 2.0 WD.
What should be the precedence of a RangeExpr? The XQuery grammar has it in a bit different place than is listed here.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
Current grammar ok.
Jerome and Mary have suggested that we abandon the separate abstract syntax for XQuery, in favor of a higher-level BNF.
This is the BNF that now appears in Appendix B.
This is the BNF that now appears in Appendix B.
XPath 1.0 has no reserved words. The current XQuery spec attempts to avoid reserved words but the result is that the XQuery grammar relies heavily on lexing tricks that make it difficult to document and difficult to extend. There is currently a substantial feeling in the XQuery group that the language should have some reserved words, which would be an incompatible change from XPath 1.0.
XSL WG Position: Exceptionally strong feeling that requiring element names that match a reserved word to be escaped is utterly unacceptable. If reserved words are required they must start with an escape character so they cannot conflict with element names. Attempt to maintain grammar and revisit this issue as necessary. We recognize that there is a problem but solutions are all distasteful.
Subsumes: #xquery-xpath-issue-reserved-words.
Subsumes: #xquery-reserved-keywords.
Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0252.html)
Decision by: xquery on 2002-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)Joint F2F
Decision by: xsl on 2002-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)Joint F2F
Closed with no change to document.
XPath 1.0 has no reserved words. It might be desirable to relax this restriction in XPath 2.0. When it is necessary to use an identifier that string-matches a reserved word, the identifier could be prefixed by a colon to distinguish it from a reserved word, as in /investment[:return > 0.1]. Reason: most query and progamming languages have reserved words. The only way to avoid them is to introduce lexing "tricks" that make the grammar difficult to document and difficult to extend. This approach greatly increases the difficulty of implementing an XQuery parser. It also contradicts the generally accepted practice of cleanly separating the parser from the lexer and keeping the lexer as simple as possible. It may also interfere with the parser's ability to report on and recover from errors.
Status: Open and under discussion. No consensus at this time.
Subsumed by :xpath-issue-reserved-words.
Where should keywords be reserved in XQuery? Currently, they are not reserved in the XML portion of our grammar, but are reserved in the expression syntax. XPath also reserves keywords, but only in certain positions in expressions.
Subsumed by :xpath-issue-reserved-words.
Should keywords in XQuery be case-sensitive?
Decision by: xsl on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)
Decision by: xquery on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)
Keywords are case-sensitive and it was also decided to use only lower-case keywords in the current XQuery / XPath WD. Thtopchange the text, the grammar, and the examples.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft: section 2.1.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
There has been deep discussion about the issue of implicit conversions, the effect of which is pervasive in XPath. The advocates for implicit conversion cite XPath 1.0 compatibility, ease of use for very common operations, and issues associated with types specified by the source tree when a schema is present, and the fact that these types may not be known at compile time. The detractors cite hidden 'gotchas' with the implicit conversion, and some difficulty in regards to optimization rewrites. The current document defines normative implicit conversions, but places the responsibility on whether or not these conversions will be done, or an error thrown, on the XPath context.
Addressed by XPath 2.0 basic and standard-fallback conversions. Whether or not implicit conversion is done when a type error occurs is up to the host language to define.
Consider the expression price * 2. If price evaluates to a node-set containing more than one node, XPath 1.0 extracts the numeric value of the first node and multiplies it by two, but XQuery will probably raise an error in this case. Tentative proposal: if we can get XQuery to accept the default XPath 1.0 conversion, but require explicit conversion for XQuery, it should solve this problem.
Addressed by XPath 2.0 basic and standard-fallback conversions. This is no longer an issue since both operands must be singletons.
XPath has a number of implicit type coercions, and also has implied existential quantification in some places. In XML 1.0, which had a small and loose type system, this was less problematic than it is with XML Schema, which introduces many types and relationships among types. If XQuery is to be compatible with XPath, we need to study these rules carefully, and adapt them to be rational and intuitive when used with the XML Schema type system.
Also, there are interactions between quantification and type coercion in XPath, sometimes causing non-intuitive results.
Addressed by XPath 2.0 basic and standard-fallback conversions.
XQuery-Null-Issue-3: Question: What should happen if an operand of an arithmetic operator is a sequence of length greater than 1?
Addressed by XPath 2.0 basic and standard-fallback conversions. It's an error.
Text is in Working Draft 2001-11-28 sec 2.5.
If two sequences are combined with an arithmetic operator, what are the semantics? Should a Cartesian product be used? Should the operator be applied to pairs? Should an error be raised?
Text is in Working Draft 2001-11-28 sec 2.5.
Addressed by XPath 2.0 basic and standard-fallback conversions. It's an error. See also: #xquery-xpath-arith-on-sets
Some feel that something as fundamental as type error checking should not be part of the context. This will prevent expressions from being moved between XSLT and XQuery without changing their results.
We recognize that XQuery may have a different conversion strategy but feel this proposal gives them that flexibility. For Xpath implicit conversions are considered to be exceptions which allow a host language to specify that the processor either halt or continue with the conversion as the recovery action. If this exception could occur at runtime the processor is allowed to notify the user earlier. (Allows static type checking).
In XPath 1.0, a node-set can be used in a Boolean context, and it is considered to have the value True if it is non-empty. But XQuery believes that a node-set containing one element with value False should not be implicitly converted to True. For example, if married is a Boolean-valued subelement of person, XQuery does not believe that //person[married="True"] should return persons whose married subelement has value False.
The section on comparisons performs exceptional treatment for node-set to Boolean conversions. Jonathan Marsh does not support such an exception. Either we should remove the exception and take the backward compatibility hit, or we should define a different mechanism to access the typed-value so that the compatibility question is avoided.
Input from Michael Rys:
The following proposal tries to provide a solution to the following issues: XPath2-Issue-14 (node-set-conversion): Implicit conversion of node-sets to boolean for comparisons. Priority: 1 Originator: XQuery, jmarsh@microsoft.com Locus: Syntax XQuery-XPath2-Issue-2 Converting node-sets to Boolean. XQuery-Issue-64 Converting general expressions to boolean and is related to the following issues: F&O Issue 85 : The semantics of xf:boolean(node) is underspecified (operator-boolean-node-unspecified) We would appreciate if this could be scheduled quickly and accepted. Assumptions ----------- I use the function typed-value(node) from the data model as a synonym for the actual language accessor /data(). Problem description ------------------- XPath 1.0 defines an implicit conversion of node-sets N to boolean in a way that any such conversion is defined as not(empty(N)). This is a useful definition for being able to define node tests of the forms (A) a[@b] (B) a[b or b/c = 4] but unfortunately conflicts with the general rules of typed-value access as requested by XQuery for expressions such as (C) a[@b=$val] In such expressions, if $val is bound to an integer value expression then the expected rules are: let $val := 5 return a[@b=$val] becomes (after expression rewrite and implicit typed-value access): a[typed-value(@b) = 5] If $val binds to a boolean value, the same expression unfortunately is in contradiction with the XPath 1.0 semantics: let $val := xf:false() return a[@b=$val] becomes (after expression rewrite and implicit typed-value access): a[typed-value(@b) = xf:false()] XPath 1.0 semantics would be: a[not(empty(@b)) = xf:false()] Summary of the proposal ----------------------- The following proposal tries to preserve the XPath 1.0 semantics for cases (A) and (B) while preserving the typed-value access for case (C). Impact: It will preserve XPath 1.0 backwards-compatibility for the 80% use case but break it in the 20% use case. Details ------- 1. Generally, if a node or node sequence is passed as a parameter to a function or operator where a boolean value is expected, an attempt is made to extract the typed-value of the node(s) subject to the conversion rules of the nodes type to boolean. Comment: This will cover (C) to be always a[typed-value(@b) = $val] regardless of the type of $val. 2. The following exceptions hold: 2 (a) If the operation is a predicate (either the [] shortform or the where clause in FLWR), then a node or node sequence will be translated into a node test instead of accessing the typed value. 2 (b) If the operation is the not() function or the and or or operators, an argument expression that results in a node or node sequence will be translated into a node test instead of accessing the typed value. Comment: This will preserve the useful XPath 1.0 compability for cases (A) and (B). Note that we have special cased these operations already, so the special casing is less of a problem than it may seem. Open Issues ----------- The XPath 1.0 semantics uses xf:boolean(node) to define the node test semantics. XQuery's cast currently does not clarify if it performs implicit typed-value access on CAST as xsd:boolean (node) or if it is an error (to allow casting to user defined complex types in the future). In either case it does not perform a node test. The question is whether xf:boolean in XPath 2.0 should be the node test or CAST as xsd:boolean(typed-value(node)). I prefer the later, but am open to strong pushback. |
Cf. Consistency of functions that take boolean formal argument
Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)
Agreed that choice context is not necessary for XPath predicates. Standard fallback conversions will handle case when required value is optional boolean but actual value is not.
Decision by: xpath-tf on 2001-11-13 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0065.html)
Adoption of Michael R's proposal in Proposal to close issue expr[nodes].
Decision by: xpath-tf on 2001-11-20 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0114.html)
There have been some problems called to attention on the editor's list about the decision made at the telcon concerning dealing with nodes in predicates and the like.
The issue will be discussed at the F2F meeting.
Text is in Working Draft 2001-11-28 sec 2.3.
Text is in Working Draft 2001-11-28 sec 2.7.
Text is in Working Draft 2001-11-28 sec 2.11.
Text is in Working Draft 2001-11-28 sec 2.12.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)
Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0692.html)(joint meeting)
Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0692.html)(joint meeting)
The EBV of a sequence containing both nodes and atomic values is True.
In XPath 1.0, a node set can be used in a Boolean context, and it is considered to have the value True if it is non-empty. This feature is sometimes used in predicates; for example, //person[kid] returns persons who have a kid. In the XPath-2 data model, it is possible to have a sequence of Booleans, or a sequence of elements whose values are Booleans. It is very strange for a sequence containing the single value False to be interpreted as True, or for a sequence containing one node whose value is False to be interpreted as True. For example, consider the query //person[married=True]. It seems unfortunate for this query to return a person containing a single "married" element whose value is False.
This is a difficult problem. Here are some possible approaches, all of which have disadvantages: a. Retain the current XPath 1.0 semantics. Problem: then //person[married=True] returns persons whose "married" subelement has value False. b. If the sequence contains exactly one element whose content is Boolean, extract the value; otherwise raise an error. Problem: incompatible with existing usage such as //person[kid]. c. Use rule (a) above when a node-sequence is used directly in a predicate such as //person[married], but use (b) above when a node-sequence is used with any Boolean operator, as in //person[married=True]. Problem: inconsistent rules. d. Change XPath so that values are not extracted from nodes except by an explicit data() function. Then, for example, a person containing a married subelement with value False would be returned by the query //person[married] but not by the query //person[married/data()=True]. The query //person[married=True] would be a type error. Problems: this approach is incompatible with XPath 1.0, and it annoys users by requiring them to type salary/data() + bonus/data() rather than salary+bonus.
Status: Open. For discussions of this issue, see http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Sep/0137.html and http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Sep/0160.html.
Subsumed by :xpath-issue-node-set-conversion.
Conditionals in XQuery allow any expression in the grammar. Which kinds of expressions are actually converted to Boolean values, and how is this done? Which kinds of expressions raise errors?
Subsumed by #xpath-issue-node-set-conversion.
XPath 1.0 implicitly converts a node set to a number by using the value of the first node. XQuery suggests that, in XPath 2.0, conversion of a node set to a number should raise an error if the node set contains more than one node. Reason: the current XPath 1.0 rule leads to lots of strange behavior. For some examples, consider the following queries, against a document containing persons who have unique names but possibly multiple donations: //person[name="Hillary"]/donation returns all the donations of Hillary. //person[name="Hillary"]/donation+0 returns only the first donation of Hillary. //person[donation] returns all persons who have a donation. //person[donation+0] returns only those persons whose position in the list of persons is equal to the value of their first donation. Editorial note: Some people have observed that example (c) above illustrates conversion of a node set to Boolean rather than arithmetic on node sets. I have retained these examples here because the difference between examples (c) and (d) illustrates an interesting property of arithmetic on node sets in XPath 1.0.
Subsumed by #xpath-issue-node-set-conversion. Status: The Query WG approved this request on 9/19/01.
Sequences are defined to not be able to contain sequences. Yet, it is probably that we need to be able to represent null in sequences in order to maintain cardinality for table processing and the like.
Proposal: Nulls are a special value or an empty sequence: It is a special value when it is a member of a sequence. It is an empty sequence for type checking and iteration. This may require tagging empty sequences that were returned as null with a flag. The XSL WG has not reached resolution on this proposal.
Conflicts with : null-missing-data.
Decision by: xpath-tf on 2001-12-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Dec/0128.html)
Decision by: xquery on 2001-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0150.html) confiriming that no action is required by the XQuery WG
XSLT WG agrees that empty sequence should be used to represent missing data (this is the status quo).
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
How should missing or unknown data be represented?
Subsumed by: #xpath-issue-null-value. Resolution: by an empty sequence.
Should elements with xsi:nil="True" receive any special treatment on input?
Resolution: In the case of an empty element whose content-type is string, the attribute xsi:nil will be used to distinguish the zero-length string from the empty sequence. For example, <a /> indicates an element whose content is the zero-length string, while <a xsi:nil="True" /> indicates an element whose content is the empty sequence.
In XPath 1.0, boolean operations such as AND and OR are defined using two-valued logic. In order to effectively deal with absent or unknown data, XQuery will probably introduce three-valued logic as used in SQL, using an empty sequence to represent the unknown truth value. This would result in incompatible changes to Boolean operators such as AND and OR.
The XSL WG resolved that three-valued logic should be used.
What logic should be used by the AND and OR operators?
Subsumed by: #xpath-issue-3valued-logic. Resolution: Three-valued logic using SQL truth tables.
In XPath 1.0, operators such as AND and OR are based on two-valued logic and an empty sequence is considered to have the truth value False. XQuery suggests that, in XPath 2.0, the Boolean operators use three-valued logic with the empty sequence representing the unknown truth value. Reason: This change will allow XQuery to deal effectively with missing and unknown information. This is a long-standing requirement that is handled by null values in relational systems. It is convenient to represent missing information by an empty sequence in the XQuery data model rather than by introducing a separate null value. However, this approach leads to some differences from XPath 1.0 usage, including the following, where () represents the empty sequence: True AND () has the value (), whereas in XPath 1.0 it is False. False OR () has the value (), whereas in XPath 1.0 it is False. not( () ) has the value (), whereas in XPath 1.0 it is True. () = () has the value (), whereas in XPath 1.0 it is False. Status: The Query WG approved this request on 9/19/01.
Personal observation (by Don): XPath 1.0 has a not() function but it does not have a NOT operator. It would be possible to retain the not() function with two-valued logic and introduce a new NOT operator with three-valued logic.
Subsumed by: #xpath-issue-3valued-logic.
Does XQuery need three-valued logic? How should XQuery deal with missing or absent values? What are the semantics of XML Schema's xsi:nil?
Subsumed by: #xpath-issue-3valued-logic.
then to return an empty
sequence?The section on Conditional Expressions provides for
if/then/else but not a simple if/then. Should we default
then to return an empty sequence?
See also: null-if-where.
Decision by: xpath-tf on 2002-01-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0312.html)
Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)
Decision by: xsl on 2002-02-07 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Feb/0034.html)
No change to if-then-else.
What is the behavior of IF and WHERE if the value of the branch-expression is the empty sequence?
Subsumed by: #xpath-issue-if-not-else. Resolution: IF takes the ELSE branch. WHERE does not execute the RETURN clause.
Should the 3-valued logic functions be part of the XPath function library? Note that they can be implemented as user functions (not as efficient as a "native" implementation). We may want to include the user definition as an example.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
Not for XPath 2.0/XQuery 1.0.
What value is returned by not() when called on an empty sequence?
Notes: In XPath 1.0, not() is a function that uses two-valued logic, where not() applied to an empty sequence returns True. This feature of XPath 1.0 is sometimes used to test for the absence of a node. The XSLT group has suggested that we retain the semantics of not(), and introduce a new function named not3() based on three-valued logic. XPath 1.0 has no NOT operator in its syntax. Therefore XQuery could add a NOT operator that uses three-valued logic without introducing an incompatibility with XPath 1.0. Option 9A: not() should implement 3-valued logic, an incompatible change to XPath 1.0. Option 9B: not() should implement 2-valued logic and a new function not3() should implement 3-valued logic. Option 9C: Same as 9B, and in addition XQuery should introduce a NOT operator into the syntax, using 3-valued logic with the SQL truth table. History: The XQuery group voted for (9A) at the Redmond F2F, but subsequent inputs from the XSLT group merit reopening this issue.
Subsumed by: #xpath-issue-not-logic.
For functions, the null (empty sequence) is passed to the function, the precedent set by SQL. Should comparison operations act the same, or should they be defined to always return an empty sequence in this case?
Text is in Working Draft 2001-11-28 sec 2.6.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
In XPath 1.0, two empty sequences are considered to be equal. However, since XQuery plans to give the empty sequence a special meaning similar to the null value in SQL, XQuery considers comparison of two empty sequences to return the unknown truth value.
Resolved as per three-valued logic. The XSL WG does not believe there are backwards compatibility issues here, since in XPath 1.0, $x=$x is false if $x is an empty node-set. This is a consequence of implicit existential quantification.
for at the XPath expression
level?Is for really a proper construct for a
simple expression language? Will the definition of
for in XPath cause problems for XQuery?
Input from Michael Kay:
Decision by: xpath-tf on 2001-11-27 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0167.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Adoption of FOR expression in XPath 2.0.
Scott Boag will provide 'tips & traps' text on potential semantic problems of mixing FOR, '/' and SORT.
Text is in Working Draft 2001-11-28 sec 2.9, paragraph 2.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
for?The simple form of the for expression (for(
sequence ) return expression) introduces a lot of
complexity: the "context item" is required for this, and
there is an issue with the parens being required for the
simple varient, and not being required for the more
complex one. Do we need this?
Subsumed by: #xpath-issue-is-for-required.
The syntax for the "for" expression currently does not
define a range variable. An alternative syntax might be
"for ($item) in expr return
$item/@price*$item/quantity".
XSL WG: We suspect we will need both, since we feel that range variables will be needed to do joins, but requiring range variables causes a great deal of verbosity.
Subsumed by: #xpath-issue-is-for-required.
A FOR clause can stand alone: FOR $var IN expr1 RETURN expr2. A LET clause can stand alone: LET $var := expr1 EVAL expr2. It has been suggested that a WHERE clause should also be able to stand alone: WHERE expr1 RETURN expr2.
Note: in the current BNF, at least one FOR or LET clause must occur, but it is not necessary to have a FOR.
Observation: This functionality is already provided by the conditional expression, IF expr1 THEN expr2 ELSE [ ]. There does not seem to be a compelling reason to provide a second way to write this expression. However, making the ELSE clause optional might be a slight improvement.
The following content model should be adopted for FLWR expressions:
FlwrExpr ::= (ForClause | LetClause)+ [WhereClause] ReturnClause |
This allows us also to remove the separate LET/EVAL expression, which can now be expressed using LET/RETURN.
The following content model should be adopted for FLWR expressions:
FlwrExpr ::= (ForClause | LetClause)+ [WhereClause] ReturnClause |
This allows us also to remove the separate LET/EVAL expression, which can now be expressed using LET/RETURN.
We have considered forms of quantified expressions that bind several variables at once, as in SOME $x IN expr1, $y IN expr2. Are such quantifiers desireable? If so, what are their semantics, and what use cases support them? Note that there is no additional expressive power over the current single-variable syntax, this is purely a question of convenience.
Decision by: xpath-tf on 2001-12-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Dec/0128.html)
Allow them; especially in view of consistency with eg "for" that already allows them. The semantics should be the same.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
XPath 1.0 has only four datatypes (booleans, floating-point numbers, strings, and unordered node-sets). XQuery suggests that XPath 2.0 should have a richer set of datatypes based on the built-in types of XML Schema and the notion of an ordered sequence, which can contain zero or more simple or complex values. Literal values should have well-defined datatypes that are determined by their appearance. This will require some changes in the interpretation of literals. For example, 47 will be a literal integer rather than a float. Some types will have constructor functions rather than literals; for example, date("1999-12-25") is distinguished from the arithmetic expression 1999-12-25 which has value 1962. Reason: these changes are needed in order to process documents based on XML Schema.
Status: The Query WG approved this request on 9/19/01.
XPath 2.0 to support all XML Schema primitive datatypes.
Text is in Working Draft 2001-11-28 sec 2.2.1.
The set of constructor functions for XML Schema simple datatypes has not yet been established. A joint task force with XML Schema has been chartered to determine the operators on datatypes, and we expect them to also determine the set of constructors for datatypes.
Resolved in F&O document.
A fixed "promotion hierarchy" must be defined among the primitive and derived types of XML Schema. A function whose declared parameter type is in this hierarchy can be invoked with an argument whose type is lower in the hierarchy. For example, a function with a declared parameter-type of Float can be invoked with an integer argument. In such a case, the argument is converted to the declared type of the parameter.
The promotion hierarchy will be defined by the Operators and Functions Task Force.
Resolved in F&O document.
Section 2.9, on functions, portrays XQuery as a statically typed language, but the mechanisms by which static typing is established are still being developed by the XML Query Algebra editorial team. A complete accounting for type requires that the XML Query Algebra conform completely to the XML Schema type system, and that many open issues be resolved.
The semantics of XQuery are defined in terms of the operators of the XML Query Algebra. The mapping of XQuery operators into Algebra operators is still being designed, and may result in some changes to XQuery and/or the Algebra. The type system of XQuery is the type system of XML Schema. Work is in progress to ensure that the type systems of XQuery, the XML Query Algebra, and XML Schema are completely aligned. The details of the operators supported on simple XML Schema datatypes will be defined by a joint XSLT/Schema/Query task force.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
We have made significant progress. There is still some mismatch (eg. occurrence indicators and facets), but these are also unlikely to change.
Decided: close this issue, raise more specific issues as needed.
Static type checking and schema validation are not equivalent, but we might want to do both in a query. For example, we might want to assert statically that an expression has a particular type and also validate dynamically the value of an expression w.r.t a particular schema.
The differences between static type checking and schema validation must be enumerated clearly (the XSFD people should help us with this).
This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00970097.
Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Addressed by the "Named Typing" proposal.
Accepting text in 2002-04-30 public draft.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Static type checking may be difficult and/or expensive to implement. Some discussion of algorithmic issues of type checking are needed. In addition, we may want to define "conformance levels" for XQuery, in which some processors (or some processing modes) are more permissive about types. This would allow XQuery implementations that do not understand all of Schema, and it would allow customers some control over the cost/benefit tradeoff of type checking.
This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00980098.
Jonathan and Don to present a potential consensus proposal at the f2f (This should be a very short proposal). Note: Perhaps we should seriously consider writing the conformance section for the next set of publications.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decided: Adopt the text in the conformance section of the latest document.
We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.
The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.
Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)
Closing of the directly related issues: #xquery-abstract-syntax and #xpath-issue-complex-type-value is sufficient to close this issue.
Decision by: xpath-tf on 2003-03-04 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0060.html)
Decision by: xsl on 2003-03-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting
Decision by: xquery on 2003-03-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting
On recommendation of the Processing Model Taskforce the disposition is reaffirmed.
This is related to #xquery-schema-importxquery-schema-import. We do not specify what is the effect of type checking a query that is applied to a document without a DTD or Schema. In general, a schema-less document has type xs:AnyType and type checking can proceed under that assumption. A related issue is what is the effect of type checking a query that is applied to an incompletely validated document. As above, we can make *no* assumptions about the static type of an incompletely validated document and must assume its static type is xs:AnyType.
This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00960096.
Some aspects addressed by the "Named Typing" proposal.
The Data Model work still needs to be done.
Open questions: What is the result of a failed validation? Can you inspect the result?
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
a. The Data Model mapping is the crucial issue - and that is duplicated in 43 (xquery-define-schema-variants), so we need not continue to maintain it here.
b. The second issue asks how we process documents on which validation has failed. Open a separate issue (xquery-failed-validation) on this question.
Does the definition of a type include both element-names and element-contents (as in the Formal Semantics document), or only element-contents (as in XML Schema)?
Addressed by the "Named Typing" proposal.
Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Accepting text in 2002-04-30 public draft.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Do we need a function that returns the type name of its operand? If so, what should it return if the operand is an element with a given xsi:type - the element name? the name of the type denoted by xsi:type? Specification of this function requires more work on types in XQuery.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Not for XQuery 1.0.
Should XQuery 1.0 support subtype substitutability for function parameters?
If subtype substitutability is not supported in XQuery Version 1, the motivation for TYPESWITCH is weakened and the decision to support TYPESWITCH should be revisited.
Input from Michael Rys:
I think this is still an open issue given some semantic issues that we found between named subtype substitutability and derivation by extension. I will send mail on this issue this week, |
Addressed by the "Named Typing" proposal.
Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Accepting text in 2002-04-30 public draft.
If the types in the CASE branches are not subtypes of the TYPESWITCH, is this an error, or are these branches simply never executed? If the latter, should we require a warning?
Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)
Issue 48 closed without changes to the document (no static errors will be raised, implementations can but are not required to raise warnings).
Decision by: fs-editors on 2003-02-13 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Feb/0075.html)
Decision by: xquery on 2003-02-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0404.html)
Decision by: xsl on 2003-02-27 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0143.html)
Accepting proposal in FS-Issue-0173 closes this issue in a consistent way.
How should XQuery handle XML Schema substitution groups with respect to name tests in paths? With respect to parameter types and return types in functions?
Text is in Working Draft 2001-11-28 sec 2.13.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
We need more thought about what constitutes a valid parameter-type for a function. Attribute-types as well as element-types? Type-names vs. element-names? Should all the MSL symbol spaces be represented? Wildcards? Sequences?
It is probably important to have NODE as a type, to allow functions to take any XML node as a parameter, or to return any XML node as a result.
Using univeral names similar to those found in the MSL document, but with a different syntax, would allow us to reference any schema type in XQuery function definitions.
Text is in Working Draft 2001-11-28 sec 3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
More detailed rules need to be developed for function resolution. What kinds of function overloading are allowed? A promotion hierarchy of basic types needs to be specified. The issue of polymorphic functions with dynamic dispatch needs to be studied. Can overloaded functions be defined such that the parameter-type of one function is a subtype of the parameter-type of another function? If so, what are the constraints on the return-types of these functions? Is function selection based on the static type of the argument or on the dynamic type of the argument (dynamic dispatch, performed at execution time)? If XQuery supports dynamic dispatch, is it based on all the arguments of a function or on only one distinguished argument?
Observation: This is a very complex area of language design. If it proves too difficult to solve in the available time, it may be wise to take a simple approach such as avoiding dynamic dispatch in Version 1 of XML Query.
The XML Query Formal Semantics does not support overloading or dynamic dispatch. We will attempt to simplify XML Query Level 1 by omitting these, unless it becomes clear that they are needed. We realize that this might happen.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Mike: We dealt with by saying that there is only one function and the use typeswitch semantics.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
XQuery currently considers book and list(book) to be different types. List is an abbreviation of the facets minoccurs=0, maxoccurs = unbounded. We need to confirm that this accurately reflects the type system of XML Schema.
Data model and type system both have sequences. This seems a moot issue.
NOTE: the original formulation of the question is in vocabulary that makes no sense in terms of the actual resolution. Thus the formulation of the issue is confusing, and it is only the resolution that matters.
Does XQuery need features to add support for unordered collections? If so, what features are required? In the current draft, "unordered" is a property of a list. The user can create an ordered list from an unordered list by using SORTBY. The distinct() function not only removes duplicates from a list, it also renders the list unordered.
Do we need a function that merely removes the ordered property of a list?
How does the ordered/unordered property of a list affect the semantics of operators applied to it?
XQuery editors considered and rejected addition of an unordered collection and type. The data model and type system support ordered sequences only.
Is it an error for a query to specify content that may not appear, according to the schema definition? Consider the following query:
invoice//nose |
If the schema does not allow a nose to appear on an invoice, is this query an error, or will it simply return an empty list?
Addressed by the "Named Typing" proposal, but needs more work.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Adopt status quo.
As part of the general description of errors, which is largely still to be done, we must carefully distinguish static from dynamic errors. In general, we should probably attempt to catch errors as early as possible. The following examples have been suggested by the Algebra team:
"If the content of its argument node cannot be expressed as a value of a simple type, the data function raises an error." This could be a static error, since the data function makes most sense for schema valid documents or nodes that have type assigned via xsi:type.
"For each member of the sequence, the ordering expression must return a single value of some type for which the ">" operator is defined (for example, a number or a string); otherwise an error results." This could also be a static error.
"When one or more operands is a node, the content of the node is extracted by an implicit call to the data function and converted to a number before the operation is performed; if this conversion is not possible, an error results." This could be a static or a dynamic error.
"TO is a binary operator that converts both of its operands to integers. It then generates a sequence containing all the integers from the left-hand operand to the right-hand operand, inclusive. If either of the operands cannot be converted to an integer, an error results." In the presence of type info, this could be a static error. In a well-formed document, in which arbitrary strings may be converted to integers, it could be dynamic.
Text is in Working Draft 2001-11-28 sec 3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:
Decision by: xquery on 2003-01-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0215.html)Joint F2F
Decided:
Are type names sufficient - YES
Would NUNS be sufficient for type name - not needed
How will type names be bound to definitions - with imported schemas and namespaces
Do we need to allow inline XML schema declarations in the prolog of a query? The following example shows one potential syntax for this. It extends the namespace declaration to allow literal XML Schema text to occur instead of a URI in a namespace declaration. The implementation would then assign an internal URI to the namespace.
NAMESPACE fid =
"http://www.example.com/fiddlefaddle.xsd"
NAMESPACE loc = [[
<xsd:schema xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">
<xsd:simpleType name="myInteger">
<xsd:restriction base="xsd:integer">
<xsd:minInclusive value="10000"/>
<xsd:maxInclusive value="99999"/>
</xsd:restriction>
</xsd:simpleType>
</xsd:schema>
]]
FUNCTION string-to-myInteger ($s STRING) RETURNS loc:myInteger
{
If the facets of loc:myInteger are not satisfied,
this function raises an error.
LET $t := round(number($s))
RETURN TREAT AS loc:myInteger($t)
}
string-to-myInteger("1023")
|
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Not for XQuery 1.0.
We do not specify how a Schema or DTD is 'imported' into a query so that its information is available during type checking. Schema and DTDs can either be named explicitly (e.g., by an 'IMPORT SCHEMA' clause in a query) or implicitly, by accessing documents that refer to a Schema or DTD. The mechanism for statically accessing a Schema or DTD is unspecified.
This item is a duplicate of the Formal Semantics issue http://www.w3.org/XML/Group/2001/06/WD-query-semantics-20010607.html#Issue-00950095.
Text is in Working Draft 2001-11-28 sec 3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
The semantics of the instanceof operator are not defined over all operands, e.g. sets of several nodes, sequences of several values, etc. What should the symantics be for these types? Should these semantics be defined in the F&O document?
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html)
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Does XQuery need a CAST expression for casting an instance of one type into another type?
A "CAST AS" operator has been added to this current Working Draft.
It's not clear to me that we need "cast" syntax, this can be done using the functions whose names match the primitive data types.
We decided that the constructor pseudo-functions should only take literal arguments, therefore CAST is needed for run-time conversions (the original issue was saying that we didn't need both)
The algebra does not have coercion functions between values. The mapping requires this for CAST AS.
The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core, therefore includes CAST AS.
Does XQuery require a syntax for type guards?
We have added the "TREAT AS" operator to this current Working Draft. This is especially helpful for function arguments, since we do not have function polymorphism in the current specification.
The functionality of TREAT can also be expressed using TYPESWITCH. A proposal to remove the TREAT expression is under consideration.
The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. 'TREAT AS' is expressed in XQuery core as a TYPESWITCH.
Various approaches to the syntax of CAST AS and TREAT AS have been proposed. Java and SQL have both been sources used to discuss these approaches. We are still exploring other syntactic approaches.
CAST/TREAT syntax has been pretty stable for a while. Can we just resolve this issue?
Do we need an expression similar to the MATCH expression in the algebra? One proposed syntax looks like this:
TYPESWITCH expr
CASE typename1: expr1
CASE typename2: expr2
|
Since this syntax corresponds more closely to the syntax of the algebra, it can be mapped more easily. Alternatively, the match expression in the algebra could be made to resemble the INSTANCEOF expression of XQuery.
The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. TYPESWITCH is supported in both.
In the XQuery Formalism document, there is a static type-assertion expression:
Expr : Type |
This is often useful in an expression like:
LET bib0 : Bib := <bib>...some literal data...</bib> |
which asserts statically that the type of bib0 is Bib, i.e., that the literal data is a value contained in the Bib type. If this is not true, a static, compile-time error is raised.
This semantics is not the same as :
LET bib0 := TREAT AS Bib (<bib>...</bib>) |
which will raise a run-time error if the literal data is not a value in Bib.
Current proposal is for ASSERT AS Datatype (Expr)
Text is in Working Draft 2001-11-28 sec 2.13.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Do we need a Context Item to track the "current item"
in a for itteration, and, if so, how should
it work? How should "." work in relation to it?
Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)
Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)
Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.
Do we need a way to specify the nodes in the input context? Many queries do not specifically state the input to which they will be applied. This allows the same query, for instance, to be applied to a number of databases. It may be helpful for the mapping to introduce a global variable, eg $input, to represent the input nodes for a query. This variable might even be useful in the syntax of XQuery itself.
Decision by: xquery on 2002-05-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0104.html)
The imput() function provides this functionality.
It seems like the context should include a default namespace declaration for use for the QNames within node tests within the XPath. I'm worried about complexities with other qnames besides the one in node tests, like function qnames.
Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)
Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 5.
Do we need a datatype names binding in the context?
Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)
Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 8.
The Functions and Operators doc specifies named collations. These probably need to be part of the context. 1) Should we treat collations as distinct from functions? 2) If yes, how do we handle the binding of the collation name to the collation.
Decision by: xpath-tf on 2001-11-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0013.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Decision by: xquery on 2001-12-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0127.html)
Addressed by Mike K's text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/att-0000/01-context.html (The XPath Expression Context)
Text is in Working Draft 2001-11-28 sec 2.1.1.1, paragraph 11.
How are collation sequences created to define inequality and sort orders?
Subsumed by: #xpath-issue-collation-bindings.
The definition and syntax of a query module are still under discussion in the working group. The specifications in this section are pending approval by the working group.
Future versions of the language may support other forms of query modules, such as update statements and view definitions.
Paulist Modules Proposal
This proposal adds modules, external variables, external functions,
and global variables to XQuery. It addresses the following open
issues:
74 Module syntax
75 Importing Modules
124 External Functions
157 Function Libraries
223 We need a way to declare external functions
250 Declaring Variables in Prolog
This proposal is called the Paulist Modules Proposal, because it is
based on a simplification Paul Cotton made to earlier module
proposals, which can be found here:
Subject: Paul's Proposal (was: Unified proposal on modules, global
and external variables, and external functions)
From: Jonathan Robie (jonathan.robie@datadirect-technologies.com)
Date: Thu, Dec 19 2002
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0391.html
Many other people have contributed to this proposal in various
iterations, including Mary Fernandez, Jerome Simeon, Don Chamberlin,
Michael Rys, Phil Wadler, and Michael Kay.
1. Modules and Module Declarations
An XQuery module is a resource that contains a Query. A module may
declare a target namespace using a ModuleDecl. The syntax of Query
and ModuleDecl is as follows:
Query ::= ModuleDecl? QueryProlog ExprSequence?
ModuleDecl ::= "module" ModuleURI
If a module contains a ModuleDecl, its functions may be imported by
other modules. A module that does not have a ModuleDecl can not be
imported. A ModuleURI may be relative - if so, it is combined with
the Base URI to create an absolute URI.
In a module that is imported by another module, the optional
ExprSequence must be absent, or a static error is raised.
2. Module Imports
A query may import modules in the QueryProlog using
ModuleImports. The syntax of QueryProlog and ModuleImport is as
follows:
QueryProlog ::= (NamespaceDecl
| DefaultNamespaceDecl
| SchemaImport
| ModuleImport
| VarDn)*
FunctionDn*
ModuleImport ::= "import" "module" ModuleURI ("at" ImplURI)?
Functions and global variables defined in a module may be used in
any module that imports the defining module. Importing a module
does not provide access to the imported schemas or namespaces of
that module. Importing a module does not provide access to the
functions imported by that module.
An implementation may locate a module in any convenient manner,
provided the ModuleURI of the module it locates matches the
ModuleURI of the ModuleImport. The optional ImplURI specifies the
resource containing the implemenation of the module. It is treated
like a schema location hint in XML Schema - an implementation may
ignore it completely.
Two modules may import each other. For instance, if module A
imports module B, then module B may import module A.
3. Variable declarations and definitions
A variable may be declared or defined using a VarDn in the
QueryProlog. The syntax of VarDn is as follows:
VarDn ::= "define" "global"? "external"? "variable" "$" VarName
("as" SequenceType)? (":=" Expr)?
A variable may have no forward references to functions or
variables. Functions and variables imported into a module are
considered prior to a global variable if they are imported before
the global variable is defined. A variable may not be used before
it is defined.
If the "global" keyword is present, then the variable will be
imported whenever the module that contains it is imported.
If the "external" keyword is present, the variable is [external];
if it is absent, the variable is [internal].
An [external] variable definition must include only the variable's
name and optional sequence type, or a static error is raised.
During dynamic evaluation, an [external] variable must be bound to
a value in the dynamic context, or an error is raised.
An [internal] variable definition must include the variable's name,
optional sequence type, and a required expression, or a static
error is raised.
It is a type error, if the value of a variable does not match the
declared sequence type of the variable.
4. External functions
An external function definition allows XQuery to call functions
written in other languages. The syntax of a FunctionDefn is as
follows:
FunctionDefn ::= <"define" "function"> "external"? <QName "(">
ParamList? (")" | (<")" "as"> SequenceType)) EnclosedExpr
If the "external" keyword is present, the function is [external];
if it is absent, the function is [internal].
If a function is [internal], its implementation is given as an
XQuery expression in the module's implementation. If a function is
[external], its implementation is given by the query environment.
XQuery does not specify how external functions are implemented or
accessed, how actual arguments are passed to external functions, or
how return values are passed to the query environment - all that is
implementation defined.
|
Questions in proposal that need resolution:
In today's telcon, we identified three central questions that need to be resolved for the modules proposal. Once we resolve these questions, it will be easy to rewrite the Paulist module accordingly. Question 1: What is the relationship between the ModuleURI and the namespace of the functions it contains? Possible answers: 1.A. There is no relationship. A module is identified by a URI, and may contain functions in any namespace. 1.B. The module URI is the namespace of functions and global variables defined in that module. It serves as a default namespace for both functions and global variables, but the prolog can change these defaults. 1.C. The module URI is the namespace of functions and global variables exported by the module. A module may contain functions and global variables defined in other namespaces or in no namespace, but they are not exported when the module is imported into another module. 2. Should there an optional LocationURI? 2.A. A module has an optional LocationURI, which provides the location of a resource. This allows the name of a resource to be decoupled from its location, while allowing relative or absolute locations to be specified explicitly. 2.B. A module is identified only by the ModuleURI, which may be relative or absolute. Catalogs or other similar devices are used to map the ModuleURI onto a location. There are two variations on 2.B: 2.B.i: The ModuleURI may be relative. 2.B.ii: The ModuleURI must be absolute. Relative ModuleURIs are not useful if we choose 2.A. Jonathan Note: Michael Kay suggested Option A and Option B. They are defined as: Option A: (C3, L1) Option B: (C1, L2) |
Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)
Decided to adopt 1B and 2A.
The means by which a query module gains access to the functions defined an an external function library remains to be defined.
Should xmlns only be respected for construction, Xquery expressions but not functions, or also functions?
Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)
Decided to adopt 1B and 2A in proposal for issue #xquery-module-syntax.
What is a query?
According the the algebra: any number of type declarations, function definitions, variable definitions and expressions.
According to XQuery: any number of namespace declarations, function definitions and a unique expression.
These definitions should be coordinated.
The XQuery algebra is a proper subset of XQuery, in particular, the XQuery Core, so however a query is defined in XQuery is the same in the algebra.
Can a namespace prefix be redefined, as in XML?
Text is in Working Draft 2001-11-28 sec 3.
Text is in Working Draft 2001-11-28 sec 3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
The syntax currently uses a semicolon as a query module separator. What are the semantics of the query module separator? Is the semicolon the best character for this?
Resolved by XQuery WG to eliminate ';' separator
Does XQuery need a way to specify the encoding of a query? For instance, should the prolog allow statements like the following?
ENCODING utf-16 |
Decision by: xquery on 2003-01-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0502.html)
The text of a query is in Unicode. Serialization is done in Unicode, but APIs can set other encodings for serialization.
There is no operator to access the typed constant content of an element. In the Algebra, the data() operator does this. Should XQuery do the same?
Decision by: xpath-tf on 2001-10-23 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0286.html)
Decision by: xquery on 2001-10-31 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Oct/0441.html)
Decision by: xsl on 2001-12-13 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Dec/xxxx.html) It was noted that there are other issues on data() that may lead to further discussions.
Consensus is to define data() on only singleton node and empty sequence. This decision will be reflected in next WD.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
Section 1 - 4th paragraph says the typed-value of an element with complex type is the same as its string-value. This is not currently consistent with the data model. The data model doc says, in section 4.2, "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."
Ed. Note: Question: I had a note from this, "insert from minutes", but I only see "Need to track "what does data()" return as an issue. Typed value? Something else?" as a response to this issue, and the formulation of issue text for the Data Model. Should this issue be removed from this document? -sb
Element & attribute nodes
~~~~~~~~~~~~~~~~~~~~~~~~~~
Given $e is a single element or attribute node:
1. If $e is of unknown type and has simple content (i.e., $e does not contain
complex
content and $e does not have a known type), then
data($e) evaluates to the simple content of the node and has
UnknownSimpleType.
Example:
let $e := <fact about="what i saw"> I saw 8 cats.</ fact>
return data($e)
==> "I saw 8 cats" : UnknownSimpletype
data($e/@about)
==> "what i saw" : UnknownSimpleType
2. Else if $e is of a known simple type or has a simple content type, then
data($e) evalutes to the simple value of the node and
has the node's known simple type.
Example:
let $e := <weight units="{ 'lbs.' }">{ 42 }</weight>
return data($e)
==> 42 : xs:integer
data($e/@units)
==> "lbs." : xs:string
3. Else if $e is of an unknown (complex) type, then data($e) evaluates
to string($e) (text node aggregation) and has UnknownSimpleType.
let $e := <fact>The cat weighs <weight>12</weight> pounds</fact>
return data($e)
==> "The cat weighs 12 pounds" : UnknownSimpleType
4. Else if $e is of a known complex type with complex or mixed content, then
there are two options:
4a. data($e) evaluates to an error
4b. data($e) is defined as in (3) above.
Example:
Assume we have schema type:
<element name="fact" mixed="true">
<element name="weight" type="xs:integer"/>
</element>
and $e is validated w.r.t. the above type:
let $e := validate as element fact (<fact>The cat weighs <weight>12</weight>
pounds</fact>)
return data($e)
4a. raises error
4b. "The cat weighs 12 pounds" : UnknownSimpleType
Text nodes
~~~~~~~~~~~
5. Given $t is a single text node, then data($t) evaluates to string($t)
(content of
text node) and has UnknownSimpleType.
Example:
let $e := <fact>The cat weighs 12 pounds</fact>,
$t := $e/text()
return data($t)
==> "The cat weighs 12 pounds" : UnknownSimpleType
NB: Open issue as to whether data() should be defined on node sequences.
NB: Current definition of data() applied to a text node is the empty sequence.
Comment, PI, Namespace nodes
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6. Given $c is a comment, processing instruction, or namespace node, then
data($c)
evaluates to the empty sequence.
Example:
let $c := <!-- a comment -->
return data($c)
==> () : empty
|
Decision by: xpath-tf on 2002-03-19 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Mar/0174.html)
Decision by: xquery on 2002-03-20 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0405.html)
Decision by: xsl on 2002-03-28 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Mar/0084.html)
Mary's proposal was adopted.
In particular, we chose option (4a) instead of (4b), because the current semantics applies data() implicitly in the basic conversion rules (e.g., when implementing equality and inequality operators), and therefore (4a) will raise an error if a user attempts to extract the atomic data from an element that has *known* complex type.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft: section 2.1.2.2 of XQuery, 2.1.2.2 of XPath.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
What should the semantics be for == and !== in regards to nodesets and sequences?
This is a Functions & Operators document issue.
It seems like Sequence comparisons should be defined in the Functions & Operators document.
Except for empty sequence comparisons, this is no longer an issue since both operands must be singletons. The empty sequence comparisons are resolved by passing the buck to the specific operator, or returning an empty sequence if both operands are empty sequences.
Subsumed by: #xpath-issue-is-isnot-semantics.
How are collections compared? Note that we need to be able to compare unordered collections as well as ordered collections.
Subsumed by: #xpath-issue-is-isnot-semantics.
Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.
The '==' operator is already defined in the F&O document and used in XQuery use cases.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
The '==' is in the document and usecases.
Note that it has been decided to change "==" to "is".
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
The definitions of UNION, INTERSECT, and EXCEPT for simple values are still under discussion. It is not clear that these operators should apply to simple values, because simple values do not have a concept of node identity. If these operators are defined for simple values, perhaps they should have a lower precedence than arithmetic operators.
Text is in Working Draft 2001-11-28 sec 2.4.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
The XSL WG felt that these operators should operate on nodes only and not be overloaded to work on "values" as well. Functions should be used for the "analogous" functionality on values. Action to Ashok to write a proposal. It was noted that one might well want to to a "value" union operating on nodes (where the typed value of each is extracted).
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-02-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0015.html)Xquery acceptance of XSL proposal
These operators operate on nodes only and are not overloaded to work on "values" as well. Functions are to be used for the "analogous" functionality on values.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What should the identity of a simple value be? The value or a unique id?
Simple values have no identity.
In XPath 1.0, comparisons whose operands are sets are considered to have implicit existential quantifiers. For example, the expression a = b effectively means "any member of set a equals any member of set b". The XQuery team observes that this makes the "=" operator non-transitive, so it cannot be used for grouping or for optimizing transforms. XQuery might deal with this by mapping the user-level "=" operator to a lower-level "core" syntax in which quantifiers are explicit and the equality operator (possibly spelled "eq") is transitive.
Status: Open and under discussion. No consensus at this time.
Resolved at Reston F2F by addition of value=, value<, etc. and node=, node<, etc.
Text is in Working Draft 2001-11-28 sec 2.6.1.
What should happen when one or more of the operands of a comparison operator is a sequence of length greater than one?
Subsumed by : #xquery-xpath-existential.
Resolution: An existential quantifier will be implied for any operand that is a sequence of multiple values. Advantages: Compatible with XPath 1.0. Allows queries such as //book[title="Tom Sawyer"] to be executed in the absence of a schema that proves that books have at most one title. Can be translated into an explicit existential quantifier used with a lower-level "eq" operator that is transitive.
Consider the expression a = b. In XPath 1.0, if either operand evaluates to a node-set, an implicit existential quantifier is inserted. Thus the expression effectively means "any member of set a equals any member of set b". The XQuery team observes that this makes the "=" operator non-transitive, so it cannot be used for grouping or for optimizing transforms.
Subsumed by: #xquery-xpath-existential.
In XPath 1.0, string1 = string2 is evaluated by string comparison, but string1 > string2 is evaluated by attempting to convert both strings to floating-point numbers and comparing the numbers. This seems inconsistent. Both of these comparions should be carried out as string comparisons using the default collation.
In XPath 1.0, comparison of a string with a number is carried out by attempting to convert the string to a number. For example, 47 = "47" is True. This seems to conflict with strong typing. One might expect 47 = "47" to be a type error. Status: Open, pending discussion.
Addressed by XPath 2.0 basic and standard-fallback conversions.
Decision by: xquery on 2002-03-27 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0478.html) XML Query WG has adopted a solution to Issues 259 and 91 as per Proposal 1 in Michael Rys' proposal. See #unknown-simple-type-arithmetic
Decision by: xsl on 2002-03-28 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Mar/0084.html)
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
In XPath, <book><title> Mark Twain </title></book> and <book><author> Mark Twain </author></book> are treated as equal in comparisons. Is this acceptable for us? Do we need another notion of deep equality? If so, what are the compatibility issues with XPath?
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
Michael confirms his retraction. Decided: close the issue.
XPath 1.0 defines the "=" operator between two elements to test for string-equality, ignoring nested markup. For example, the "=" operator of XPath 1.0 returns True when comparing a book that has author "Mark Twain" and title "Tom Sawyer" with another book that has title "Mark Twain" and author "Tom Sawyer". XQuery suggests that there are several ways of comparing two elements for equality, and that in XPath 2.0 these various types of element-comparisons should be invoked by function calls rather than by the "=" operator. The comparison functions might have names such as "deep-equal" and "string-equal". Reason: invoking different kinds of element comparisons by their names rather than by the "=" operator will help to avoid surprising results like the one in the above example.
Status: On 9/19/01, the XQuery group approved the following resolution: XQuery requests that the = and != operators, applied to elements, should raise an error if either element does not have a simple content. No change to other comparison operators such as > is requested. Various kinds of equality functions can be defined for elements with complex values, to be invoked using functional notation.
Subsumed by: #xquery-deep-equality.
XPath 1.0 defines the "=" operator between two elements to test for string-equality, ignoring nested markup. For example, the "=" operator of XPath 1.0 returns True when comparing a book that has author "Mark Twain" and title "Tom Sawyer" with another book that has title "Mark Twain" and author "Tom Sawyer". The XQuery group believes that there are several ways of comparing two elements for equality, and that these different forms of comparison should be invoked by functions rather than by the "=" operator.
No resolution yet in XSL WG: Karim, Norm, Jonathan, Perin to discuss deep-equals comparisions of nodes and what to do for the '=' operator. Jonathan will take action on Monday/Tuesday to write a proposal for "deep-equals" function and for '=' operator and sent it to XSL list to get the discussion going.
Subsumed by: #xquery-deep-equality.
The note "NOTE: The string operators will be backwards > compatible with XPath 1.0 ...." is true only in the case of the <, >, <=, > and >= operators. It's not true for "=" and "!=". In fact, if this collating > sequence is used, then < will be compatible ("1" <= "1.0" is true) but "=" > will not be compatible ("1" = "1.0" is now true, previously false).
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
When elements are compared, are comments and PIs considered in the comparison? How is whitespace handled? Do we need to allow more than one way to handle these in comparisons?
Decision by: xquery on 2002-09-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0078.html)
Decision by: xsl on 2002-10-03 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0025.html)The XSL WG is not agreeable to blessing this.
"When elements are compared, are comments and PIs considered in the comparison?": NO
"How is whitespace handled?": This depends on the whitespace in the instance as per the data model.
"Do we need to allow more than one way to handle these in comparisons?": NO, not in XPath 2.0/XQuery 1.0.
How should the error object be supported? How does the error object relate to exceptions?
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
There is no error object in the current design.
This document does not have a general discussion of errors, when they are raised, and how they are processed. This is needed.
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
There is no support for "try" & "catch" in version 1. The current document describes the "halt and catch fire" behaviour of errors.
We believe the following approach to error handling would be very useful - (1) introduce TRY <expression> CATCH <expression>, similar to try/catch in OO languages. Instead of having "throw" to throw objects, use error(<expression>), bind the result of the expression to the variable $err, and allow $err to be used in the CATCH clause.
Dana Florescu has been assigned the task of writing a proposal for this.
Decision by: xquery on 2002-12-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0167.html)
The issue of try/catch has been debated extensively in recent months and the decision has been made not to add such a capability.
Are an empty sequence and an empty node-set distinguishable?
The data model does not distinguish between sequences and between 'node sets', i.e., sequences in document order with no duplicates, therefore there is only one empty sequence.
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
Should sequences be allowed to have nodes? I think you
need them to support sequences of nodes constructed by
for loops.
Status quo: sequences may contain nodes and/or simple values.
XQuery-Null-Issue-7: Question: What should happen if a function expecting one element is invoked on an empty sequence?
It's an error.
Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.3.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What should happen if a function expecting one element is invoked on a sequence of more than one element?
It's an error.
Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6, item 1.1.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
If a sequence is passed as a function parameter where a singleton was declared as the parameter type, should the function call operate on tuples of the Cartesian cross product, as in the current draft, raise an error, or do something else?
Subsumed by: #nulls-functions-on-sequences.
Many XPath functions and node-tests implicitly operate on the current node if no argument is specified. Should this apply to all functions? All unary functions? Only certain functions?
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
Issue closed. We have decided that some functions have this behavior, but that it is not a property of functions in general.
This is really a placeholder. Ashok mentioned that there may be a problem with using '.' as a default argument for functions, because XQuery does not define a current context node??? Is this a bigger issue, or a non-issue?
Subsumed by: #xquery-implicit-current-node.
How should the current node be passed to a function in a path-step?
Using dot notation (".").
Text is in Working Draft 2001-11-28 sec 2.1.1.2, paragraph 4.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What should the the result of various aggregate functions when applied to the empty sequence?
null-aggregates-on-empty: Aggregate functions on empty sequences http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0185.html Status: The XPath TF recommends that we reopen this issue. We will do a straw poll with the WG on this recommendation. The Chair views the public pushback we have received on this topic as sufficient reason for re-opening this issue: http://lists.w3.org/Archives/Public/www-xpath-comments/2002JanMar/0013.htmlhttp://lists.w3.org/Archives/Public/www-xpath-comments/2001OctDec/0010.html (point 8)
Paul Cotton - Do we re-open this issue? Straw poll taken - Yes: 10 No: 0 Abstain: 8
The XPath TF should take this matter back under review.
Action A-87-06 - Paul Cotton to convey to XPath TF that issue is re-opened and the WG would like to receive some proposed changes.
As in SQL, count(()) returns 0, and all other aggregate functions return the empty sequence. This rule is familiar to SQL users and minimizes the complexity of SQL-based XQuery implementations.
Decision by: xpath-tf on 2002-01-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0312.html)
Decision by: xquery on 2002-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0057.html)
Decision by: xsl on 2002-04-04 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Apr/0012.html)
Change semantics of sum() on () to 0.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
There seems to be a lot of material missing here, for example the rules for disambiguating operator names from NCNames, the two uses of "*", etc. The statement "the longest possible token" means the longest sequence that would form a token in the token-space of the grammar, not the longest that would be valid in the current syntactic context.
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
These problems were solved in the 2002-08 draft.
is and isnot instead
of == and !==.Should we use is and isnot
instead of == and !==. Using
keywords would be clearer, and less prone to error. On
the other hand, introduction of more keywords could cause
more controversy.
At Reston F2F, we agreed to infix operators 'value=', 'value<', 'node=', 'node<'. Next WD should reflect this decision.
Text is in Working Draft 2001-11-28 sec 2.6.2.
Decision by: xsl on 2002-02-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0005.html)(joint meeting)
Decision by: xquery on 2002-02-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0005.html)(joint meeting)
Decided to change to "is" and "isnot"
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
I think this issue should be closed. The (x,y) form seems to do fine after all.
Use ',' as in XQuery.
Should leading minus/plus be treated as unary operators or as part of a numeric literal? Or should both be supported?
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html)
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Why is axis availability part of the run-time context? Myaxis::foo should be a syntax error. This seems like a really clunky mechanism for subsetting. The alternative, as Mike Kay presented, is to provide a set of booleans telling if the given axis is available.
Proposed resolution: Axis subsetting should be done at the grammar level, similar to how XSLT pattern matching is specified.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Done at grammar level.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
XPath supports 13 axes. The current Working Draft says that XQuery will support a subset of these axes, including at least those axes required by the abbreviated syntax. The definitive set of axes to be supported by XQuery has not yet been determined. In the current Working Draft, the examples use abbreviated syntax, but the grammar supports unabbreviated syntax.
For the axes required by the abbreviated syntax, should XQuery allow both the unabbreviated and abbreviated syntax? If we decide not to support additional axes, no new functionality would be added by supporting the unabbreviated syntax. Opinions vary as to whether the unabbreviated syntax is clearer.
Text is in Working Draft 2001-11-28 sec 2.3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html) Decided: additional axes will not be included in XQuery Version 1.
The XML Query WG has decided not to support the full set of XPath axes in Version 1. We are trying to keep XQuery small, and that means we want to avoid providing the same functionality in multiple ways unless there is a compelling reason to do so. We also felt that we could easily add the full set of axes in future versions if users clearly demand it.
Experienced XPath users leverage the full set of axes to express complex queries. In examining many XPath expressions, we have found that they can be expressed in XQuery using other features, often using FLWR expressions. The two different approaches use different idioms, and are based on different programming models. We decided not to try to support both models, because it increases the learning required to master the entire language, and increases the probability that distinct user communities will evolve, and they will have difficulty reading each other's queries.
Another reason for not supporting the axes in Version 1 is that they have a lot of semantics, and these can be a burden for an optimizer. An implementation may well be able to do precedes or follows efficiently without an efficient way to perform all the enumerations required by the axes. For instance, an implementation may be able to efficiently determine whether one node is before another node (which means it supports 'precedes' efficiently), yet still have no efficient way of listing all nodes that precede a given node in reverse order (which is required to support the 'preceding' axis). And these axes come in pairs, so an implementation must be able to enumerate the nodes in either document order or reverse document order. Interactions between forward and reverse axes can also be tricky for query optimizers.
We also note that it is easy to write a function library that mimics the axes.
Decision by: xquery on 2003-06-25 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0031.html)
Consensus of the XQuery group to make all of the axes (minus namespace) optional as a set (all or nothing).
The XPath task force has recommended that we allow any expression in a path step. Proponents note that this adds to the symmetry of the language. Opponents note that this allows queries to be written that are very difficult to read, and may raise some issues for optimization. This needs further study.
Text is in Working Draft 2001-11-28 sec 2.3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
The use of full expression syntax in a step of a path expression has been recommended by the joint Query/XSLT Task Force but has not yet been approved by the respective Working Groups. In the examples and use cases we have, this is currently used mainly to allow union at any level in a path expression. The use of full expression syntax in this document is subject to Working Group approval.
Subsumed by: #xquery-step-expressions.
While $x[2] and $x[2]/baz are perfectly fine, should we disallow baz/$x[2]?
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Yes, variables should be disallowed on right side of slash.
Text is in Working Draft 2001-11-28 sec 2.3.
While 'abc'[2] is OK, what about 'abc'/baz?
Text is in Working Draft 2001-11-28 sec 2.3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Should nonsensical expressions like attribute::comment() outlawed?
Decision by: xpath-tf on 2002-01-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0312.html)
Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)
Decision by: xsl on 2002-02-07 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Feb/0034.html)
No explicit syntax restrictions on invalid step expressions.
XPath 1.0 effectively requires that each step in a path expression eliminate duplicate node-ids and sort the results in document order. (There is some controversy about terminology here: some people claim that the result of a step is somehow "unordered" even though it is subject to positional predicates such as [5] which means "the fifth element".) XQuery has a need for an iteration mechanism that preserves order and duplicates. XQuery can accomplish this goal by using a syntax such as FLWR that is separate from XPath.
Status: On 9/19/01 the Query WG agreed that no change to XPath 1.0 is needed in this area.
Does a path expression preserves the order of its input or document order? When do these differ? We need to make our discussion of this more precise.
Subsumed by: #xquery-xpath-slash.
XPath 1.0 effectively requires that each step in a path expression eliminate duplicate node-ids and sort the results in document order. (There is some controversy about terminology here: some people claim that the result of a step is somehow "unordered" even though it is subject to positional predicates such as [5] which means "the fifth element".) The XQuery group has talked about path expressions in which the steps do not eliminate duplicates or sort the result in document order.
Subsumed by: #xquery-xpath-slash.
When an empty element is linearized, should it get xsi:nil="True"? Option 8A: Yes. Option 8B: No. Option 8C: Only if it is declared to have required content and to be "nilable".
Decision by: xquery on 2003-01-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0146.html)
We just agreed that elements which are nilled will keep the xsi:nil attribute. As a consequence I think we can close the issue by serializing the xsi:nil attribute like any other attributes, and not have any special rules for empty elements.
An extensibility mechanism needs to be defined that permits XQuery to access a library of functions written in some other programming language such as Java.
Some sources of information: the definition of external functions in SQL, the implementation of external functions in Kweelt.
Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)
Decided to adopt 1B and 2A in proposal for issue #xquery-module-syntax.
Should we say something about the fact that XPath is meant to be a abstract specification? I am concerned about people getting the impression that XPath can be used by itself. Maybe it can be, and maybe this is OK.
Input from Paul Cotton:
Input from Michael Rys:
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Action to Michael Rys to propose alternative text to resolve issue.
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
XQuery WG approves wording in: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0312.html with a change so that "cannot" is changed to "should not" and Paul Cotton to convey changes to the XPath TF and XSL WG. Note: This text should be added to a new Conformance section in the XPath 2.0 specification.
Thus the proposed text is:
XPath is intended primarily as a component that can be used by other specifications. Therefore, XPath relies on specifications that use XPath (such as [XPointer] and [XSLT]) to specify criteria for conformance of implementations of XPath and does not define any conformance criteria for independent implementations of XPath. Specifications that set conformance criteria for their use of XPath should not change the syntactic or semantic definitions of XPath as given in this specification. |
Decision by: xpath-tf on 2002-03-05 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Mar/0011.html)
There is great concern in the XSL WG about the proposed last sentence. An alternative one was accepted by the XPath TF for approval by the WGs:
Specifications that set conformance criteria for their use of XPath must not change the syntactic or semantic definitions of XPath as given in this specification; except by subsetting and/or extensions in compatible ways.
Decision by: xquery on 2002-03-13 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0292.html)Accepting the XPath TF proposal
Decision by: xsl on 2002-04-04 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Apr/0012.html)
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
The division of path expressions into relative and absolute isn't reflected in the syntax. I think it's best to define the semantics as follows: / is an abbreviation for root(), /expr is an abbreviation for root()/expr, and // is an abbreviation for "/descendant-or-self::node()/". If the first step is an AxisStepExpr, add "./" in front of the expression. All unabbreviated paths now take the form OtherStepExpr ( '/' StepExpr )* and we only need to define the semantics of this kind of path expression.
Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)
The current WD text reflects suggestions.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
XPath defines some operators on lists in ways that differ from most commonly used languages. For example, if $X is a list, $X+1 is defined as the result of adding 1 to the first element in $X (ignoring the other elements.) XQuery takes a more regular approach to operations on lists, as described in the section on functions. For example, if the function increment(integer) is defined to add 1 to its argument, then the function call increment($X) where $X is a list of integers will return a list in which every member has been incremented by 1.
This issue needs more study, which should probably occur on the joint task force between XML Query and XSL. Operations on lists may be one area in which work is needed to evolve the XPath specification toward Version 2.0.
It is very desirable that operators such as "+" occur only once in the grammar, not separately in the "XPath" and "non-XPath" parts of the language. This probably means that path expressions should be integrated into the XQuery grammar and not treated as a "terminal symbol." This is the approach that has been taken in the current CUP and JavaCC grammars.
Expressions involving operators must also be carefully defined. We expect this to be handled by the task force on operators and the XPath 2.0 task force.
This is the charter of the XPath and F&O task force.
A complete list of XQuery operators and core functions is needed, with their signatures (datatypes of operands and results).
Sources of information: XPath specification, operator lists presented at recent F2F meetings by Frank Olken and others.
Note: The Query Working Group and the Schema Working Group have agreed to spawn a joint task force to investigate this issue. The XQuery language will integrate the results of that work.
This is the charter of the XPath and F&O task force.
Should the syntaxes of XQuery and the XML Query Formal Semantics be more closely aligned?
At the time this issue was originally proposed, XQuery and the Formal Semantics used distinctly different languages. We are now in the process of aligning these languages. The current Working Draft shows significant progress in this direction. However, more work is to be done with respect to type declarations and the use of type in the language.
The XQuery algebra is a proper subset of XQuery, in particular, the XQuery Core.
The algebra mapping is incomplete and out of date.
Jerome has created a new version of the mapping, with help from Mary, Dana and Mugur.
Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)
Can we please close this issue as a duplicate given that we have now added all the FS issues to the main issues list?
/paulc
The precedence rules of XQuery and the algebra are not completely aligned. This needs to be fixed by the time both specifications are finished.
The XQuery algebra is a proper subset of XQuery, in particular, the XQuery Core, so the algebra has the same set of precedence rules as XQuery.
We need functions to return the name of an attribute and the content of an attribute.
My proposal is to create a separate section in the F&O document listing the accessors in the data model that are supported. The semantics would still be specified in the data model document. Similarly, we would add a section that listed the functions in the evaluation context that are supported. The semantics for these functions would be in the XPath document as decided this morning.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Section "Accessors" has been added to F&O.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Queries should be able to return references; for instance, a query that generates a table of contents should also be able to create references to the items in the content itself. How can we extend the syntax to support this?
XPath TF and XQuery WG resolved to remove references from the data model. Query must use some explicit reference mechanism (e.g., ID or key) to reference a particular node in a document
Does the dereference operator work on links, such as XLink or HTML href? Should we also support KEY/KEYREF? In general, our handling of references needs a lot of work.
In general, how are the semantics of the dereference operator defined?
Text is in Working Draft 2001-11-28 sec 2.3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-02-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0015.html)
Acceptance of text in December 2001 published Working Draft, that it does only id/idref.
Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html) Verifying that the text that the text is in the draft. Note: there is also a proposal on the table to remove => entirely.
Decision by: xquery on 2002-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/att-0110/01-minutes_020516pm.txt)
We will keep the dereference operator.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
The XML Query WG revisited issue 134 and decided to close the issue by removing => completely. This was not unanimous decision.
Decision by: xsl on 2002-05-23 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002May/0123.html)The XSL WG agrees with the change to remove =>.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Our current syntax uses an empty end tag ("</>") as the end tag for element constructors that use computed element names. Should we allow this for element constructors with literal element names?
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
If a list of expressions contains adjacent element constructors, should a comma appear between these element constructors?
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
We need a function for constructing attributes.
The attribute function takes two parameters. The first is the name of the attribute to be constructed. The second is the value of the attribute to be constructed. If an attribute function occurs within an element constructor, the attribute is added to the set of attributes for that element.
<foo> IF $f/temp > 200 THEN
make_attribute("warning", "about to explode!!") ELSE []
</foo></foo>
|
Note Dana and Phil's exchange re: typing when attribute names are not statically known.
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
XQuery currently allows computed attribute values without quotes, which is not well-formed XML:
<foo bar={//baz} />
|
In XSLT, the equivalent syntax uses quotes:
<foo bar="{//baz}" />
|
Should XQuery adopt the XSLT convention? This would make it easier for XQuery to reside in well formed XML documents.
Text is in Working Draft 2001-11-28 sec 2.8.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
The current syntax for computed elements and attributes uses a syntax that looks like XML but is not well-formed XML.
<{name($e)}> # replicates the
name of $e {$e/@*} # replicates the attributes of $e
{2 * number($e)} # doubles the content of $e
</>
|
This makes it hard to embed queries that use this syntax in well-formed XML documents. Also, the Formal Description uses a syntax for element and attribute construction that is more suitable for use with inference notation. Should an alternative construction syntax be used that eliminates both problems?
Text is in Working Draft 2001-11-28 sec 2.8.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
(From Algebra team): We think it would be helpful to
have two syntaxes for construction, algebra a[. .
.] as used in the Algebra and <a> . .
. </a> as used in XQuery. Not least, the
a[. . .] syntax matches the syntax used in
the Algebra for types.
Subsumed by: #xquery-computed-element-names.
We do not believe it is helpful to have two syntaxes for the same thing, and we do not feel that this suggestion would make XQuery easier to read or use. In any case, square brackets are used in XQuery to enclose predicates and are not available for the suggested purpose.
The current EBNF lacks productions for comments and processing instructions.
Text is in Working Draft 2001-11-28 sec 2.8.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Since an XQuery may physically reside in an XML document, comments that rely on the concept of end-of-line can result in anomalies due to XML whitespace normalization. We should probably use bounded comments.
One possible syntax for comments:
{- - This is reminiscent of XML,
but without angle brackets. - -}
|
Subsumed by: #xquery-comment-pi-productions.
Is there a need for a constructor that creates an instance of the XML Query Data Model from a string that contains XML text?
Close the issue, pending convincing use cases. When do we need to be able to create a string of XML text, then convert it into an instance of the XML data model? Can't there always be an intervening parser or other tool to create the XML data model instance?
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Not for XQuery 1.0.
In attribute constructors and string constructors, XQuery uses quotes or apostrophes as delimiters. How are these characters escaped when they occur within strings that are created by one of these constructors?
Input from Michael Rys:
I asked a member of my team to check for a resolution that he can live with. He said he has not found it and currently works on constructing examples that shows the open issue. |
I propose that we use double-delimiters within a string literal, e.g. 'I don''t', and unlike most of my syntactic ideas, this proposal seemed to recieve general support.
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0204.html)
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Syntax in current draft has this, but explanatory text need to be added.
Copy and reference semantics must be defined properly for updates to work. This must be coordinated with the algebra team.
Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)
Subsumed by #node-identity-modeling
Can a query construct an entire XML document? What restrictions are there, eg on the internal subset, processing instructions or comments on the root level?
The constructor we propose does nothing except create a document node,
and is very simple. The documents constructed in this way can be
validated, fed to functions that save them or send them as messages,
or used in any other way that document nodes may be used in XQuery.
Currently, we can construct any node in our data model except for the
document node. For instance, we have the following constructors for
element and attribute nodes:
[66] ComputedElementConstructor
::= "element" (QName | EnclosedExpr) "{" ExprSequence? "}"
[67] ComputedAttributeConstructor
::= "attribute" (QName | EnclosedExpr) "{" ExprSequence? "}"
We propose an analogous syntax for document nodes, except that there
is no need to create the QName for a document node, which does not
have one:
DocumentNode ::= 'document' '{' ExprSequence '}'
A document node constructor creates a document node. It does nothing
else. It does not associate the document node with a schema or DTD,
specify a file name for it, validate the instance, assign file
permissions, or shine shoes.
Appendix: Interesting things that are not part of document node
construction
Here are many things people want to do with documents. None of these
are part of document node construction, but all of these things
benefit from document nodes.
1. Validating a node
Once created, a document may be validated, eg:
let $d := document {
<?xml version="1.0"?>
<greeting>Hello, world!</greeting>
}
return validate($d)
2. Saving a node to the file system
This is best done using a function that specifies the URI, and any
other parameters that the system may need. The signature for such a
function may look like this:
save-document( document $docnode, anyURI $name, element file-params? $p)
The file-params element could be used to store information on file
permissions, etc.
Appendix: Issues
Issue: How should schemas be imported for validating a document using
the document node?
Consider the following example:
<stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:html="http://www.w3.org/1999/xhtml"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://www.w3.org/1999/XSL/Transform
http://www.w3.org/1999/XSL/Transform.xsd
http://www.w3.org/1999/xhtml
http://www.w3.org/1999/xhtml.xsd">
I think this is no different from validating an element node. A root
element may identify namespace prefixes. Names must be defined in the
in-scope schema definitions before they can be used for
validation. With or without the document node, a schema location may
be specified on an element. Implementations should be free to use this
location to locate a schema or to ignore it, as in XML Schema.
Issue: Should we allow a DOCTYPE in a document constructor?
Consider the following example:
let $d := document {
<?xml version="1.0"?>
<!DOCTYPE greeting SYSTEM "hello.dtd">
<greeting>Hello, world!</greeting>
}
return validate($d)
If a DOCTYPE is specified, should it be used, as it would be by most
XML processors?
|
Decision by: xquery on 2002-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/att-0110/01-minutes_020516pm.txt)
Cotton: Any objections to adopting this proposal as written by Jonathan? One objection by Michael Rys. Proposal is adopted with one objection.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What does <a b={expr}> mean if expr returns an empty sequence? Option 10A: Attribute is not created. Option 10B: Run-time error. Option 10C: The attribute is created, and its value is the empty sequence. Option 10D: The attribute is created and its value is the empty sequence if this is allowed by the attribute type; otherwise it's a run-time error. Option 10E: The attribute is created and its value is the empty sequence. However, an error may occur when the attribute is serialized. Option 10F: If the attribute-type is a list of scalar types that allows the empty list, an attribute is created with an empty sequence as its value; if the attribute is optional and scalar, then the attribute is not created. If the type system does not allow the attribute to be an empty list or absent, a type error is raised.
Decision by: xquery on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)
Adopt 10C.
Decision by: xpath-tf on 2002-05-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002May/0037.html) Verifying that the text that the text is in the draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
If an element constructor contains a namespace declaration in XML syntax, is the namespace declared in the query?
<foo:bar xmlns:foo="//www.foo.com/foo.xsd">
<foo:baz>
Is this baz in the 'www.foo.com' namespace?
</foo:baz>
</foo>
|
Text is in Working Draft 2001-11-28 sec 2.8.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Do we need a way to embed literal XML content in a query? For instance, should there be a way to construct an XML element using the native syntax of XML?
Current XQuery syntax supports literal XML constructors
Do we need a way to escape from XML to XQuery syntax? This could be used to provide functionality similar to that of ASP or JSP.
Subsumed by: #xquery-embedding-xml.
A variety of XML constructs can not be cut and paste into XQuery, including the internal subset, entities, notations, etc. Should we attempt to ameliorate this?
Decision by: x-editors on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Feb/0010.html)
Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)
Close the issue with no change to the documents.
XQuery needs an XML representation that reflects the structure of an XQuery query. Drafts of such a representation have been prepared, but it is not yet ready for publication.
Decision by: xquery on 2003-10-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0002.html)
An XQueryX Working Draft will be produced that:
a) includes a trivial embedding (single XML start and end tag which can be used with the readable syntax)
b) a detailed embedding based on a parse tree of the Last Call XQuery grammar with no redundant BNF productions and which expands all XPath steps.
c) defines a MIME type for XQuery.
Is there a need to be able to escape to ABQL in XQueryX?
The text is confused. ABQL was the old name of XQueryX. The real issue is should be whether XQueryX and XQuery can escape to each other.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Not for XQuery 1.0.
The ORDERBY operator of XQuery can be used to order a sequence of elements by some computed expression which may return an empty value. What is the resulting order? For example, in the query //emp SORTBY bonus, what is the position of employees who have no bonus? Option 15A: Implementation-defined, but a given implementation must sort all the values with an empty sort-key consistently either first or last (as in SQL). Option 15B: Empty sort-keys always sort first. Option 15C: Empty sort-keys always sort last. Option 15D: Invent some syntax to specify how empty sort-keys should be handled.
Text is in Working Draft 2001-11-28 sec 2.10.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Should we make it easier to sort by data that is not exposed in the result? Although the current language allows this, it is difficult to define complex sort orders in which some items are not exposed in the result and others are computed in the expression that is sorted. Is there a more convenient syntax for this that would be useful in XQuery?
Here is an example: FOR $e IN //employee WHERE ... RETURN <newe>$e/name</newe> SORTBY -- Now I would like to sort by salary but cannot. Instead, the query would have to be written as FOR $e IN (FOR $x IN //employee RETURN $x SORTBY employee/salary/data()) WHERE ... RETURN <newe>$e/name</newe> Which seems awkward. The question is of course how we can integrate the SORTBY in an other way. For example, could we say FOR $e IN //employee WHERE ... SORTBY $e/salary/data() RETURN <newe>$e/name</newe> ? Best regards Michael |
Decision by: xquery on 2002-09-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0236.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)Confirming that there are no concerns for the resolution of this XQuery only issue.
Resolved by the adoption of the proposal to add "orderby" to the FLWR expression and to drop the previous "sortby" syntax/
Which of the following meanings is preferred for X BEFORE Y? (In each case, X AFTER Y would have the symmetric meaning.)
(1) X and Y are node sequences. Return the nodes in X that occur before some node in Y. This is the current definition.
(2) X and Y are node sequences. Return the nodes in X that occur before all nodes in Y. This is similar to the current definition and may be a better match for our use cases.
(3) X is a node sequence and Y is an individual node. Return the nodes in X that occur before Y. If YS is a node sequence, the meanings in (1) and (2) can be expressed as "X BEFORE YS[last()]" and "X BEFORE YS[1]".
(4) X and Y are both individual nodes. Return True if X occurs before Y in document order, otherwise False. If XS and YS are node sequences, the meaning in (1) can be expressed as "FOR $x IN XS [SOME $y IN YS SATISFIES $x BEFORE $y] RETURN $x". The meaning in (2) can be expressed similarly, substituting "EVERY" for "SOME".
Decision by: xsl on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)
Decision by: xquery on 2001-12-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0047.html)(joint meeting)
Reflected in Working Draft 2001-11-28 sec 2.4.
XQuery needs a mechanism to allow function definitions to be shared by multiple queries. The XQuery grammar allows function definitions to occur without a query expression.
We must provide a way for queries to access functions in libraries. For instance, we might add an IMPORT statement to XQuery, with the URI of the functions to be imported. It must be possible to specify either that (1) local definitions replace the imported definitions, or (2) imported definitions replace the local ones.
Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)
Decided to adopt 1B and 2A in proposal for issue #xquery-module-syntax.
If a function name is not qualified by a namespace prefix, what namespace is the function in? Some options that have been suggested: the function might be considered to be in no namespace, in a default namespace, or in the namespace of XQuery's built-in functions.
Text is in Working Draft 2001-11-28 sec 3.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Should XQuery support general recursion, or should it be limited in some way? Status quo: XQuery currently supports general recursion.
Reference: XML Query Algebra Issues
[Issue-0008] Fixed point operator or recursive functions]
[Issue-0032] Full regular path expressions]
Status quo: XQuery currently supports general recursion.
Marton Nagy has suggested that it would be helpful to describe a naive implementation strategy for XQuery.
A naive XQuery implementation might parse the query, map it to Algebra syntax, and pass it to an Algebra implementation to request type checking from the algebra, returning an error if there were static type errors. A naive implementation might then request query execution from the algebra, get the results from the algebra and return it to the user.
Alternatively, the implementation might have its own algebra for execution, or it might generate statements in a specific implementation language such as XPath or SQL.We expect a wide variety of implementation approaches to be used in practice.
Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)
People propose to close it. Approved. We don't have cycles, and the FS can be used as the basis for a naive implementation.
Consider adding a fusion operator to XQuery. Michael has supplied us with a few queries in which fusion would be helpful, and fusion seems promising as a feature, but we have not yet done adequate study of this issue. We would like to explore a wider set of use cases to make sure that we take a general approach to the problems related to fusion.
This requires further study. Use cases will need to be developed to determine precisely what forms of a fusion operator are actually helpful for data integration. An extensive and informative thread on this topic can be found in the W3C archives, starting at http://lists.w3.org/Archives/Member/w3c-archive/2000Dec/0132.htmllists.w3.org/Archives/Member/w3c-archive/2000Dec/0132.html.
Fusion is still not well motivated by use cases, despite fairly extensive discussion. External functions may be important, but we do not think it is worth doing right now. There is also an argument for omitting them because they limit the optimizations that can be done in the rest of the language.
Withdrawn 2001-12-07.
Dana has observed that Filter can be a function rather than an operator, if nodes have identity.
Filter is now a function, where the first parameter is the expression to be filtered, and the second parameter is the filter expression. We find this more elegant.
The above is obsolete (2001-12-07); filter is now a single-parameter function.
The current mapping of filter to the algebra does not preserve much useful type information. Can the mapping be improved? Is there another approach to filter that would yield better type information?
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Filter no longer exists.
We believe that a syntax for update would be extremely useful, allowing inserts, updates, and deletion. This might best be added as a non-normative appendix to the syntax proposal, since the algebra is not designed for defining this portion of the language.
Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)
We have agreed to publish a note on updates.
Do we need a way to define views?
While a mechanism for view definition is desirable, we do not currently intend to provide one in Level 1.
How do we exclude undesired elements from the results of joins?
This need came out of a thread exploring data integration scenarios, starting with http://lists.w3.org/Archives/Member/w3c-archive/2000Dec/0132.html.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
This can be done using "except".
Is there a need to be able to execute a string that contains the text of an XQuery query? (This is similar to the eval function in Lisp.)
No in Version 1.0
Does XQuery need an explicit GROUPBY expression? This would not add expressive power, but would be convenient, and may be easier to optimize.
Decision by: xquery on 2003-03-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0344.html)
Decided to close with no action.
The final XQuery recommendation must have a conformance section. The XML Query Working Group has not yet decided what should go into this section.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
This section is now included.
How are collections of documents named and addressed in queries? How are they associated with files in directory structures, or resources in various systems? How does one address documents within collections?
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
This is addressed by xf:collection().
Should the operands be restricted?
Suggestions floated:
Decision by: xpath-tf on 2001-10-23 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Oct/0286.html)
Decision by: xquery on 2001-10-31 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Oct/0441.html)
Consensus to restrict operands of "/" to node sets, i.e., every step expression must yield a node set otherwise an error is raised.
This decision will be reflected in next WD.
Decision by: xsl on 2001-10-25 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Oct/0122.html)
operands to / - discussed but we wish to await the resolution on how /data() is handled.
Decision by: xsl on 2001-12-13 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Dec/xxxx.html)
Agreed to limit operands no nodesets.
Text to that effect is in Working Draft 2001-11-28 sec 2.3.
Should small set of functions on nodes, i.e., data(), name, uri-namespace(), be defined on node sequences and have an implicit mapping semantics?, e.g., data(a/b)
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
Adopt status quo.
If we have polymorphism in the operator, should we have only one fallback?
Matching Operands with Polymorphic Operators
Consider the operator +. Assume, purely for illustration, that + is
defined on numerics, strings and a date and a duration. When the
interpreter sees "op1 + op2" how does it decide what function to call.
Here are the rules by example for +:
- If op1 and op2 are numerics it accepts the operands and calls
the appropriate function based on the numeric promotion rules described
below.
- If op1 and op2 are strings it accepts the operands, converts
both operands to string and calls the string-concat function.
- It then checks if the first operand is a date and the second
operand is a duration. If so, it calls the add-duration-to-date
function.
- If none of the above rules works a type exception is declared.
Depending on the host language and the environment (as indicated by a
global variable) one of two actions occurs:
o A fallback conversion is attempted. Fallback conversions are
described in detail in the XPath straw document
o A type error is declared. When an error is declared the process
aborts. This means that functions never have to deal with error inputs.
This is a logical specification of how the process works.
Implementations are free to create implementations that differ from the
above as long as they obey the semantics defined in the F&O document.
For example, 10 div 3 should return 3.
Numeric Type Promotions
For simplicity, each operator is defined to operate on operands
of the same type and to return the same type. If the two
operands are not of the same type, one operand is promoted to be the
type of the other operand.
Numeric types have the following hierarchy :
integer->decimal->float->double
Note that we need to take user-defined types into account. For
example, a user may define height as a derived type of integer with a
minimum value of 20 and a maximum value of 100. He may then derive
oddHeight using a pattern to restrict the value to odd integers.
If op1 is of type oddHeight. We first promote it to its base
type, integer. If op1 and op2 are now both integers we call addInteger
or whatever the appropriate function is.
If not, we see which of the operators is higher in the above
hierarchy and promote the other until we get two integers or two
decimals or two floats or two doubles. This is guaranteed to occur.
Then we call the appropriate functions for the operands.
The F&O document contains details of numeric type promotions.
|
Text is in Working Draft 2001-11-28 sec 2.5.
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)
Acceptance of text in December 2001 published Working Draft.
Do we still need fallbacks if we have a marker for untyped data (="PCDATA")?
Input from Mary F. Fernandez:
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html) Acceptance of text in December 2001 published Working Draft.
Text is in Working Draft 2001-11-28 sec 2.5.
I discussed this issue with Mary on the phone today, and we have
developed the following modified version of her original proposal. The
key difference is this:
1. In the data model, the type name 'anySimpleType' is used everywhere
that 'unknownSimpleType' was used in her original proposal. This
avoids the problems discussed in:
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0173.html
2. In the SequenceType production, the keyword 'unknown' matches
values whose most specific type is 'anySimpleType'.
Jonathan and Mary
=================
This message proposes, in summary, that XQuery/XPath must have a type
for Text Nodes, denoted by the reserved word 'text', and a type for
Atomic Values with unknown simple type, denoted by the type name
'anySimpleType' in the Data Model. In the SequenceType production, the
keyword 'unknown' matches values whose most specific type is
'anySimpleType'.
Rationale:
XQuery/XPath supports expressions that yield two *distinct* types of
values:
1. Text nodes, which have identity and contain character data
Example:
let $e := <fact>I saw 8 cats</fact>
return $e/text()
This expression yields a Text Node (that has identity!) with type
'text'.
2. Atomic values with unknown simple type, which no not have identity
and contain character data
Example 1:
let $e := <fact about="what I saw">I saw 8 cats</fact>
return data($e)
This expression yields an Atomic Value (that does not have
identity!) with type 'anySimpleType' Example 2: data($e/@about)
This expression also yields an Atomic Value with anySimpleType.
In a typed language, every value must have an associated type.
Neither value above currently has a type in XQuery/XPath. In
addition, Text Nodes and Atomic Values with unknown simple type do not
denote the same set of values, therefore, they must have distinct
types.
Both these types may occur wherever a type expression is permitted,
e.g., in the SequenceType production. However, note that the type name
'anySimpleType' matches all simple types, since they are all derived
from 'anySimpleType', whereas the keyword 'unknown' matches only
values whose most specific type is 'anySimpleType'.
The formal semantics already constructs core expressions that require
both 'text' and 'unknown'. for example, here's the rule that converts
a node to an optional atomic value of type xsd:integer:
typeswitch (Expr) as $v
case xs:integer? return $v
case unknown return cast as xs:integer ($v)
case node return
typeswitch (data($v)) as $w
...
We use the type 'anySimpleType' for simple types because this type
explicity captures the notion that it is a simple type for which there
is no more specific known type. To simplify processing, we map all
PSVI representations of character data with unknown type onto this one
type.
Since our language needs a way to match only values whose most
specific type is 'anySimpleType', we add a keyword to the language,
rather than invent a new type for XML Schema. The functionality we
need is part of our language, not part of the XML Schema type system
that underlies our type system.
The necessity of associating a type to text nodes was first discussed
in Aug 2001:
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Aug/0209.html
|
Decision by: xquery on 2002-03-27 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0478.html) XML Query WG has resolved issue 174 and Strawman Issue 17 by adopting Proposal #1 Jonathan Robie's proposal above.
Decision by: xsl on 2002-03-28 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Mar/0084.html)
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html) Verifying that text is in current draft.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
The XML Query WG participants would like the XPath task force to propose a final name for the "not3" function.
Subsumed by :xpath-issue-not-logic.
A sequence that contains at least one node? A sequence that contains all nodes?
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
The proposal by Michael Rys in Proposal to close issue expr[nodes] treats not()/not3() differently from all other functions that take a boolean formal argument.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
The wording indicates that this is an issue on a proposal. There is no such thing as an issue on a proposal.
If there is an issue on the document, we need text identifying specifically what this issue is.
What shold the semantics be?
Decision by: xpath-tf on 2001-11-13 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0069.html)
Decision by: xquery on 2001-11-14 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Nov/0306.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
In XPath predicates only, if expression evaluates to a singleton number, then the predicate is true if the context position equals the singleton number, otherwise it is false.
There is no support for range expressions in XPath predicates.
Text is in Working Draft 2001-11-28 sec 2.3.3.1, paragraph 2, item 2.
Query fans: Which of the following is true?
(1) The substring function takes a string as its first parameter. $emp/address is a node. Therefore substring($emp/address, 1, 25) is a type error. To fix it the user must write substring(data($emp/address), 1, 25). Even then, if $emp does not happen to have an address, the function call is a type error and aborts the query.
(2) The first-parameter-type of substring should be "zero or one nodes or strings". The substring function (and virtually all of the other core library functions) does not have the correct signature in the F&O document. All these functions should be defined to accept nodes and extract their values, and to return the empty sequence if called with the empty sequence.
(3) There is a general convention that, when a function expects a simple value and it is called with a node argument, the typed value is implicitly extracted from the node and converted (if possible) to the appropriate type. Therefore the first-parameter-type of substring (and many other functions) in the F&O document should be "zero or one strings".
Curiously, --Don
Input from Michael Rys:
Input from mhkay@iclway.co.uk:
Input from Mary F. Fernandez:
Input from Jonathan Robie:
Input from Andrew Eisenberg:
Input from Michael Rys:
Input from Michael Rys:
Input from Jim Melton:
Decision by: xpath-tf on 2001-11-27 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Nov/0167.html)
Decision by: xquery on 2001-11-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Nov/0397.html)
Decision by: xsl on 2001-11-29 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2001Nov/xxxx.html)
Adopting basic conversion rules for applications of functions that expect simple-valued arguments.
Michael R will provide 'tips & traps' text indentifying potential backward compatibility issue if/when overloaded functions are added to XQuery/XPath.
Text is in Working Draft 2001-11-28 sec 2.1.2, paragraph 6.
Semantics of function application for functions that expect complex-valued arguments is not documented in current WDs.
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
The asssertion is no longer true; issue closed.
Should literals include integers & integer be treated as primitive type?
Input from Mary F. Fernandez:
Input from Kay, Michael:
Decision by: xpath-tf on 2001-12-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2001Dec/0128.html)
Decision by: xquery on 2001-12-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2001Dec/0150.html)
This issue is moot: integer literals are included in grammar and are modeled as simple-typed values.
The mapping from operators (such as "+", "*") to the operator functions needs to be defined. A second question is if the text should be in the F&O or XPath/XQuery document.
This belongs in the XPath document. Ashok will send a draft to Don, who will incorporate this in XPath post December 2001 publication.
Decision by: xpath-tf on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0108.html)Accepting Don's Proposal
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0066.html)(whole group at XPath TF telcon)
Decision by: xquery on 2002-01-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0345.html)Accepting Don's Proposal
Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)
Decision by: xpath-tf on 2002-04-30 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0201.html)Verifying that the table is in the current drafts and the issue is thus resolved.
Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.
Lexical structure and typed form of text nodes discussed in datamodel. No analogous discussion in the XPath document on that there are two ways to access information, as typed content or as nodes. This also needs to be discussed in conjunction with construction.
Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)
Decision by: xquery on 2002-10-23 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0467.html)
Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)
The datamodel now makes a clear distinction.
Need to extend languages to test for instance-of comments, pis, etc.
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html)
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
Should we do explicit casts rather than type conversion, like for example Python? This would result in e.g. forceing the user to tag a string everytime...
Addressed by the "Named Typing" proposal.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What should be the ordering of the results of the union, intersect, and except operators?
Issue is for material in sec 2.4. in Working Draft 2001-11-28.
Union, intersect, and except on node sequences are defined to return their results in document order.
Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)
Decision by: xquery on 2002-07-17 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jul/0329.html)
The issue is "dead", in the sense that the April draft contains text that everyone is happy with.
Decision by: xquery on 2002-10-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0303.html) XQuery WG approves of the text in the published draft resolving the issue.
What arithmetic operations should be supported on date/time types?
Issue is for material in sec 2.5. in Working Draft 2001-11-28.
Decision by: xquery on 2002-02-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Feb/0090.html)
Locus should be Functiond and Operators
Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)
This issue is closed (duplicate to an F&O issue).
What is the concrete syntax of the comparison operators?
Issue is for material in sec 2.6. in Working Draft 2001-11-28.
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
Make sure that the XPath/XQuery document is consistent with the F&O document with respect to the supported combinations of types for comparison operators.
Issue is for material in sec 2.6. in Working Draft 2001-11-28.
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)
The table has been moved to the XPath/XQuery document, thus ensuring that it is consistent with XPath/XQuery.
What operators are supported for comparing various objects based on their order?
Issue is for material in sec 2.6. in Working Draft 2001-11-28.
Decision by: xpath-tf on 2002-01-15 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0164.html)
Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)
Decision by: xsl on 2002-01-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Jan/0067.html)
Acceptance of text in December 2001 published Working Draft.
How is whitespace handled in element constructors?
Issue is for material in sec 2.8. in Working Draft 2001-11-28.
Input from Michael Kay:
The XQuery WG requested information from XSL WG
as to how we currently deal with whitespace, in the hope that we can provide
an off-the-shelf solution to the problem.
In response to the action, here's a description of what XSLT does.
The stylesheet is an XML document. In constructing its infoset, all
processing instructions, comments, and whitespace-only text nodes are
discarded. (To be absolutely precise, PIs and comments are discarded; then
adjacent text nodes are merged; then whitespace-only text nodes are removed
from the tree). Whitespace text nodes are retained however, in two
circumstances: (a) if the whitespace text node is a child of an <xsl:text>
element, and (b) if an ancestor element specifies xml:space="preserve".
Certain elements in the stylesheet (for example, xsl:element) contain a
"content constructor". A content constructor is a sequence of XSLT
instructions, literal result elements, and literal text nodes. In evaluating
a content constructor, XSLT instructions do whatever the semantics of the
particular instruction say, while literal result elements and literal text
nodes are copied to the result tree.
The effect of this is that a whitespace-only text node in the stylesheet is
copied to the result tree only if either (a) it appears immediately inside
<xsl:text>, or (b) it is within the scope of an xml:space="preserve"
attribute.
Whitespace that is adjacent to non-white text in a literal text node is
copied to the result tree.
The effect of these rules is as follows:
=======================================
<a> </a>
generates an empty element:
<a/>
=======================================
<a xml-space="preserve"> </a>
generates:
<a xml-space="preserve"> </a>
=======================================
<a><xsl:text> </xsl:text></a>
generates:
<a> </a>
=======================================
<a>
<b/>
<a>
generates:
<a><b/></a>
=======================================
<a>Some text
<b/>
</a>
generates:
<a>Some text
<b/></a>
=======================================
There are other complications with whitespace. Whitespace in the result tree
can come from the source document as well as from the stylesheet; XSLT
provides control over whether whitespace-only text nodes in the source
document are significant or not. Whitespace can also be generated in the
output during serialization, if the xsl:output option indent="yes" is
specified.
Also of course the XSLT rules apply in addition to the XML rules. XML for
example normalizes line endings and normalizes whitespace (but not
character references) in attribute values. This happens outside XSLT's
control. Whitespace character references such as are treated
differently from literal whitespace by the XML processor, but are treated
identically to literal whitespace by the XSLT processor.
It's fair to say that these rules create a fair bit of confusion. It usually
doesn't matter for generating HTML, because whitespace in HTML is rarely
significant. For generating text files, it can be quite tricky. However, the
rules are well-defined and a user who understands the rules can always get
the required output.
What should XQuery do? I'd suggest mimicking these rules as closely as
possible, if only because users then only have to learn one set of confusing
rules rather than two. I can't think of any obvious improvements that would
make the system less confusing. Where the user wants to explicitly output
whitespace, of course, <a>{' '}</a> provides a suitable alternative to
XSLT's <xsl:text> instruction.
This analogy would suggest that <a> {'x'} </a> should output <a>x</a>,
while <a>z {'x'} y</a> should output <a>z x y</a>: that is, the characters
between <a> and "{" are ignored if they consist entirely of whitespace, but
are all significant if any of them is non-whitespace. <a> </a> should output
<a/>, as should <a> </a>. This is only a suggestion, of course, the
decision is entirely for XQuery to make.
Mike Kay
|
Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)
Decided: Resolve this by adopting the whitespace proposal.
What is the type of a newly constructed element?
Issue is for material in sec 2.8. in Working Draft 2001-11-28.