XPath 2.0 and XQuery 1.0 Issues

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

1. xquery-xpath-productions: XPath Productions

Locus: xpath Cluster: grammar Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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.

Actual Resolution

This is the charter of the XPath task force.

2. xquery-precedence: Precedence of Operators

Locus: xquery Cluster: grammar Priority: o-1 Status: subsumed
Originator: Dana

Description

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.

Actual Resolution

Operator precedenced subsumed by XPath 2.0 WD.

3. xpath-issue-rangeexpr-precidence: What should be the precedence of a RangeExpr be?

Locus: xpath Cluster: grammar Priority: o-3 Status: resolved
Originator: Editor

Description

What should be the precedence of a RangeExpr? The XQuery grammar has it in a bit different place than is listed here.

Actual Resolution

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.

4. xquery-abstract-syntax: Abstract Syntax

Locus: xquery Cluster: grammar Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

Jerome and Mary have suggested that we abandon the separate abstract syntax for XQuery, in favor of a higher-level BNF.

Proposed Resolution

This is the BNF that now appears in Appendix B.

Actual Resolution

This is the BNF that now appears in Appendix B.

5. xpath-issue-reserved-words: Reserved words

Locus: xpath Cluster: reserved-words Priority: o-2 Status: resolved
Originator: XQuery

Description

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.

Interactions and Input

Cf. 5. Reserved Words:

Subsumes: #xquery-xpath-issue-reserved-words.

Cf. Keywords in XQuery

Subsumes: #xquery-reserved-keywords.

Actual Resolution

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.

6. xquery-xpath-issue-reserved-words: 5. Reserved Words:

Locus: xpath Cluster: reserved-words Priority: o-2 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by :xpath-issue-reserved-words.

7. xquery-reserved-keywords: Keywords in XQuery

Locus: xquery Cluster: reserved-words Priority: o-1 Status: subsumed
Originator: XQuery WG

Description

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.

Actual Resolution

Subsumed by :xpath-issue-reserved-words.

8. xquery-case-sensitive-keywords: Case-Sensitivity in Keywords

Locus: xpath Cluster: reserved-words Priority: o-1 Status: resolved
Originator: XML Query

Description

Should keywords in XQuery be case-sensitive?

Actual Resolution

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.

9. xpath-issue-implicit-conversion: Should implicit conversions be used?

Locus: xpath Cluster: type-conversions Priority: o-1 Status: resolved
Originator: Editor

Description

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.

Actual Resolution

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.

10. xpath-issue-conversions-for-arithmetic: Conversions for Arithmetic

Locus: xpath Cluster: type-conversions Priority: o-2 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

Addressed by XPath 2.0 basic and standard-fallback conversions. This is no longer an issue since both operands must be singletons.

11. xquery-xpath-coercions: XPath Type Coercions

Locus: xpath Cluster: type-conversions Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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.

Actual Resolution

Addressed by XPath 2.0 basic and standard-fallback conversions.

12. null-issue-arithmetic-on-sequences: Arithmetic on Sequences.

Locus: xpath Cluster: arithmetic-operators Priority: o-2 Status: resolved
Originator: XQuery

Description

XQuery-Null-Issue-3: Question: What should happen if an operand of an arithmetic operator is a sequence of length greater than 1?

Actual Resolution

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.

13. xquery-arithmetic-among-sequences: Arithmetic operators among sequences

Locus: xpath Cluster: arithmetic-operators Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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.

Actual Resolution

Addressed by XPath 2.0 basic and standard-fallback conversions. It's an error. See also: #xquery-xpath-arith-on-sets

14. xpath-issue-type-error-checking: Should type error checking be part of the context?

Locus: xpath Cluster: type-conversions Priority: o-1 Status: resolved
Originator: jmarsh@microsoft.com

Description

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.

Actual Resolution

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

15. xpath-issue-node-set-conversion: Implicit conversion of node-sets to boolean for comparisons.

Issue Class: TF Locus: xpath Cluster: choice-context Priority: 1 Status: resolved
Originator: XQuery, jmarsh@microsoft.com

Description

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.

Interactions and Input

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

Proposed Resolution

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.

Proposed Resolution

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

Proposed Resolution

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.

Proposed Resolution

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.

Actual Resolution

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.

16. xquery-xpath-nodes-to-boolean: 2. Converting node sets to Boolean

Locus: xpath Cluster: choice-context Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by :xpath-issue-node-set-conversion.

17. xquery-anything-to-boolean: Converting general expressions to Boolean

Locus: xpath Cluster: choice-context Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

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?

Actual Resolution

Subsumed by #xpath-issue-node-set-conversion.

18. xquery-xpath-arith-on-sets: 1. Arithmetic on node sets

Locus: xpath Cluster: choice-context Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

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.

Actual Resolution

Subsumed by #xpath-issue-node-set-conversion. Status: The Query WG approved this request on 9/19/01.

19. xpath-issue-null-value: How should null be treated in the data model?

Locus: xpath Cluster: nulls-empty Priority: o-1 Status: resolved
Originator: XSL WG

Description

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.

Actual Resolution

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.

20. null-missing-data: Representation of Missing Data

Locus: xpath Cluster: nulls-empty Priority: o-1 Status: subsumed
Originator: XQuery

Description

How should missing or unknown data be represented?

Actual Resolution

Subsumed by: #xpath-issue-null-value. Resolution: by an empty sequence.

21. null-on-input: Handling of xsi:nil on Input

Locus: datamodel Cluster: nulls-empty Priority: o-1 Status: resolved
Originator: XQuery

Description

Should elements with xsi:nil="True" receive any special treatment on input?

Actual Resolution

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.

22. xpath-issue-3valued-logic: Three-valued logic

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

The XSL WG resolved that three-valued logic should be used.

23. null-3value-logic: Three-valued Logic

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: subsumed
Originator: XQuery

Description

What logic should be used by the AND and OR operators?

Actual Resolution

Subsumed by: #xpath-issue-3valued-logic. Resolution: Three-valued logic using SQL truth tables.

24. xquery-xpath-3value-logic: 3. Three-valued logic

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

25. xquery-three-value-logic: Nulls, nil, and three-valued logic

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

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?

Actual Resolution

Subsumed by: #xpath-issue-3valued-logic.

26. xpath-issue-if-not-else: Should we default then to return an empty sequence?

Locus: xpath Cluster: 3-value-logic Priority: o-3 Status: resolved
Originator: marsh@microsoft.com

Description

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.

Actual Resolution

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.

27. null-if-where: IF and WHERE

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: subsumed
Originator: XQuery

Description

What is the behavior of IF and WHERE if the value of the branch-expression is the empty sequence?

Actual Resolution

Subsumed by: #xpath-issue-if-not-else. Resolution: IF takes the ELSE branch. WHERE does not execute the RETURN clause.

28. xpath-issue-not-logic: Do we need and3(), or3(), not3() built in?

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: postponed
Originator: XSL WG

Description

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.

Actual Resolution

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.

29. null-not-on-empty: Not() on Empty Sequence

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by: #xpath-issue-not-logic.

30. xpath-issue-null-handling-for-comparisons: Should comparison operations always return null if either of the arguments are null?

Locus: xfo Cluster: 3-value-logic Priority: o-2 Status: resolved
Originator: Editor

Description

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?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.6.

Actual Resolution

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.

31. xpath-issue-empty-sequence-comparisons: Empty sequence comparisons

Locus: xpath Cluster: 3-value-logic Priority: o-2 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

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.

32. xpath-issue-is-for-required: Do we really require for at the XPath expression level?

Locus: xpath Cluster: for-expr Priority: o-1 Status: resolved
Originator: K Karun

Description

Is for really a proper construct for a simple expression language? Will the definition of for in XPath cause problems for XQuery?

Interactions and Input

Input from Michael Kay:

Actual Resolution

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.

33. xpath-issue-simple-for: Do we need a simple form of for?

Locus: xpath Cluster: for-expr Priority: o-2 Status: subsumed
Originator: Editor

Description

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?

Actual Resolution

Subsumed by: #xpath-issue-is-for-required.

34. xpath-issue-range-variables-in-for-expressions: Does XPath require range variables in for expressions?

Locus: xpath Cluster: for-expr Priority: o-3 Status: subsumed
Originator: unknown

Description

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.

Actual Resolution

Subsumed by: #xpath-issue-is-for-required.

35. xquery-separation-of-flowers: Separation of clauses in FLWR

Locus: xquery Cluster: FLWR-expr Priority: o-1 Status: resolved
Originator: Algebra Editors

Description

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.

Proposed Resolution

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.

Actual Resolution

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.

36. xquery-quantifier-multiple-variables: Quantifiers with multiple bindings?

Locus: xpath Cluster: SOME-expr Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

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.

Actual Resolution

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.

37. xquery-xpath-datatypes: 6. Datatypes:

Locus: xpath Cluster: datatypes Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

XPath 2.0 to support all XML Schema primitive datatypes.

Text is in Working Draft 2001-11-28 sec 2.2.1.

38. xquery-datatype-constructors: XML Schema Datatypes Constructors

Locus: xfo Cluster: datatypes Priority: o-1 Status: resolved
Originator: Paul Cotton

Description

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.

Actual Resolution

Resolved in F&O document.

39. xquery-schema-type-promotion: Promotion Hierarchy for XML Schema Types

Locus: xfo Cluster: datatype promotions Priority: o-1 Status: resolved
Originator: Jonathan

Description

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.

Actual Resolution

Resolved in F&O document.

40. xquery-type-correspondence: Correspondence of Types

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

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.

Actual Resolution

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.

41. xquery-static-versus-validate: Static type-checking vs. Schema validation

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

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.

Actual Resolution

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.

42. xquery-type-conformance: Implementation of and conformance levels for static type checking

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: Don

Description

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.

Proposed Resolution

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.

Actual Resolution

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.

43. xquery-define-schema-variants: Defining Behavior for Well Formed, DTD, and Schema Documents

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: decided
Originator: Don Chamberlin

Description

We should specify the behavior of XQuery for well formed XML, XML validated by a schema, and XML validated by a DTD.

Proposed Resolution

The mapping of a DTD validated or well formed document still needs to be defined in the Data Model.

Actual Resolution

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.

44. xquery-schemaless: Support for schema-less and incompletely validated documents

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: subsumed
Originator: Don Chamberlin/Mary Fernandez

Description

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.

Proposed Resolution

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?

Actual Resolution

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.

45. xquery-names-type-definition: Names in Type Definitions

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: Don

Description

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

Actual Resolution

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.

46. xquery-typeof: typeof() function

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 3 Status: postponed
Originator: Jonathan

Description

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.

Actual Resolution

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.

47. xquery-subtype-substitutability: Subtype Substitutability

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 2 Status: decided
Originator: XQuery Editors

Description

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.

Interactions and Input

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,

Actual Resolution

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.

48. xquery-typeswitch-case-not-subtype: CASE not a subtype

Issue Class: T Locus: algebra Cluster: type-semantics Priority: 3 Status: decided
Originator: XML Query

Description

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?

Actual Resolution

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.

49. xquery-substitution-groups: Substitution Groups

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery Editors

Description

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?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.13.

Actual Resolution

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.

50. xquery-function-definition: Function Definition

Issue Class: TF Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery Editors

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 3.

Actual Resolution

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.

51. xquery-function-resolution: Function Resolution

Issue Class: TF Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery Editors

Description

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.

Proposed Resolution

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.

Actual Resolution

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.

52. xquery-collection-types: Collection types

Locus: xquery Cluster: type-semantics Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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.

Actual Resolution

Data model and type system both have sequences. This seems a moot issue.

53. xquery-unordered-collections: Support for Unordered Collections

Locus: xquery Cluster: type-semantics Priority: o-1 Status: resolved
Originator: Algebra Editors

Description

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?

Actual Resolution

XQuery editors considered and rejected addition of an unordered collection and type. The data model and type system support ordered sequences only.

54. xquery-invalid-content: Queries with Invalid Content

Locus: xquery Cluster: type-errors Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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?

Proposed Resolution

Addressed by the "Named Typing" proposal, but needs more work.

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Adopt status quo.

55. xquery-errors-static-dynamic: Static versus Dynamic Errors

Locus: xquery Cluster: type-errors Priority: o-1 Status: resolved
Originator: Algebra

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 3.

Actual Resolution

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.

56. xquery-type-syntax: Human-Readable Syntax for Types

Issue Class: T Locus: xquery Cluster: type-syntax Priority: 3 Status: decided
Originator: Algebra Editors

Description

The Algebra has a syntax for declaring types. Up to now, XQuery uses XML Schema for declaring types. Is this sufficient? Some important questions:

  1. Are type names sufficient, or does XQuery really need its own syntax for declaring types?
  2. Would Normalized Universal Names (derived from MSL) be sufficient for type names?
  3. How will type names be bound to definitions?

Actual Resolution

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

57. xquery-inline-xml-schema: Inline XML Schema Declarations

Issue Class: T Locus: xquery Cluster: type-syntax Priority: 3 Status: postponed
Originator: Don Chamberlin

Description

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

Actual Resolution

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.

58. xquery-schema-import: Importing Schemas and DTDs into query

Issue Class: T Locus: xquery Cluster: type-syntax Priority: 3 Status: resolved
Originator: Don Chamberlin

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 3.

Actual Resolution

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.

59. xpath-issue-instanceof-symantics: We need precise semantics for instanceof.

Issue Class: T Locus: xpath Cluster: INSTANCEOF-expr Priority: 1 Status: resolved
Assigned to: xquery Originator: mhkay@iclway.co.uk

Description

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?

Actual Resolution

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.

60. xquery-cast-expression: CAST expression

Locus: xquery Cluster: CAST-expr Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

Does XQuery need a CAST expression for casting an instance of one type into another type?

Actual Resolution

A "CAST AS" operator has been added to this current Working Draft.

61. xpath-issue-cast-operator: Do we need an explicit cast operator (or instead treat as)?

Locus: xpath Cluster: CAST-expr Priority: o-3 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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.

Actual Resolution

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)

62. xquery-mapping-cast: Mapping CAST AS

Locus: algebra Cluster: CAST-expr Priority: o-1 Status: resolved
Originator: Jerome Simeon

Description

The algebra does not have coercion functions between values. The mapping requires this for CAST AS.

Actual Resolution

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core, therefore includes CAST AS.

63. xquery-type-guard: Type Guard

Locus: xquery Cluster: TREAT-expr Priority: o-1 Status: resolved
Originator: Michael Rys

Description

Does XQuery require a syntax for type guards?

Actual Resolution

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.

64. xquery-remove-treat: Is TREAT AS necessary?

Locus: algebra Cluster: TREAT-expr Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

The functionality of TREAT can also be expressed using TYPESWITCH. A proposal to remove the TREAT expression is under consideration.

Actual Resolution

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. 'TREAT AS' is expressed in XQuery core as a TYPESWITCH.

65. xquery-cast-syntax: CAST and TREAT AS Syntax

Locus: xquery Cluster: CAST/TREAT-expr Priority: o-1 Status: resolved
Originator: Jonathan Robie

Description

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.

Actual Resolution

CAST/TREAT syntax has been pretty stable for a while. Can we just resolve this issue?

66. xquery-typeswitch: Typeswitch

Locus: xquery Cluster: TYPESWITCH-expr Priority: o-1 Status: resolved
Originator: Mary Fernandez

Description

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.

Actual Resolution

The XQuery algebra is a proper subset of XQuery, in particular, XQuery Core. TYPESWITCH is supported in both.

67. xquery-static-type-assertion: Static Type Assertions

Locus: xquery Cluster: ASSERT-expr Priority: o-1 Status: resolved
Originator: Mary

Description

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.

Proposed Resolution

Current proposal is for ASSERT AS Datatype (Expr)

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.13.

Actual Resolution

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.

68. xpath-issue-context-item: Do we need a Context Item, and, if so, how should it work?

Locus: xpath Cluster: context Priority: o-2 Status: resolved
Originator: Editor

Description

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?

Actual Resolution

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.

69. xquery-mapping-input-context: Mapping Input Context

Locus: xquery Cluster: context Priority: o-1 Status: resolved
Originator: Jerome Simeon

Description

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.

Actual Resolution

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.

70. xpath-issue-default-namespace: Does the context include a default namespace declaration?

Locus: xpath Cluster: context Priority: o-2 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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.

Actual Resolution

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.

71. xpath-issue-datatype-binding: Do we need a datatype names binding in the context?

Locus: xpath Cluster: context Priority: o-3 Status: resolved
Originator: Editor

Description

Do we need a datatype names binding in the context?

Actual Resolution

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.

72. xpath-issue-collation-bindings: How should qname-to-collation bindings be handled?

Locus: xpath Cluster: context Priority: o-2 Status: resolved
Originator: Editor

Description

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.

Actual Resolution

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.

73. xquery-collation-sequences: Collation Sequences

Locus: xpath Cluster: context Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

How are collation sequences created to define inequality and sort orders?

Actual Resolution

Subsumed by: #xpath-issue-collation-bindings.

74. xquery-module-syntax: Module syntax

Locus: xquery Cluster: module-semantics Priority: o-1 Status: decided
Originator: XQuery Editors

Description

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.

Proposed Resolution

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)

Actual Resolution

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.

75. xquery-import: Importing Modules

Locus: xquery Cluster: module-semantics Priority: o-1 Status: decided
Originator: XQuery Editors

Description

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?

Actual Resolution

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.

76. xquery-query: What is a Query

Locus: xquery Cluster: module-semantics Priority: o-1 Status: resolved
Originator: Dana

Description

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.

Actual Resolution

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.

77. xquery-namespace-prefix-redefine: Namespace Prefix Redefine

Locus: xquery Cluster: module-semantics Priority: o-1 Status: resolved
Originator: XML Query

Description

Can a namespace prefix be redefined, as in XML?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 3.

Text is in Working Draft 2001-11-28 sec 3.

Actual Resolution

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.

78. xquery-semicolon: Semicolon as Query Module Separator

Locus: xquery Cluster: module-syntax Priority: o-1 Status: resolved
Originator: XML Query

Description

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?

Actual Resolution

Resolved by XQuery WG to eliminate ';' separator

79. xquery-encoding: Encoding

Locus: xquery Cluster: module-syntax Priority: o-1 Status: decided
Originator: Jonathan Robie

Description

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

Actual Resolution

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.

80. xquery-data-function: Accessing Element Data

Locus: xpath Cluster: typed-value/data() Priority: o-1 Status: resolved
Originator: Mary Fernandez

Description

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?

Interactions and Input

Cf. Some functions taking node sequences and implicitly map?

Actual Resolution

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.

81. xpath-issue-complex-type-value: What should the typed value of a complex type be?

Issue Class: T Locus: datamodel Cluster: typed-value/data() Priority: 1 Status: resolved
Originator: jmarsh@microsoft.com

Description

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

Proposed Resolution

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

Actual Resolution

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.

82. xpath-issue-is-isnot-semantics: What should the semantics be for == and !== in regards to nodesets and sequences?

Locus: xfo Cluster: node-equality Priority: o-2 Status: resolved
Originator: Editor

Description

What should the semantics be for == and !== in regards to nodesets and sequences?

Actual Resolution

This is a Functions & Operators document issue.

83. xpath-issue-sequence-nodeset-comparisons-in-fo: Sequence comparisons need to be defined in the F&O spec.

Locus: xfo Cluster: sequences Priority: o-1 Status: subsumed
Originator: Editor

Description

It seems like Sequence comparisons should be defined in the Functions & Operators document.

Actual Resolution

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.

84. xquery-comparing-collections: Comparing Collections

Locus: xquery Cluster: sequences Priority: o-1 Status: subsumed
Originator: XML Query

Description

How are collections compared? Note that we need to be able to compare unordered collections as well as ordered collections.

Actual Resolution

Subsumed by: #xpath-issue-is-isnot-semantics.

85. xquery-equality-identity: Identity-based equality operator

Locus: xfo Cluster: node-equality Priority: o-1 Status: resolved
Originator: Algebra Editors

Description

Do we need an identity-based equality operator? Please justify your answer with sample queries. Note that XPath gets along without it.

Interactions and Input

Cf. Should we use is and isnot instead of == and !==.

Proposed Resolution

The '==' operator is already defined in the F&O document and used in XQuery use cases.

Actual Resolution

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.

86. xquery-set-operators-on-values: Set operations based on value

Locus: xpath Cluster: node-equality Priority: o-2 Status: resolved
Originator: XQuery Editors

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.4.

Proposed Resolution

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

Actual Resolution

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.

87. xpath-issue-simple-value-identity: What is the identity of a simple value?

Locus: xfo Cluster: value-identity Priority: o-2 Status: resolved
Originator: Editor

Description

What should the identity of a simple value be? The value or a unique id?

Actual Resolution

Simple values have no identity.

88. xquery-xpath-existential: 8. Implied existential quantifiers:

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

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.

89. null-comparing-sequences: Comparing Sequences

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: subsumed
Originator: XQuery

Description

What should happen when one or more of the operands of a comparison operator is a sequence of length greater than one?

Actual Resolution

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.

90. xpath-issue-node-set-comparisons: Node-set comparisons

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by: #xquery-xpath-existential.

91. xquery-xpath-string-compare: 9. String comparisons:

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Proposed Resolution

Addressed by XPath 2.0 basic and standard-fallback conversions.

Actual Resolution

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.

92. xquery-deep-equality: Deep equality

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: resolved
Originator: Jonathan

Description

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?

Actual Resolution

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.

93. xquery-xpath-elem-equality: 4. Element-equality:

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by: #xquery-deep-equality.

94. xpath-issue-nodeset-equality: Node equality

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by: #xquery-deep-equality.

95. xpath-issue-backwards-compat-equals: Equality will not be compatible with some string conversions

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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

Actual Resolution

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.

96. xquery-normalized-equality: Normalized Equality

Locus: xpath Cluster: (in)equality-operators Priority: o-1 Status: decided
Originator: Mary Fernandez

Description

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?

Actual Resolution

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.

97. xpath-issue-error-object: How should the error object be supported?

Locus: xpath Cluster: error Priority: o-2 Status: resolved
Originator: Editor

Description

How should the error object be supported? How does the error object relate to exceptions?

Actual Resolution

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.

98. xquery-general-errors: General discussion of errors

Locus: xpath Cluster: error Priority: o-2 Status: resolved
Originator: XML Query WG

Description

This document does not have a general discussion of errors, when they are raised, and how they are processed. This is needed.

Actual Resolution

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.

99. xquery-try-catch-error: TRY/CATCH and error()

Locus: xquery Cluster: error Priority: o-1 Status: resolved
Assigned to: Dana Originator: XQuery Editors

Description

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.

Proposed Resolution

Dana Florescu has been assigned the task of writing a proposal for this.

Actual Resolution

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.

100. xpath-issue-empty-nodeset-vs-empty-sequence: Should an empty sequence and an empty node-set be distinguishable?

Locus: datamodel Cluster: datamodel Priority: o-1 Status: resolved
Originator: Editor

Description

Are an empty sequence and an empty node-set distinguishable?

Proposed Resolution

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.

Actual Resolution

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.

101. xpath-issue-nodes-in-sequences: Should sequences be allowed to have nodes?

Locus: datamodel Cluster: datamodel Priority: o-1 Status: resolved
Originator: jmarsh@microsoft.com

Description

Should sequences be allowed to have nodes? I think you need them to support sequences of nodes constructed by for loops.

Actual Resolution

Status quo: sequences may contain nodes and/or simple values.

102. null-issue-functions-on-empty: Functions on Empty Sequences

Locus: xpath Cluster: function-app Priority: o-1 Status: resolved
Originator: XQuery

Description

XQuery-Null-Issue-7: Question: What should happen if a function expecting one element is invoked on an empty sequence?

Actual Resolution

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.

103. null-functions-on-sequences-a: Functions on Sequences

Locus: xpath Cluster: function-app Priority: o-1 Status: resolved
Originator: XQuery

Description

What should happen if a function expecting one element is invoked on a sequence of more than one element?

Actual Resolution

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.

104. xquery-sequence-for-single: Sequences for single parameters

Locus: xquery Cluster: function-app Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

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?

Actual Resolution

Subsumed by: #nulls-functions-on-sequences.

105. xquery-implicit-current-node: Implicit current node for functions?

Locus: xpath Cluster: function-app Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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?

Actual Resolution

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.

106. xpath-issue-default-context-node: Problem with default context node for functions?

Locus: xpath Cluster: function-app Priority: o-2 Status: subsumed
Originator: Editor

Description

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?

Actual Resolution

Subsumed by: #xquery-implicit-current-node.

107. null-functions-on-sequences-b: Path iteration

Locus: xpath Cluster: function-app Priority: o-1 Status: resolved
Originator: XQuery

Description

How should the current node be passed to a function in a path-step?

Actual Resolution

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.

108. null-aggregates-on-empty: Aggregate functions on empty sequences.

Locus: xpath Cluster: function-app Priority: o-1 Status: resolved
Originator: XQuery

Description

What should the the result of various aggregate functions when applied to the empty sequence?

Interactions and Input

Input from :

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.

Proposed Resolution

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.

Actual Resolution

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.

109. xpath-issue-lexical-disambiguating-text: Need text to disambiguate Lexical Structure?

Locus: xpath Cluster: syntax Priority: o-3 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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.

Actual Resolution

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.

110. xpath-issue-is-isnot-syntax: Should we use is and isnot instead of == and !==.

Locus: xpath Cluster: syntax Priority: o-4 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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.

Actual Resolution

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.

Actual Resolution

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.

111. xpath-issue-sequence-concat-char: What is the best sequence concatenation operator?

Locus: xpath Cluster: syntax Priority: o-3 Status: resolved
Originator: Editor

Description

I think this issue should be closed. The (x,y) form seems to do fine after all.

Actual Resolution

Use ',' as in XQuery.

112. xquery-leading-minus: Leading Minus

Locus: xpath Cluster: syntax Priority: o-1 Status: resolved
Originator: XML Query

Description

Should leading minus/plus be treated as unary operators or as part of a numeric literal? Or should both be supported?

Actual Resolution

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.

113. xpath-issue-axis-subsetting: What should the mechanism be for axis subsetting?

Locus: xpath Cluster: axes Priority: o-1 Status: resolved
Originator: jmarsh@microsoft.com

Description

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

Proposed resolution: Axis subsetting should be done at the grammar level, similar to how XSLT pattern matching is specified.

Actual Resolution

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.

114. xquery-xpath-axes: XPath Axes

Locus: xquery Cluster: axes Priority: o-1 Status: decided
Originator: XQuery Editors

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.3.

Actual Resolution

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

115. xquery-step-expressions: General Expressions in Path Steps

Locus: xpath Cluster: path-semantics Priority: o-1 Status: resolved
Originator:

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.3.

Actual Resolution

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.

116. xquery-full-expression-syntax: Full Expression Syntax in Steps

Locus: algebra Cluster: path-semantics Priority: o-1 Status: subsumed
Originator: XML Query

Description

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.

Actual Resolution

Subsumed by: #xquery-step-expressions.

117. xpath-issue-disallow-variables-on-right: Disallow variables on right side of slash?

Locus: xpath Cluster: path-semantics Priority: o-4 Status: resolved
Originator: Editor

Description

While $x[2] and $x[2]/baz are perfectly fine, should we disallow baz/$x[2]?

Actual Resolution

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.

118. xpath-issue-disallow-obvious-sequence-on-left: Disallow obvious non-node sequences on left of slash?

Locus: xpath Cluster: path-semantics Priority: o-4 Status: resolved
Originator: Editor

Description

While 'abc'[2] is OK, what about 'abc'/baz?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.3.

Actual Resolution

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.

119. xpath-issue-nonsense-nodetests: Should nonsense nodetests be disallowed?

Locus: xpath Cluster: path-semantics Priority: o-4 Status: resolved
Originator: jmarsh@microsoft.com

Description

Should nonsensical expressions like attribute::comment() outlawed?

Actual Resolution

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.

120. xquery-xpath-slash: 7. Duplicates and ordering:

Locus: xpath Cluster: path-semantics Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

Status: On 9/19/01 the Query WG agreed that no change to XPath 1.0 is needed in this area.

121. xquery-path-expression-order: Path Expression Order

Locus: xquery Cluster: path-semantics Priority: o-1 Status: subsumed
Originator: Michael Rys

Description

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.

Actual Resolution

Subsumed by: #xquery-xpath-slash.

122. xpath-issue-duplicates-and-ordering: Duplicates and ordering

Locus: xpath Cluster: path-semantics Priority: o-1 Status: subsumed
Originator: XQuery

Description

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.

Actual Resolution

Subsumed by: #xquery-xpath-slash.

123. null-serialization: Linearization/Serialization

Locus: xquery Cluster: serialization Priority: o-1 Status: resolved
Originator: XQuery

Description

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

Actual Resolution

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.

124. xquery-external-functions: External Functions

Locus: xquery Cluster: functions Priority: o-1 Status: decided
Originator: XQuery Editors

Description

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.

Actual Resolution

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.

125. xpath-issue-xpath-abstract: Should we say something about the abstractness of XPath?

Locus: xpath Cluster: editorial Priority: o-4 Status: resolved
Originator: Editor

Description

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.

Interactions and Input

Input from Paul Cotton:

Input from Michael Rys:

Proposed Resolution

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.

Proposed Resolution

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.

Proposed Resolution

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.

Actual Resolution

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.

126. xpath-issue-re-explain-paths: Should we re-explain path expressions?

Locus: xpath Cluster: editorial Priority: o-4 Status: resolved
Originator: mhkay@iclway.co.uk

Description

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.

Actual Resolution

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.

127. xquery-definition-of-operators: Definitions of Operators

Locus: xpath Cluster: operators Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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.

Actual Resolution

This is the charter of the XPath and F&O task force.

128. xquery-operators-and-functions: Operators and functions

Locus: xfo Cluster: operators Priority: o-1 Status: resolved
Originator: XQuery Editorial Team

Description

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.

Actual Resolution

This is the charter of the XPath and F&O task force.

129. xquery-alignment-of-syntax: Alignment of Syntax

Locus: xquery Cluster: algebra Priority: o-2 Status: resolved
Originator: Algebra Editors

Description

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.

Actual Resolution

The XQuery algebra is a proper subset of XQuery, in particular, the XQuery Core.

130. algebra-mapping: Algebra Mapping

Locus: algebra Cluster: xquery-alignment Priority: o-1 Status: resolved
Assigned to: Jerome Originator: XQuery Editors

Description

The algebra mapping is incomplete and out of date.

Proposed Resolution

Jerome has created a new version of the mapping, with help from Mary, Dana and Mugur.

Actual Resolution

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

131. xquery-align-precedence: Alignment of Precedence

Locus: algebra Cluster: xquery-alignment Priority: o-1 Status: resolved
Originator: Jerome Simeon

Description

The precedence rules of XQuery and the algebra are not completely aligned. This needs to be fixed by the time both specifications are finished.

Actual Resolution

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.

132. xquery-attribute-name-content: Attribute Name, Attribute Content

Locus: xfo Cluster: attribute accessors Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

We need functions to return the name of an attribute and the content of an attribute.

Proposed Resolution

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.

Actual Resolution

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.

133. xquery-reference-constructor: Reference Constructor

Locus: xquery Cluster: (de)reference-expr Priority: o-1 Status: resolved
Originator: Jonathan

Description

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?

Actual Resolution

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

134. xquery-dereference-links: Dereference Operator and Links

Locus: xquery Cluster: (de)reference-expr Priority: o-1 Status: resolved
Originator: Jonathan Robie

Description

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?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.3.

Actual Resolution

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.

Actual Resolution

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.

Actual Resolution

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.

135. xquery-empty-end-tag: Empty End Tags in Element Constructors

Locus: algebra Cluster: constructor-syntax Priority: o-1 Status: resolved
Originator: Michael Rys

Description

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?

Actual Resolution

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.

136. xquery-list-element-constructor: Lists of Element Constructors

Locus: xquery Cluster: constructor-syntax Priority: o-2 Status: resolved
Originator: Michael Rys

Description

If a list of expressions contains adjacent element constructors, should a comma appear between these element constructors?

Actual Resolution

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.

137. xquery-attribute-constructor-function: Attribute Constructor Function

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

We need a function for constructing attributes.

Proposed Resolution

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.

Actual Resolution

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.

138. xquery-quote-computed-attribute-value: Quotes for computed attribute values

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: resolved
Originator: James Clark

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.8.

Actual Resolution

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.

139. xquery-computed-element-names: Computed element and attribute names

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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?

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.8.

Actual Resolution

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.

140. xquery-element-construction: Alternative syntax for element construction

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: subsumed
Originator: Algebra Editors

Description

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

Proposed Resolution

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.

141. xquery-comment-pi-productions: Productions for Comments and Processing Instructions

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

The current EBNF lacks productions for comments and processing instructions.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.8.

Actual Resolution

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.

142. xquery-comment-to-end-of-line: Comments to end-of-line

Locus: xquery Cluster: constructor-syntax Priority: o-1 Status: subsumed
Originator: Michael Rys

Description

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

Actual Resolution

Subsumed by: #xquery-comment-pi-productions.

143. xquery-literal-xml-constructor: XML Constructor

Locus: algebra Cluster: constructor-syntax Priority: o-1 Status: postponed
Originator: Jonathan Robie

Description

Is there a need for a constructor that creates an instance of the XML Query Data Model from a string that contains XML text?

Proposed Resolution

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?

Actual Resolution

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.

144. xquery-escaping-quotes-and-apostrophes: Escaping Quotes and Apostrophes

Locus: xquery Cluster: syntax Priority: o-1 Status: decided
Originator: XML Query

Description

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?

Interactions and Input

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.

Proposed Resolution

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.

Actual Resolution

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.

145. xquery-copy-reference: Copy and Reference Semantics

Locus: xquery Cluster: constructor-expr Priority: o-1 Status: subsumed
Originator: XQuery Editors

Description

Copy and reference semantics must be defined properly for updates to work. This must be coordinated with the algebra team.

Actual Resolution

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

146. xquery-document-construction:

Locus: xquery Cluster: constructor-expr Priority: o-1 Status: resolved
Originator: Jonathan

Description

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?

Proposed Resolution

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?

Actual Resolution

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.

147. null-empty-attributes: Empty Attributes

Locus: xquery Cluster: constructor-expr Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Actual Resolution

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.

148. xquery-namespace-attribute-declaration: Namespace Attributes in Element Constructors

Locus: xquery Cluster: constructor-expr Priority: o-1 Status: resolved
Assigned to: xquery Originator: XML Query

Description

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>

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.8.

Actual Resolution

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.

149. xquery-embedding-xml: Embedding XML in XQuery

Locus: xquery Cluster: literal-XML Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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?

Actual Resolution

Current XQuery syntax supports literal XML constructors

150. xquery-embedding-xquery-in-xml: Embedding XQuery in XML

Locus: xquery Cluster: literal-XML Priority: o-1 Status: subsumed
Originator: Steve Tolkin

Description

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.

Actual Resolution

Subsumed by: #xquery-embedding-xml.

151. xquery-cut-and-paste-xml: Cutting and pasting XML into XQuery

Locus: xquery Cluster: literal-XML Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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?

Actual Resolution

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.

152. xquery-abql: XML-based Syntax

Locus: xqueryx Cluster: xqueryx Priority: o-1 Status: decided
Originator: XML Query WG

Description

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.

Actual Resolution

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.

153. xquery-escape-to-abql: Escape between syntaxes

Locus: xquery Cluster: xqueryx Priority: o-1 Status: postponed
Originator: Jerome Simeon

Description

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.

Actual Resolution

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.

154. null-order-on-empty: Ordering of empty values.

Locus: xquery Cluster: sort Priority: o-1 Status: resolved
Originator: XQuery

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.10.

Actual Resolution

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.

155. xquery-phantom-sortby: Sorting by Non-exposed Data

Locus: xquery Cluster: sort Priority: o-1 Status: decided
Originator: Michael Rys

Description

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?

Interactions and Input

Cf. Add 'order by' clause to FLWR?

Proposed Resolution

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

Actual Resolution

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/

156. xquery-before-after: Meaning of BEFORE and AFTER

Locus: xpath Cluster: BEFORE/AFTER-expr Priority: o-1 Status: resolved
Originator: Jonathan

Description

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

Actual Resolution

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.

157. xquery-function-library: Function Libraries

Locus: xquery Cluster: functions Priority: o-1 Status: decided
Originator: XQuery Editors

Description

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.

Actual Resolution

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.

158. xquery-unqualified-function-names: Unqualified Function Names

Locus: xquery Cluster: functions Priority: o-1 Status: resolved
Originator: XML Query

Description

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 3.

Actual Resolution

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.

159. xquery-recursion: Recursion

Locus: algebra Cluster: functions Priority: o-1 Status: resolved
Originator: XQuery Editors

Description

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]

Actual Resolution

Status quo: XQuery currently supports general recursion.

160. xquery-naive-implementation: Naive Implementation Strategy

Locus: xquery Cluster: execution-model Priority: o-2 Status: resolved
Originator: Marton Nagy

Description

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.

Actual Resolution

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.

161. xquery-fusion: Fusion

Locus: xquery Cluster: fusion Priority: o-1 Status: abandoned
Originator: Michael Rys

Description

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.

Proposed Resolution

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.

Proposed Resolution

Withdrawn 2001-12-07.

162. xquery-filter-function: Filter as a Function

Locus: algebra Cluster: filter Priority: o-1 Status: resolved
Originator: Dana

Description

Dana has observed that Filter can be a function rather than an operator, if nodes have identity.

Actual Resolution

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.

163. xquery-filter-typing: Typing of Filter

Locus: algebra Cluster: filter Priority: o-1 Status: resolved
Assigned to: Jerome Simeon Originator: Jerome Simeon

Description

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?

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Filter no longer exists.

164. xquery-updates: Updates

Locus: xquery Cluster: updates Priority: o-1 Status: resolved
Assigned to: Jonathan Originator: XQuery Editors

Description

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.

Actual Resolution

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.

165. xquery-persist-views-functions: View Definition

Locus: algebra Cluster: views Priority: o-1 Status: resolved
Originator: Mugur

Description

Do we need a way to define views?

Actual Resolution

While a mechanism for view definition is desirable, we do not currently intend to provide one in Level 1.

166. xquery-exclude-undesireables: Excluding Undesired Elements

Locus: xquery Cluster: miscellaneous Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

How do we exclude undesired elements from the results of joins?

Interactions and Input

Input from :

This need came out of a thread exploring data integration scenarios, starting with http://lists.w3.org/Archives/Member/w3c-archive/2000Dec/0132.html.

Actual Resolution

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

167. xquery-eval: Eval

Locus: algebra Cluster: miscellaneous Priority: o-1 Status: resolved
Originator: Jonathan Robie

Description

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

Actual Resolution

No in Version 1.0

168. xquery-groupby: GROUPBY

Locus: xquery Cluster: groupby Priority: o-1 Status: resolved
Originator: XML Query

Description

Does XQuery need an explicit GROUPBY expression? This would not add expressive power, but would be convenient, and may be easier to optimize.

Actual Resolution

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.

169. xquery-conformance: Missing conformance section

Locus: xquery Cluster: conformance Priority: o-1 Status: resolved
Originator: Jonathan

Description

The final XQuery recommendation must have a conformance section. The XML Query Working Group has not yet decided what should go into this section.

Actual Resolution

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.

170. xquery-collections: Document collections

Issue Class: D Locus: xquery Cluster: documents Priority: 1 Status: resolved
Originator: XQuery WG

Description

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?

Actual Resolution

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

171. operands-of-slash: Operands of "/"

Locus: xpath Cluster: path-semantics Priority: o-1 Status: resolved
Originator: XPath TF

Description

Should the operands be restricted?

Suggestions floated:

  1. only defined on singleton node or empty sequence
  2. defined on any node sequence

Proposed Resolution

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.

Proposed Resolution

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.

Proposed Resolution

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.

Actual Resolution

Text to that effect is in Working Draft 2001-11-28 sec 2.3.

172. functions-with-implicit-mapping: Some functions taking node sequences and implicitly map?

Issue Class: T Locus: xpath Cluster: typed-value/data() Priority: 2 Status: resolved
Originator: XPath TF

Description

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)

Interactions and Input

Cf. Accessing Element Data

Actual Resolution

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.

173. polymorphic-operators-fallback: Polymorphic operator; only one fallback?

Locus: xpath Cluster: type exception Priority: o-1 Status: resolved
Originator: XPath TF f2f

Description

If we have polymorphism in the operator, should we have only one fallback?

Proposed Resolution

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.

Proposed Resolution

Text is in Working Draft 2001-11-28 sec 2.5.

Actual Resolution

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.

174. fallback-if-untyped-marker: Support for UnknownSimpleType

Issue Class: T Locus: xpath Cluster: type exception Priority: 1 Status: resolved
Originator: XPath TF f2f

Description

Do we still need fallbacks if we have a marker for untyped data (="PCDATA")?

Interactions and Input

Input from Mary F. Fernandez:

Cf. Always explicit cast?

Proposed Resolution

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.

Proposed Resolution

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

Actual Resolution

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.

175. xpath-name-of-not3: What should "not3()" be called?

Locus: xpath Cluster: 3-value-logic Priority: o-2 Status: subsumed
Originator: XQuery WG

Description

The XML Query WG participants would like the XPath task force to propose a final name for the "not3" function.

Interactions and Input

Cf. Do we need and3(), or3(), not3() built in?

Actual Resolution

Subsumed by :xpath-issue-not-logic.

176. xpath-node-sequence-definition: What is a node sequence?

Locus: xpath Cluster: choice-context Priority: o-1 Status: resolved
Originator: XPath-TF

Description

A sequence that contains at least one node? A sequence that contains all nodes?

Actual Resolution

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.

177. functions-with-boolean-argument: Consistency of functions that take boolean formal argument

Issue Class: TF Locus: xpath Cluster: choice-context Priority: 2 Status: abandoned
Originator: XPath-TF

Description

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.

Interactions and Input

Cf. Implicit conversion of node-sets to boolean for comparisons.

Actual Resolution

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.

178. xpath-predicates-semantics: Semantics of positional predicates in XPath

Locus: xpath Cluster: type-conversions Priority: o-1 Status: resolved
Originator: XPath-TF

Description

What shold the semantics be?

Actual Resolution

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.

179. function-call-rules: Function call rules needed

Locus: xpath Cluster: type-conversion Priority: o-1 Status: resolved
Originator: Don Chamberlin

Description

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

Interactions and Input

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:

Actual Resolution

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.

180. functions-complex-valued-arguments: Functions expecting complex-valued arguments

Locus: xpath Cluster: functions Priority: o-1 Status: resolved
Originator: XPath-TF

Description

Semantics of function application for functions that expect complex-valued arguments is not documented in current WDs.

Actual Resolution

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.

181. integers-primitive-in-literals: Should literals include integers & integer be treated as primitive type?

Locus: xpath Cluster: type-system Priority: o-1 Status: resolved
Originator: Michael Kay

Description

Should literals include integers & integer be treated as primitive type?

Interactions and Input

Input from Mary F. Fernandez:

Input from Kay, Michael:

Actual Resolution

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.

182. operator-mapping: Mapping XPath Operators to F&O Functions

Locus: xpath Cluster: operators Priority: o-1 Status: resolved
Originator: XPath TF

Description

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.

Proposed Resolution

This belongs in the XPath document. Ashok will send a draft to Don, who will incorporate this in XPath post December 2001 publication.

Proposed Resolution

See http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jan/0186.html.

Actual Resolution

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.

183. text-nodes-lexical-typed: Text nodes - lexical structure and typed form

Issue Class: T Locus: xpath Cluster: text-nodes Priority: 1 Status: resolved
Originator: XPath TF

Description

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.

Actual Resolution

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.

184. kind-tests: Need ability to test for Comments, PIs

Issue Class: T Locus: xpath Cluster: node-types Priority: 3 Status: resolved
Assigned to: xquery Originator: F&O TF

Description

Need to extend languages to test for instance-of comments, pis, etc.

Actual Resolution

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.

185. always-explicit-cast: Always explicit cast?

Locus: xpath Cluster: type exception Priority: o-2 Status: resolved
Originator: Phil Wadler

Description

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

Interactions and Input

Cf. Support for UnknownSimpleType

Actual Resolution

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.

186. order-union-intersect-except: Ordering of result of union, intersect, and except operators

Locus: xpath Cluster: node order Priority: o-1 Status: resolved
Originator: XPath Editors

Description

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.

Proposed Resolution

Union, intersect, and except on node sequences are defined to return their results in document order.

Actual Resolution

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.

187. date-time-operators: Operations supported on date/time types

Locus: xfo Cluster: operators Priority: o-1 Status: subsumed
Originator: XPath Editors

Description

What arithmetic operations should be supported on date/time types?

Issue is for material in sec 2.5. in Working Draft 2001-11-28.

Actual Resolution

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

188. syntax-comparison-operators: Comparison operators - concrete syntax

Locus: xpath Cluster: operators Priority: o-1 Status: resolved
Originator: XPath Editors

Description

What is the concrete syntax of the comparison operators?

Issue is for material in sec 2.6. in Working Draft 2001-11-28.

Actual Resolution

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.

189. operators-consistent-f_o: Supported combinations of types for comparison operators

Locus: xpath Cluster: operators Priority: o-1 Status: resolved
Originator: XPath Editors

Description

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.

Actual Resolution

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.

190. order-comparisons: Operators for order comparisons

Locus: xpath Cluster: operators Priority: o-1 Status: resolved
Originator: XPath Editors

Description

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.

Actual Resolution

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.

191. whitespace-in-element-constructors: Whitespace handling in element constructors

Locus: xquery Cluster: whitespace Priority: o-1 Status: decided
Originator: XPath Editors

Description

How is whitespace handled in element constructors?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Interactions and Input

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

Actual Resolution

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.

192. type-of-constructed-element: Type of a newly constructed element

Issue Class: T Locus: xquery Cluster: type constructed element Priority: 2 Status: resolved
Originator: XPath Editors

Description

What is the type of a newly constructed element?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Interactions and Input

Cf. Is the QName denoting type information optional or required?

Cf. Should all elements and attributes have type annotations?

Actual Resolution

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.

193. non-valid-xml-construction: Construction of non representable XML

Issue Class: T Locus: xquery Cluster: xml non representable Priority: 2 Status: resolved
Originator: XPath Editors

Description

An element constructor may contain adjacent simple values as the content of the element. This cannot be represented in XML. What should we do about this?

Issue is for material in sec 2.8. in Working Draft 2001-11-28.

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

This issue is solved as part of the adoption of "Alternative 1".

194. sort-stable-unstable: Support for stable and unstable sort?

Locus: xquery Cluster: sort Priority: o-1 Status: resolved
Originator: XPath Editors

Description

Should the language support both stable and unstable sort? Using what syntax?

Issue is for material in sec 2.10. in Working Draft 2001-11-28.

Actual Resolution

Decision by: xquery on 2002-05-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0104.html)

Resolved by the following production in the document: [5] SortExpr ::= Expr "stable"? "sortby" "(" SortSpecList ")"

195. sort-heterogenous-sequence: Semantics of sorting heterogeneous sequences

Locus: xquery Cluster: sort Priority: o-1 Status: resolved
Originator: XPath Editors

Description

Is it possible to sort a heterogeneous sequence? What syntax and semantics are used?

Issue is for material in sec 2.10. in Working Draft 2001-11-28.

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Adoption of status quo.

196. syntaqx-datatype-declarations: Concrete syntax for datatype declarations

Issue Class: T Locus: xpath Cluster: types Priority: 2 Status: resolved
Assigned to: xquery Originator: XPath Editors

Description

What should be the concrete syntax for datatypes in function signatures and expressions? Should this syntax support node-or-value? Processing-instructions? Comments? Note that some functions in the F&O document (such as "exists") require "node-or-value" parameters.

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

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.

197. type-on-attributes: Need "attribute of type"?

Issue Class: T Locus: xpath Cluster: types Priority: 2 Status: resolved
Assigned to: xquery Originator: XPath Editors

Description

The current Datatype production supports declarations of the form "element of type <var>". Do we also need declarations of the form "attribute of type <var>" or "node of type <var>"?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

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.

198. named-typing-support: Syntax for named typing

Issue Class: T Locus: xpath Cluster: types Priority: 3 Status: resolved
Assigned to: xquery Originator: XPath Editors

Description

Does the Datatype declaration need a way to specify both the QName of an element or attribute and its type, eg element person of type plumber?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

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.

199. support-locally-declared-types: Support for locally declared types?

Issue Class: T Locus: xpath Cluster: types Priority: 2 Status: resolved
Assigned to: xquery Originator: XPath Editors

Description

Should XQuery support the import of locally declared types from schemas?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

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.

200. semantics-of-only: Semantics of "only"

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: postponed
Assigned to: xquery Originator: XPath Editors

Description

The keyword "only" remains in the syntax of "instance of", but the meaning of this keyword is not clear. Do we need this? If so, what are its semantics?

Issue is for material in sec 2.13. in Working Draft 2001-11-28.

Further input from Phil Wadler: Suggest we remove "only" from the text, and turn it into an issue. (As noted in the text, "only" makes sense only if we have named types, which is another issue.) If we do have "only", it should be used consistently in both "instance of" and in the "case" of a type switch. [!]

Actual Resolution

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.

201. scope-namespace-declaration: Scope of namespace declaration

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: XPath Editors

Description

What is the scope of a namespace declaration in the query prolog?

Issue is for material in sec 3. in Working Draft 2001-11-28.

Actual Resolution

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.

202. namespace-binding: In-scope namespaces and bindings

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: XPath Editors

Description

How do namespace declarations in the prolog and in namespace declaration attributes affect the in-scope namespaces of the context?

Issue is for material in sec 3. in Working Draft 2001-11-28.

Actual Resolution

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)

[Decided modulo suggested changes to text by Mike K] Action Item on Jonathan to incorporate these changes.

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.

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

203. non-declared-namespace-prefix: Non declared namespace prefix

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: XPath Editors

Description

Is it legal to use names that lexically match a QName if the prefix has not been bound in a namespace declaration?

Issue is for material in sec 3. in Working Draft 2001-11-28.

Proposed Resolution

Statement that using a namespace prefix that has not been declared is an error.

Actual Resolution

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.

204. attribute-namespaces: How do default element namespaces affect attributes

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: XPath Editors

Description

What is the name of an unprefixed attribute? Is this affected by default namespaces? Is this affected by the namespace of the containing element?

Issue is for material in sec 3. in Working Draft 2001-11-28.

Actual Resolution

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.

205. default-function-parameter-type: Default function parameter type

Issue Class: TF Locus: xquery Cluster: types Priority: 1 Status: resolved
Originator: XPath Editors

Description

If a function parameter does not specify a type, can both nodes and values be passed as arguments? If a function return does not specify a type, can both nodes and values be returned?

Issue is for material in sec 3. in Working Draft 2001-11-28.

Proposed Resolution

The default type of a function parameter when no type is specified in the function signature is changed from "any node" to "any type". The default return type of a function when no return type is specified is changed from "any sequence of nodes" to "any type".

Actual Resolution

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)

[Decided modulo suggested changes to text ] Action Item on Jonathan to incorporate these changes. "any sequence" or "any type"

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: The default return type is item*, the default parameter type is item*.

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Independent verification.

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

206. xpath-datatype-support: Typing support in XPath

Issue Class: T Locus: xpath Cluster: types Priority: 2 Status: decided
Originator: Mike Kay

Description

Which of these type productions (CAST, TREAT, ASSERT, TYPESWITCH...) belong in XPath? (ie common to XQuery and XPath)

The list is now (2002-10): CAST, TREAT, VALIDATE, INSTANCE OF, types on variable bindings, TYPESWITCH.

Actual Resolution

Decision by: xsl on 2003-04-07 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Apr/0034.html)

Decision by: xquery on 2003-04-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0175.html)

Decided to remove "validate" from XPath. ("typeswitch" was removed already)

207. variable-names: Variable names: QNames or NCnames?

Locus: xpath Cluster: variables Priority: o-1 Status: resolved
Originator: Ashok Malhotra

Description

Should variable names be QNames or NCNames? Note that XPath 1.0 uses QNames, and it may be helpful to disambiguate variable names from different modules.

Actual Resolution

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.

208. multiple-curly-braces: Multiple curly braces allowed?

Locus: xquery Cluster: syntax curly brace Priority: o-1 Status: resolved
Assigned to: xquery Originator: Phil Wadler

Description

Can you have multiple matching curly braces inside an attribute value? How is it evaluated? What is the associated typing? Note that the BNF permits this.

Actual Resolution

Decision by: xsl on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Decision by: xquery on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Can you have multiple matching curly braces inside an attribute value?

Braces for text must be escaped. <e a="{{{{}}"/>

Nesting is no problem:

<e a="{{{{{text{true()}}}}"/>

How is it evaluated?

With a parser.

What is the associated typing?

Not a syntax issue.

209. syntax-attribute-values: Syntax for attribute values - more than one?

Locus: xquery Cluster: syntax attribute values Priority: o-1 Status: resolved
Assigned to: xquery Originator: Phil Wadler

Description

Do we want to continue to support both of the following forms for computed attribute values? If not, is it possible to decide which to remove?

     <pic size={}>
      {
      }
     </pic>
  
     <pic size="{}">
      {
      }
     </pic>
  

Actual Resolution

Decision by: xquery on 2002-01-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Jan/0304.html)

Jonathan: Computed attribute values - two ways to do this.  Propose to
elimiate no quoted representation.
Michael: a = {3} - it is clear that the type is integer...

PaulC:  Is there anyone who thinks the semantics are different.  Michael
is
not sure.

PaulC: Anyone think we should retain non quoted syntax:  no objections,
resolved.
  

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.

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

210. order-sequences: Order of sequences

Locus: xpath Cluster: order sequences Priority: o-1 Status: postponed
Originator: Phil Wadler

Description

2.10, * Points 1 and 2 (Draft 2001-11-28). We could specify that lexical order is used when the ordering expression yields a sequence of values. This could be quite useful, e.g., if we represent Section 1.2.3 by (1,2,3) and Section 1.4 by (1,4), then lexical ordering does the right thing. This also implies that () should sort before everything else, as that is what happens with lexical order.

Actual Resolution

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.

211. treat-choice: Treat and structural vs named typing

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Assigned to: xquery Originator: Phil Wadler

Description

2.13.2 (Draft 2001-11-28) The behaviour of treat is profoundly affected by the choice between structural and named typing. If we use structural typing, then treat changes the type but not the value; if we use named typing, then treat must return a new value containing the appropriate type names. (Similarly for type switch.) The current wording is vague on this point. Should we be less vague and more clear about what the two different choices involve?

Actual Resolution

Addressed by the "Named Typing" proposal in SequenceType production.

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.

212. datatype-production-name: Is "datatype" a suitable production name?

Locus: xpath Cluster: syntax Priority: o-1 Status: resolved
Assigned to: xquery Originator: Phil Wadler

Description

Is Datatype the right name for production [54] (Draft 2001-11-28)? It may be confused with XML Schema Type 2.

Actual Resolution

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.

213. syntax-special-characters: How to get quotes etc in string literals?

Locus: xpath Cluster: syntax quotes Priority: o-1 Status: resolved
Originator: Andrew Eisenberg

Description

How do you get strings such as single and double quote to be allowed in character strings?

      <name>Ben &amp; Jerry&apos;s</name>
  

eg should doubling a quote escape it?

It would seem that we need to allow these CharRef's in string literals as well.

Interactions and Input

Cf. Strings in attributes

Input from Andrew Eisenberg:

XPath TF Meeting #91 suggested closing issue 213.

Issue 213 has the title "syntax-special-characters: How to get quotes etc
in string literals?" Perhaps we have focused on the quotes, and not the
"etc."

I might want to construct an element as follows (where ™ represents
the trademark symbol "?"):

   <company name='Ben & Jerry's ™'> ... </company>


To write this as a ComputedElementConstructor, I would have to write to
following:

   element company
   {
      attribute name { 'Ben & Jerry''s ', xf:codepoints-to-string(8482) }
      ...
   }

To pass this string as an argument to a function I'd have to write the
following:

   f (xf:concat ('Ben & Jerry''s ', xf:codepoints-to-string(8482)))


It's rather jarring to allow CharRef in ElementContent and
AttributeValueContent, but not in string literals. I suggest that we add
CharRef to the content of a string literal.

                                          -- Andrew

Input from Andrew Eisenberg:

I suggested in [1] that issue 213 should not be closed until StringLiteral
supported CharRef. The discussion that followed showed me that this was not
as simple as I had thought it to be. XPath that is used within an XSLT
stylesheet already has CharRef's processed by an XML parser. Having XPath
process them a second time (which would happen if the XPath included "
&amp;") would be both backwards incompatible and painful for users.

Michael Kay brought a great deal of clarity to the discussion in [2],
suggesting:

> For XPath, the right solution is doubling for string quotes, and
> host-language escaping rules for anything else.
>
> For XQuery, the two questions are
>
> (a) in what syntactic contexts should the XML built-in entities (e.g.
&lt;)
> be allowed?
> This can't be everywhere; the whole point of these is to distinguish "<"
as
> markup from "<" as data. Possible solutions are:
>    a1: everywhere that XML would allow them
>    a2: only in places that XQuery considers to be "character data", ie.
> outside the curly braces in attribute content and element content, and in
> string literals
>
> (b) how and where numeric Unicode escapes should be allowed. Possible
> solutions are
>    b1: use XML-style numeric character references as in a1 above
>    b2: use XML-style numeric character references as in a2 above
>    b3: allow XML-style numeric character reference anywhere
>    b4: allow a different form of numeric character reference anywhere
>    b5: don't allow numeric character references anywhere; leave it to the
> host environment
>
> The simplest solution is probably a2+b2, which is the status quo with the
> addition of allowing CharRef in an XQuery (but not XPath) string literal.

I agree with the a2+b2 solution that he proposes.

This would leave the definition of String Literal as it is for XPath:

   [4]  StringLiteral ::=
           ('"' (('"' '"') |  [^"])* '"')
           |  ("'" (("'" "'") |  [^'])* "'")

For XQuery (section 3.1.1, Literals), the definition would be changed to
allow CharRef and PredefinedEntityRef:

   [4]  StringLiteral ::=
           ('"' (('"' '"') | CharRef | PredefinedEntityRef | [^"])* '"')
           |  ("'" (("'" "'") | CharRef | PredefinedEntityRef | [^'])* "'")

   [5]  URLLiteral ::=
           ('"' (('"' '"') | CharRef | PredefinedEntityRef | [^"])* '"')
           |  ("'" (("'" "'") | CharRef | PredefinedEntityRef | [^'])* "'")

The editors may wish to add the following example:

      "&#8364;50 " denotes the string containing the characters 'Ç', '5',
      and '0'.

This would allow an element with attribute value "Ben & Jerry's?" to be
created as follows:

   <company name='Ben &amp; Jerry&apos;s &#8482;'> ... </company>

Expressed as computed constructor, this element could be written as:

   element company
      {
         attribute name {'Ben &amp; Jerry&apos;s &#8482;'}
      }

In XSLT, a user could write the following:

   <company name="{'Ben &amp; Jerry''s &#8482;'}"/>

The use of "&apos;" would have caused an error, because XML processing
would have left XPath to interpret 'Ben & Jerry's?'.

Michael Rys suggested in [3] that:

> I think there is a b6:
> B1+allow a different form of numeric character reference (\unnnnnn) in
> XQuery string literals.

This could not be done for XPath without introducing a backward
incompatibility. This could be done for XQuery only, but it would introduce
a syntax different from what we have for element constructor and computed
element constructor. The example above would now be written as:

   element company
      {
         attribute name {'Ben \u000026 Jerry\u000027s \u008482'}
      }

Michael's suggestion would, admittedly, simplify the process of embedding
an XQuery within an XML document.

                                          -- Andrew

[1] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0400.html
[2] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0454.html
[3] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0456.html

--------------------
Andrew Eisenberg
IBM
5 Technology Park Drive
Westford, MA  01886

andrew.eisenberg@us.ibm.com
Phone: 978-399-5158    Fax: 978-399-5117

Actual Resolution

Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)

Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)

The XPath TF believes that it is fixed as far as XPath is concerned. Doubled quotes are allowed. CharRef is a query-specific problem, and is subsumed by other issues.

Decision by: xquery on 2002-11-27 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0007.html) Issue will be closed with no change to Xpath and Xquery will adopt solutions A2 and B2.

214. strings-in-attributes: Strings in attributes

Locus: xquery Cluster: syntax strings in attributes Priority: o-1 Status: resolved
Assigned to: xquery Originator: Andrew Eisenberg

Description

Behavior of strings between quotes in attributes is different from that in string literals - should they be unified?

Interactions and Input

Cf. How to get quotes etc in string literals?

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decided: no. "{" and "}" are good examples of characters that should be treated differently. We've discussed this extensively, with no enthusiasm for unification.

215. quantified-expressions-2-or-3-valued: Should we have a 3-valued form of quantifiers?

Locus: xpath Cluster: 3-value-logic Priority: o-1 Status: postponed
Originator: Andrew Eisenberg

Description

Should we have a 3-valued form of quantifiers?

QuantifiedExpr is defined as being two-valued, while SQL's is 3-valued. SQL would evaluate 5 >ALL (6, null, 7) as UNKNOWN. XQuery would return FALSE where SQL returns UNKNOWN.

Actual Resolution

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.

216. focus-description: Description of focus is very procedural

Locus: xpath Cluster: focus Priority: o-1 Status: abandoned
Originator: Michael Rys

Description

The description of the focus is very procedural. Given that we define a declarative language this worries me quite a bit. Can this be written in a more declarative manner?

Actual Resolution

Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)

Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

217. focus-context-document: Context document in focus

Locus: xpath Cluster: focus Priority: o-1 Status: resolved
Originator: Michael Rys

Description

The current definition of context documents may be difficult to implement in an efficient manner. Should this definition be simplified? Is this definition needed at all?

Actual Resolution

Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)

Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

The definition of context document has been removed.

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.

218. wildcards-for-what: What wildcards; namespaceprefix?

Locus: xpath Cluster: wildcards Priority: o-1 Status: resolved
Assigned to: xquery Originator: Michael Rys

Description

Do we need wildcards for only elements and attributes whose namespace URI is null? Are there other wildcards that should be supported?

Actual Resolution

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)

We don't think any requirement has been demonstrated for such functionality. It can all be achieved reasonably easily with predicates, for example

  select="*[namespace-uri(.)='']

We also don't think that at this stage we should be leaving open issues that merely conjecture a possible requirement. We finished the requirements stage a long time ago. If someone has a specific use case that is currently problematic, they can bring it forward. In the absence of a specific proposal, this issue is closed with no change to the document.

219. namespaces-context: Context: namespaces

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: Michael Rys

Description

XQuery must specify how namespaces are handled in the context.

Note that:

1. An unprefixed element name used as a nametest in a query has the namespaceURI associated with the default element namespace from the context.

Note: we may decide that this is the same as the default namespace of the in-scope namespaces, but this is not certain.

2. An unprefixed attribute has a null namespaceURI

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Unprefixed element names are considered to be in the default element namespace. Unprefixed attribute names are considered to be in no namespace. These rules are documented in XQuery Section 4.1. It is noted that attribute names may occur in the following places, and are handled uniformly: (1) Name test in path expression on attribute axis, (2) Attribute constructor; (3)Attribute within an element constructor.

220. document-order-explict-sort: Should there be a way to explicitly sort in document order?

Locus: xpath Cluster: sort Priority: o-1 Status: subsumed
Originator: Michael Rys

Description

Should there be a way to explicitly sort in document order?

Actual Resolution

Subsumed by F&O issue 66.

221. namespace-prefixed-where-apply: Where should namespace prefixes apply?

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: Michael Rys

Description

Should namespace prefixes apply equally to nametests, element and attribute construction, variables, and functions? Consider the following example:

  <foo xmlns:bar="http://www.foo.com">
    {
          bar:sort(1,2,3)
    }
  </foo>
  

Is bar:sort() in the namespace defined by the xmlns attribute?

Actual Resolution

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.

222. namespace-redefinition: Allow redefinition of namespace prefixes?

Locus: xquery Cluster: namespaces Priority: o-1 Status: resolved
Originator: Michael Rys

Description

Should we allow redefinition of namespace prefixes using NAMESPACE declarations in order to allow query system defaults that can be overridden by user? What are the interoperability issues of this?

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decided to accept status quo: Namespace declaration attributes may redefine a namespace prefix within a given scope.

223. external-function-definition: We need a way to declare external functions

Locus: xquery Cluster: functions external Priority: o-1 Status: decided
Originator: Michael Rys

Description

Should we allow external functions to be defined using a syntax like this?

       [71a] ExternalFnDef ::= {"define" S "external" S "function"}
            QName "(" ParamList? ")" ("returns" Datatype)?
  

Interactions and Input

Cf. XQuery Extension Mechanisms

Actual Resolution

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.

224. function-return-datatype: Why do we want to allow optional returns and DataType?

Issue Class: T Locus: xquery Cluster: types Priority: 2 Status: decided
Originator: Michael Rys

Description

Would we prefer a syntax that requires explicit declaration of a general type when a function is to be loosely typed, rather than use the current syntax in which the type is omitted when the function is untyped.

Actual Resolution

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

Decided that the default is item*.

225. variable-definition-error: Variable redefinition allowed?

Locus: xpath Cluster: variables Priority: o-1 Status: resolved
Originator: Mike Kay

Description

The binding of a variable in an expression always overrides any in-scope binding of a variable with the same name". In XSLT, it is an error to declare a (local) variable if another local variable with the same name is already in scope. This rule has proved useful in catching many user errors, particularly where users misunderstand the nature of XPath variables and think that a second declaration behaves like an assignment statement. I would prefer it to be an error to declare a variable if a variable of that name is already in scope. Also, the scope of variables has not been defined with very great precision, it's not explicitly clear what

for $i ........return for $i in // X, $j in $i/z return ....

means: which $i does this refer to?

Interactions and Input

Cf. Shadowing of Variables

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html) It has since been found that the XQuery minutes are in error and that the resolution was NOT approved.

Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html) Finding that the XQuery minutes were in error the XSL WG decided in the 2002-10-16 meeting to withdraw approval of the resolution to issue 225.

Decided to accept status quo - permitting this.

Decision by: xsl on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Decision by: xquery on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Decision to accept status quo; permit redefinition.

226. testing-existential-expressions: Existential Expressions

Locus: xpath Cluster: existential expressions Priority: o-1 Status: resolved
Originator: Mike Kay

Description

Do we want to require implementations to test all pairs in order to determine if there is an incomparable value? Note that there are three choices: return true if any pair that satisfies the condition is encountered, return error on incomparable, or permit implementations to define what to do if both a true comparison and an incomparable pair are encountered. Should static and dynamic semantics handle this differently?

Actual Resolution

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)

Decision by: xsl on 2002-10-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Oct/0121.html)

Decided to accept status quo - allowing short-circuiting.

227. syntax-dereference: Syntax for dereference?

Locus: xpath Cluster: syntax dereference Priority: o-2 Status: resolved
Originator: Don Chambrelin

Description

What syntax should be used for dereference? In addition to the => syntax described in the document, here are two alternative approaches: (a) Treat dereferencing as an axis; (b) Simply use id(.) in a general step, with no special syntax.

Actual Resolution

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, with no change to the specification.

We no longer have a "=>" operator, and we do not have a semantic function that is in need of new syntax. We decided not to include this in XPath 2.0 or XQuery 1.0.

The ability to use id(.) in a step is there, it needs no changes to the document.

228. default-namespace-functions: Should we keep the default function namespace, and the xf: namespace?

Locus: xpath Cluster: namespace functions Priority: o-2 Status: decided
Originator: Scott Boag

Description

The question was raised of whether the Query WG and F&O TF have 1) a good rationale for putting built-in functions in a namespace, and 2) a consistent story about how this will relate to default namespace declarations and user-defined functions.

It would seem odd to have to have all user defined functions put in the FandO namespace if a namespace is not declared for it. If you do not do that, then user defined functions that don't require a prefix will not match the QName.

And, if there is not a good rational that provides user benifits, then it seems like we are going through a lot of additional complexity for little or no benefit.

Interactions and Input

Cf. Do functions in the null namespace clash with functions in the default namespace?

Input from Kristoffer Rose:

Actual Resolution

Decision by: xquery on 2003-01-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0435.html)Unqualified, user-defined functions are placed in the default namespace for the scope of the query *only*.

Decision by: xsl on 2003-01-16 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jan/0046.html)

This issue is identical to XSLT issue 155. Decision:

- no controls on default function namespace

- XSLT functions are in F&O namespace

- User defined function must be in a namespace

Decision by: xpath-tf on 2003-05-14 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0037.html)

1. Propose to require (in XQuery) that all user-defined functions be defined in a namespace.

2. Provide built-in namespace prefix (local, xql, ...) so that user is not required to define function namespace in every query.

E.g., define function local:test () { }

Benefits

* Simplifies rules for resolving unprefixed function and type names ALOT!

* Aligns with XSLT, which requires all functions be defined in some namespace.

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F, accepting XPath TF proposal

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F, accepting XPath TF proposal

Summary of things needed:

No necessary change to the grammar.

But other change is that if somebody chooses the fn namespace as default, other implementation-defined functions have to be prefixed.

We have to add the constraints on where you can put your functions (which URIs you can add them to).

We have to define "local" (have a mapping in the language document between chosen prefix and corresponding URI)

And, we have to change the Use Cases accordingly.

229. more-than-one-precedes: Do we need both << and precedes?

Locus: xpath Cluster: syntax Priority: o-2 Status: resolved
Originator: XQuery/XSL WGs

Description

Do we need both << and precedes?

Actual Resolution

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)

"precedes" and "follows" operators deleted.

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.

230. context-multiple-documents: Context document adequate for multiple docuemnts?

Issue Class: D Locus: xpath Cluster: context Priority: 1 Status: resolved
Originator: Michael Rys

Description

Is "/" and the context document adequate for multiple documents?

Interactions and Input

Cf. Mapping Input Context

Actual Resolution

Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)

Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Access is provided to multiple documents using a different mechanism, specifically the input() and collection() functions.

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.

231. fallback-data-function: data(SimpleValue) is error or no-op?

Locus: xpath Cluster: fallback Priority: o-1 Status: resolved
Originator: XSL WG

Description

What is the result of applying the data() function on a SimpleValue? Is it an error, is it a no-op, or is it a type exception with a fallback?

Actual Resolution

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)

Decision by: xquery on 2002-05-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002May/0241.html)Reaffirming the XPath TF telcon 2002-04-30 view.

Decision by: xsl on 2002-06-27 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Jun/0037.html)

data() applied to simple value is identity function (no-op). Rationale: does not require special 'fallback' behavior and if we resolve Issue 0172 so that data is defined on node sequences, then for consistency, it should be defined on heterogeneous sequences. Still waiting on general proposal for Issue 172.

At the XPath TF telcon 2002-04-30 it was noted that the current documents do not reflect the resolution, as recorded in our issues list. The documents need to be modified accordingly.

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.

232. operators-on-date: Use "+" and "-" on dates and durations?

Locus: xpath Cluster: syntax operators date Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Should we use the operators + - on dates and durations, when addition of dates is not associative or commutative?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Agreed to close this issue with no change to documents.

Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0252.html)

Closed with no change to document.

233. syntax-flwr: Simpler FLWR syntax?

Locus: xquery Cluster: syntax Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Now that we have keywords, should we return to the simpler syntax?

  FLWRExpr ::= (ForClause | LetClause | WhereClause)* "return" Expr
  

Actual Resolution

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)

Decided NOT to adopt a simpler syntax.

234. order-sequences-who-defines: Who defines sorting order of ()?

Locus: xpath Cluster: order sequences Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

2.10, + Point 5 (Draft 2001-11-28). If we don't adopt Plil W's proposal in Point 1, then there should be an Issue as to whether the behaviour should be specified by the user, or the vendor. One option is to let the user specify that () sorts high, low, or either, in the latter case the vendor decides.

Interactions and Input

Cf. Order of sequences

Actual Resolution

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)

Decided to accept status quo.

235. parenthesis-conditional-expression: Need parenthesis in conditional expression?

Locus: xpath Cluster: syntax Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Now that we have keywords, do we need parentheses in the conditional expression?

Actual Resolution

Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)

Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)

Recommendation to drop the "then".

Subsequently some problems and differing views were expressed. The discussions will continue.

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.

236. keyword-before-simpletype: SimpleType preceded by a keyword?

Locus: xpath Cluster: syntax Priority: o-1 Status: resolved
Assigned to: xquery Originator: Phil Wadler

Description

Issue as to whether SimpleType (was BuiltInType) might be preceded by a keyword. Now that we have "element of type" it seems natural to use "type" to preced SimpleType, possible generalizing to also allow a complex type.

Actual Resolution

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)

This particular issue with SequenceType has been solved, issue closed with no modification to the document.

237. parenthesis-type-switch-expression: Need parenthesis in type switch expression?

Locus: xquery Cluster: syntax Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Now that we have keywords, do we need parentheses in the type switch expression?

Actual Resolution

Decision by: xquery on 2003-01-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0215.html)Joint F2F

Closed with no action because we need parenthesis because of no reserved word.

238. consistency-tradeoffs: Consistency: tradeoff between interoperability and efficiency

Locus: xpath Cluster: consistency Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Consistent tradeoff between interoperability and efficiency. There are a number of places where XQuery must choose between pinning down precise behaviour or offering flexibility to the implementor. These include whether order in "for" expressions is significant, whether sorting is stable, whether order is significant for duplicate elimination, whether order is significant when finding the union, merge, except of sequences of values, and the like. We should have a consistent policy for making these choices.

Actual Resolution

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.

239. consistency-bracketing: Consistency: bracketing of nested expressions

Locus: xpath Cluster: consistency Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Consistent bracketing of nested expressions. Some nested expressions are surrounded by parentheses (treat, cast, assert), some nested expressions are surrounded by braces (element construction, function body), and some nested expressions are not bracketed (for expression, conditional expression). We should have a consistent policy for bracketing of nested expressions.

Actual Resolution

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.

240. consistency-parenthesizing-test-expressions: Consistency: parenthesizing test expressions

Locus: xpath Cluster: consistency Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Consistent parenthesizing of test expressions. Some test expressions are surrounded by parentheses (conditional, type switch) and some are not (where). We should have a consistent policy for parenthesizing of test expressions.

Actual Resolution

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.

241. consistency-keywords: Consistency: keywords

Locus: xpath Cluster: consistency Priority: o-1 Status: resolved
Originator: Phil Wadler

Description

Consistent keywords. Some keywords concatenate two words "sortby", "typeswitch", while others are multiple words "element" "of" "type", "cast" "as", "instance" "of". We should have a consistent policy for keywords.

Actual Resolution

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)

We have decided to go with multi-word keywords. Close the issue as "done". Typeswitch is an exception.

242. sortby-partial-order: Sortby on partially ordered values?

Locus: xquery Cluster: sort Priority: 3 Status: resolved
Originator: Michael Rys

Description

I was unable to find the semantics of what happens of sortby tries to order based on a base type that only has partial order (e.g., Duration). Can we explicitly disallow this?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Issue covered by the following rule in the XQuery document section 3.8.3 Order By and Return Clauses:

- Each orderspec must return values of the same type for all tuples in the tuple stream, and this type must be a (possibly optional) atomic type for which the gt operator is defined--otherwise, a dynamic error is raised.

243. sort-disappearing: Provide an example of sorting "disappearing"

Locus: xpath Cluster: sort Priority: 3 Status: decided
Originator: Michael Rys

Description

Provide an example of

   (employee sortby data(salary))/name
  

Actual Resolution

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)

Decided to leave this to editorial discretion.

244. cdata-serialization: CDATA sections and serialization

Locus: xquery Cluster: serialization Priority: 2 Status: decided
Originator: Michael Rys

Description

What are the semantics of CDATA sections in XQuery? Are they preserved in the data model for serialization?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Decided to close, with document changes as described by Mike Kay in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0095.html, including editorial comments.

245. curly-braces-in-text: Are {} in text evaluated?

Locus: xquery Cluster: syntax curly brace Priority: 2 Status: resolved
Originator: Michael Rys

Description

In attribute definitions, "{a}" will be interpreted as expression a returning the value for the attribute. Is this also the case for texts in general (inside an element construction)?

Actual Resolution

Decision by: xsl on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Decision by: xquery on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Yes it will be evaluated, for example in:

<a>this is {@color} text</a>

246. nested-comments: Nested XQuery comments allowed?

Locus: xquery Cluster: syntax Priority: 2 Status: decided
Originator: Michael Rys

Description

Nested XQuery comments allowed?

Actual Resolution

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

Permit nested comments. Use "(:" and ":)" syntax.

247. namespace-default-affecting: What does default namespace(s) affect?

Locus: xpath Cluster: namespaces Priority: 2 Status: decided
Originator: XPath TF

Description

What is effect of default namespace declarations on unprefixed QNames that may occur in element constructors, attribute constructors, and name tests (or anywhere else).

In XPath 1.0, in-scope namespace decls effect prefixed QNames, but default namespace decl does not effect unprefixed names in a name test. In XSLT 2.0, we introduced multiple default namespace decls :one for constructed elements, one for names in xpath expressions.

Actual Resolution

Decision by: xquery on 2002-09-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0180.html)

Decided to accept status quo:

- default element namespace defines a namespace URI that is associated with unprefixed names of elements and types.

- default function namespace defines a namespace URI that is associated with unprefixed names of functions.

248. evaluate-function: Evaluate function

Locus: xpath Cluster: evaluate Priority: 4 Status: postponed
Originator: XPath TF

Description

> The question, for me, is whether it belongs to the minimum required to
> declare victory. I suspect that it does not.

It (evaluate) is one of the most requested (and widely implemented)
extensions in current xpath 1.0 implementations.

If Xpath2 adds useful new functionality in the area of type checking and
schema support but doesn't address many of the main issues raised by
existing xpath1 users (evaluate, higher order functions, regexps, ...)
then I don't think that victory can be declared.

I think it's reasonable that the current set of drafts have concentrated
on the newer features and the merge with Xquery but that's the first
draft it isn't enough to "declare victory".

David [Carlisle]

XSLT decided not to support eval() in Version 2.0.

249. higher-order-functions: Higher-order functions

Locus: xpath Cluster: higher-order-functions Priority: 4 Status: postponed
Originator: XPath TF

Description

Should these be included in XPath 2.0?

Interactions and Input

Input from Dimitre Novatchev:

Input from Phil Wadler:

Date: Tue, 29 Jan 2002 11:29:46 -0500
From: Philip Wadler <wadler@research.avayalabs.com>
Subject: Higher-order functions

I love higher-order functions.  But here are some reasons why we
should postpone including them in XPath 2.0 and XQuery 1.0.  -- P

1.  Typing.  Higher-order functions require an extension to the type
system.  Schema has no support for higher-order functions, so this
would be at odds with our desire to make our type system as close to
Schema as possible.

2.  Data model.  Do we allow functions to be stored in data values?
This greatly extends the value of higher-order functions.  It is
what is usually done in functional languages.  Support of this
would require significant change in our data model.

3.  Optimization.  Optimizing a higher-order function usually requires
some form of inlining.  The functional programming community has a lot
of experience in decing when to inline and when not to inline, it is
something of a fine art.  It is not particularly hard to do such
optimizations, but this is probably not where we want early
implementors to put their effort.

250. declaring-variables-in-prolog: Declaring Variables in Prolog

Locus: xquery Cluster: variables Priority: 2 Status: decided
Originator: Jonathan Robie

Description

Functions in a function library often need to access the same variables. For instance, a function library that manipulates a grammar may need to use the following variables in many functions:

$grammar := document("xpath-grammar.xml")/g:grammar
$target := "xquery"

One possible syntax for this is:

'define' ''variable' varname ':=' expr

The above production would occur only in the prolog.

Actual Resolution

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.

251. sort-by: Sorting "input to loop", not the result

Locus: xquery Cluster: sort Priority: 2 Status: decided
Originator: Phil Wadler

Description

Consider this query:

   for $x in /books/book, $y in /reviews/review
   where $x/isbn = $y/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>
   sortby isbn

This is an error, since isbn doesn't appear in newbook. (The static type system would catch this error.) What you have to write is

   for $z in
     for $x in book, $y in review
     where $x/isbn = $y/isbn
     return <dummy>{ $x/title, $x/author, $y/reviewer, $x/isbn }</dummy>
     sortby isbn
   return <newbook>{ $z/title, $z/author, $z/reviewer }</newbook>

This is painful.

I think that XQuery should support this syntax, or something similar:

   for $x in book, $y in review
   where $x/isbn = $y/isbn
   sortby $x/isbn
   return <newbook>{ $x/title, $x/author, $y/reviewer }</newbook>

Our plate is full with more important matters just now, but I hope we could fix this before we finalize XQuery.

Actual Resolution

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.

252. sortby-name: "sort by" rather than "sortby" for consistency?

Locus: xquery Cluster: consistency Priority: 2 Status: resolved
Originator: Phil Wadler

Description

By the way, why is it "sortby"? Since we changed "instanceof" to "instance of", shouldn't we change "sortby" to "sort by"?

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

No change to document. THis is already decided (we have "order by").

253. cast-simple-type-of-node: CAST as simple type of a node type

Issue Class: TF Locus: xpath Cluster: type-semantics Priority: 2 Status: resolved
Originator: Michael Rys

Description

Given the expression:

cast as xsd:decimal(//element_string [3]) div cast as
xsd:decimal("+1.25000000")

and a type of ELEMENT element_decimal [xsd:string] for the element_string nodes, our current cast rules disallow the cast of the element node to a value, since the above expression would be translated into:

data(cast as xsd:decimal(//element_string [3])) div cast as
xsd:decimal("+1.25000000")

instead of (the user expected):

cast as xsd:decimal(data(//element_string [3])) div cast as
xsd:decimal("+1.25000000")

Could we change the casting rules to allow the above?

We could either add a rule that pushes data() into cast expressions or have a special rule for casting to simple value types that implies applying data() in the casted expression (similar to arithmetic expressions).

Actual Resolution

Addressed by the "Named Typing" proposal: XQuery Section 2.13 cast does data extraction.

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.

254. lexical-details-in-doc: Should the lexical details be in document?

Locus: xpath Cluster: grammar Priority: 2 Status: resolved
Originator: XPath TF

Description

Current grammar documents lexical states and maps directly to tool we use. An alternative is to use an alternative grammar and document lexical states with the tool separately.

Actual Resolution

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)

Decided to accept the current approach in the XPath/XQuery documents.

255. operators-derived-type: What are the operators on a derived type?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

User defines a derived type, what operators are inherited by that type. SQL has a concept of distinct type. A distinct type does not inherit the operastors on the base type. XQuery in F&O does the opposite. All operations on the base type are inherited.

Interactions and Input

Input from Don Chamberlin:

Input from Don Chamberlin:

Actual Resolution

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)

This has been discussed and the decision taken to be different from SQL. Issue closed with no document change.

256. return-type-collection: What is return type of colections?

Issue Class: D Locus: xpath Cluster: collections Priority: 1 Status: resolved
Originator: XPath TF

Description

MR: Why does collection() return item*. I want document*.

JR: You can specify what you want. You have to accept a URI and what you return is implementation dependent.

SCA: Strawpoll. 5 item*, 3 document*. No one cannot live with item*

Can an implementation provide a more specific return type than item* and still be a conforming implementation?

Some discussion. No consensus.

Actual Resolution

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)

Decided to accept status quo: xf:collection(string $srcval) => node*

257. collection-always-return-same: Does collection() always return same result?

Issue Class: D Locus: xpath Cluster: collections Priority: 1 Status: decided
Originator: XPath TF

Description

Does collection() always return same result for the same URI? The same within the scope of a query/transformation? Are the nodes in the sequence identical?

Actual Resolution

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)

It should return the same answer every time. Applies also to input(). We should use the same language as we use for document() and for current-dateTime().

258. document-nodes-identity: Identity of Document Nodes

Issue Class: D Locus: xpath Cluster: documents Priority: 2 Status: decided
Originator: Jonathan Robie

Description

Consider the following query:

        if (document("foo.com") == document("foo.com"))
                then <yep/>
                else <nope/>

I would like the following output:

        <yep/>

I think we can achieve this if we say that the URI of a resource is used as its identity. However, one resource can be identified by more than one URI. Suppose that "foo.com/here/there/hi.xml" and "file://c:/temp/limerick-tei.xml" refer to the same resource. What does the following return?

if (document("foo.com/here/there/hi.xml") ==
document("file://c:/temp/limerick-tei.xml"))
        then <yep/>
        else <nope/>

Should we simply use the URI of the parameter to establish identity and say that the two do not match? Should we make the result implementation-dependent?

Actual Resolution

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)

This is already covered by the existing spec, but we may want to review the language as part of the actions for issue 257.

259. unknown-simple-type-arithmetic: Arithmetic operation rules for unknown simpletype

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Michael Rys

Description

Currently, the arithmetic operation rules in [1] say:

The operands of an arithmetic expression do not have required types. An arithmetic expression is evaluated by applying the following rules, in order, until an error is raised or a value is computed:

1. If any operand is a sequence of length greater than one, a type exception is raised.

2. If any operand is an empty sequence, the result is an empty sequence.

3. If any operand is a node, its typed-value accessor is applied. If the node has no typed-value accessor, or if the typed-value accessor returns a sequence of more than one value, an error is raised. If the typed-value accessor returns the empty sequence, the result of the expression is the empty sequence.

4. If any operand is an untyped simple value (such as character data in a schemaless document), it is cast to the type suggested by its lexical form. For example, the untyped value 12 is cast to the type xs:integer.

5. If the arithmetic expression has two numeric operands of different types, one of the operands is promoted to the type of the other operand, following the promotion rules in [XQuery 1.0 and XPath 2.0 Functions and Operators]. For example, a value of type xs:integer can be promoted to xs:decimal, and a value of type xs:decimal can be promoted to xs:double.

6. If the operand type(s) are valid for the given operator, the operator is applied to the operand(s), resulting in either a simple value or an error (for example, an error might result from dividing by zero.) The combinations of simple types that are accepted by the various arithmetic operators, and their respective result types, are listed in [XQuery 1.0 and XPath 2.0 Functions and Operators]. If the operand type(s) are not valid for the given operator, a type exception is raised.

Rule 4 cannot be efficiently implemented and basically would defer any algebrization of the operation to the runtime when the value is actually available to make this decision. Not even XPath 1.0 had such an impossible rule. (see also Mary's reply in [2])

Instead, I would like to align this with the rules of comparison operators in the following way:

The untyped simple value is cast to the type of the other operand.

If both operands are untyped, they are cast to double (in analogy to the XPath 1.0 number conversion).

E.g.,

unknownSimpleType + xsd:decimal will become cast as xsd:decimal
(unknownSimpleType) + xsd:decimal.
unknownSimpleType + unknownSimpleType will be cast as xsd:double
(unknownSimpleType) + cast as xsd:double
(unknownSimpleType).

Another proposal was provided by Michael Kay in [3] that however relays on the not yet introduced type numeric [4], thus I think we should follow the rule above (which is basically the same as we do for comparisons).

[1] http://www.w3.org/TR/xquery/#id-arithmetic

[2] http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0029.html

[3] http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0021.html

[4] http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Feb/0067.html

Proposed Resolution

I have been tasked with rewording the sections 2.5 and 2.6.1 in [1] with
two proposed solutions for implicit treatment of unknown simple types
(UST) with arithmetic and comparison operators based on my earlier
proposal in [2] and a subsequent simplification discussed at today's
XPath TF call. The rewording should also refer to the basic conversion
rules that are defined in [1] Section 2.1 as:

The basic conversion rules are as follows:

If the required type is a simple type or an optional occurrence of a
simple type:

If the given value is a sequence of more than one item, a type exception
is invoked. If the given value is a single node, its typed value is
extracted by calling its typed value accessor. If the node has no typed
value accessor or if its typed value is a sequence containing more than
one item, a type exception is invoked.

If the (given or extracted) value has an unknown simple type (as in the
case of character data in a schemaless document), an attempt is made to
cast it to the required simple type. If the cast fails, a type exception
is invoked.

If the (given or extracted) value does not conform to the required type,
a type exception is raised. This includes the case in which the (given
or extracted) value is an empty sequence and the required type is not an
optional occurrence.

If the required type is a sequence of a simple type:

If the given value is a sequence containing one or more nodes, each such
node is replaced by its typed value, resulting in a sequence of simple
values. Each of these simple values then is converted to the required
type by applying the rules described above for converting values to a
required simple type.

If the required type is a sequence of nodes:

If the given value contains any item that is not a node, a type
exception is invoked.

In addition, I assume that numeric and numeric types are well-defined
terms referring to the set of types double, float, decimal and all their
subtypes (derived by restriction).

********************************************
Proposal I: Rewrite to treat UST as double if operating with numeric
types
********************************************
2.5 Arithmetic Expressions
<leave as is until "For example, a-b will be interpreted as a single
token."/>

An arithmetic expression is evaluated by applying the following rules
that are based on the basic conversion rules, in order, until an error
is raised or a value is computed:

The required types of the operands of an arithmetic expression do not
have required types.

1. If any operand is a sequence of length greater than one, a type
exception is raised (applying the basic conversion rule to each
argument).

2. If any operand is an empty sequence, the result is an empty
sequence(applying the basic conversion rule to each argument).

3. If any operand is a node, its typed-value accessor is applied. If the
node has no typed-value accessor, or if the typed-value accessor returns
a sequence of more than one value, an error is raised. If the
typed-value accessor returns the empty sequence, the result of the
expression is the empty sequence. (applying the basic conversion rule to
each argument).

4. If any or both operands are an untyped simple value (such as
character data in a schemaless document), the basic conversion rule is
applied and the required type is xs:double. Thus an untyped simple value
is cast to type xs:double.

5. If the arithmetic expression has two numeric operands of different
types, one of the operands is promoted to the type of the other operand,
following the promotion rules in [XQuery 1.0 and XPath 2.0 Functions and
Operators]. For example, a value of type xs:integer can be promoted to
xs:decimal, and a value of type xs:decimal can be promoted to xs:double.
This is an extension to the basic conversion rule.

6. If the operand type(s) are valid for the given operator, the operator
is applied to the operand(s), resulting in either a simple value or an
error (for example, an error might result from dividing by zero.) The
combinations of simple types that are accepted by the various arithmetic
operators, and their respective result types, are listed in [XQuery 1.0
and XPath 2.0 Functions and Operators]. If the operand type(s) are not
valid for the given operator, a type exception is raised.

Ed. Note: A future version of this document will provide a mapping from
the arithmetic operators to the functions that implement these operators
for various datatypes. See issue 182.

Here are some examples of arithmetic expressions:

In general, arithmetic operations on numeric values result in numeric
values:

<rest stays the same/>

2.6.1 Value Comparisons

Value comparisons are intended for comparing single values. The result
of a value comparison is defined by applying the following rules, based
on the basic conversion rules, in order:

1. If either operand is an empty sequence, the result is an empty
sequence.

2. If either operand is a sequence containing more than one item, an
error is raised.

3. If either operand is a node, its typed value is extracted. If the
typed value is an empty sequence, the result of the comparison is an
empty sequence. If the typed value is a sequence containing more than
one item, an error is raised.

4. If one of the operands is an untyped simple value (such as character
data in a schemaless document) and the other operand is a typed simple
value, the required type for casting the untyped simple value is
determined by the type of the other operands as follows:
   - if the type is of the other operand is numeric the required type
becomes xs:double.
   - if the type of the other operand is unknown, then the required type
for both becomes xs:string.
   - otherwise the type of the other operand becomes the required type.

5. The result of the comparison is true if the value of the first
operand is (equal, not equal, less than, less than or equal, greater
than, greater than or equal) to the value of the second operand;
otherwise the result of the comparison is false. [XQuery 1.0 and XPath
2.0 Functions and Operators] describes which combinations of simple
types are comparable, and how comparisons are performed on values of
various types. If the value of the first operand is not comparable with
the value of the second operand, a type exception is invoked.

Ed. Note: A future version of this document will provide a mapping from
the comparison operators to the functions that implement these operators
for various datatypes. See issue 182.

Here is an example of a value comparison:

The following comparison is true only if $book1 has a single author
subelement and its value is "Kennedy":

$book1/author eq "Kennedy"

********************************************
Proposal II: Rewrite to treat UST as the other numeric type
********************************************
2.5 Arithmetic Expressions
Change Proposal I Rule 4 to:

4. If of the operands is an untyped simple value (such as character data
in a schemaless document), the basic conversion rule is applied and the
required type is set based on the type of the other operand:
  - the required type for both operands becomes xs:double if the type of
the other operand is unknown
  - otherwise the required type becomes the type of the other operand.
Thus an untyped simple value added to a float is cast to type xs:float.

2.6.1 Value Comparisons
Change Proposal I Rule 4 to:

4. If one of the operands is an untyped simple value (such as character
data in a schemaless document) and the other operand is a typed simple
value, the required type for casting the untyped simple value is
determined by the type of the other operands as follows:
   - if the type of the other operand is unknown, then the required type
for both becomes xs:string.
   - otherwise the type of the other operand becomes the required type.

********
Analysis
********

The advantage of proposal I is that it is closer to the known XPath
behaviour (although as Peter pointed out not the same), it is simpler to
explain and implement and allows expressions where the UST value is a
double and an operation combines it with a type based on decimal that
would lead to runtime errors in case II. Based on extensive discussions
with my constituency, users and implementers alike, this seemed to be
the preferred solution.

The disadvantage is a slight loss of type precision on the result that
can be regained by explicitly casting the result or operands to the
desired type.

Best regards
Michael

[1] http://www.w3.org/TR/xquery/
[2] http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Mar/0037.html

Actual Resolution

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.

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.

260. instanceof-implicit-data: Implicit data() on instanceof?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 2 Status: resolved
Originator: Michael Rys

Description

Does expr instance of type define an expected type with type so that data() is implied explicitly on:

let $e := <e xsi:type=?xsd:integer?/>
return
$e instanceof xsd:integer

is that

let $e := <e xsi:type=?xsd:integer?/>
return
  data($e) instanceof xsd:integer

and thus true or false?

This issue is somewhat related to CAST (Issue 253), but since we perform a type test here, I would argue that we should not.

Interactions and Input

Cf. CAST as simple type of a node type

Actual Resolution

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)

Decided to accept status quo, which is also the recommendation made in the issue.

261. attribute-constructor-quoting-rules: Quoting rules in nested expressions in attribute value construction

Locus: xquery Cluster: syntax quotes Priority: 2 Status: resolved
Originator: Michael Rys

Description

We currently say that in a constant string in XQuery, I can do any of the following three to escape quotes (please correct if I am wrong):

A. XQuery rule (works both in XQuery only and XQuery in XML embedding): quotes and double quotes are doubled if they are enclosed inside their own kind.

E.g.,

Lexical              Value in datamodel
'"'                  "
''''                 '
""""                 "
'""'                 ""

B. XML rules (work only in XQuery in XML embedding since XML parser will work:

B1. Use ' when string delimiter is " and viceversa. This of course does not preserve data fidelity, so if the difference between them is important, you will need to use B2.

B2. Entitize

I assume that I cannot do just B, but that I have to use B to get A. E.g., <a foo="&quot;"/> in an XML document is not a valid XQuery and I have to write <a foo="&quot;&quot;"/>

The problem that I have is that I do not know what the rules are for nesting quotes inside XQuery expressions:

What are the rules for:

<foo bar="{fnc1(<baz goo="{fnc2("string arg")}"/>)}"/>

Do I have to double and then triple? Does {} mean that the outside "" become inconsequential?

Actual Resolution

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

Closed with no action. Double quotes are only meaningful inside string literals. A clarifying example to be added to the text.

262. data-on-elements-with-known-complex-type: Definition of data() on elements with known complex type

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XPath TF

Description

An alternative definition of data() on elements with known complex type:

If $e is an element of an known (complex) type, then data($e) evaluates to the concatenation of $e's text nodes and has UnknownSimpleType.

This definition is appropriate when explicit casts are necessary to convert UnknownSimpleType to other atomic types, i.e., when the basic conversion rules *DO NOT* implicitly convert UnknownSimpleType to other atomic types.

The benefit of this alternative is that a user can always safely apply data() to any node and is guaranteed never to get an error.

Actual Resolution

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)

Decided to accept status quo, which is to raise an error.

263. data-on-elemets-with-unknown-type: Definition of data() on elements with unknown type, whose content may be simple or complex

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XPath TF

Description

The the data() function is only defined on element and attributes with a simple type. The definition of data() on other kinds of nodes or on element and attributes with unknown type is still an open issue.

The corresponding issue in the Formal Semantics document is Issue-108.

Actual Resolution

Decision by: xpath-tf on 2002-04-11 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Apr/0087.html)

xf:data(): decided that it should return the error object when applied to document, PI, comment and namespace nodes.

This change should be reflected in the F&O, XPath and Data Model document.

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.

264. variables-shadowing: Shadowing of Variables

Locus: xpath Cluster: variables Priority: 1 Status: resolved
Originator: Michael Kay

Description

XSLT does not allow a local variable to be declared if there is already a local variable in scope with the same name. For example, the following is disallowed:

<xsl:variable name="i" select="0"/>
<xsl:for-each select="item">
  <xsl:variable name="i" select="$i + 1"/>
  <a><xsl:value-of select="$i"/></a>
</xsl:for-each>

This restriction has proved with experience to be a good thing, because users writing a construct such as the one above have almost invariably misunderstood the way variables work in a declarative language; if the construct were allowed, it would not give them the results they expect.

The equivalent XQuery expression is currently allowed:

let $i := 0
for $x in item
   let $i := $i + 1
   return <a>{$i}</a>

XPath 2.0 has no "let" expression, but it can include variable declarations, and these are allowed to shadow each other.

For XSLT users, it seems inconsistent that there should be different rules in XSLT and in XPath. The XSLT 1.0 rule, which makes variable shadowing an error, has proved useful in practice and we recommend that it should be adopted also for XPath 2.0 and XQuery 1.0.

Interactions and Input

Cf. Variable redefinition allowed?

Actual Resolution

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-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.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.

265. lang-inheritance: How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Priority: 2 Status: decided
Originator: FTTF

Description

How do we determine the xml:lang for a node if it inherits xml:lang from a higher-level node?

Actual Resolution

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

Decided to close issue with no change to documents, since user-written expressions or functions can determine the value of xml:lang that a node inherits.

266. lang-sublanguage-support: Do we support the sublanguage portion of xml:lang?

Locus: xpath-fulltext Cluster: FTTF-xml:lang Priority: 2 Status: decided
Originator: FTTF

Description

Do we support the sublanguage portion of xml:lang? If so, how?

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

A user-written expression of function has to determine the value of xml:lang and then do the appropriate analysis of the value. No change to document.

267. validate-syntax-problem: Syntax problems with "validate"

Locus: xpath Cluster: syntax Priority: 1 Status: resolved
Originator: XPath TF

Description

If "validate" is in XPath the "{}" in the syntax conflicts with the current use in XPath. It needs to change to use "()" instead.

Actual Resolution

Decision by: x-editors on 2002-10-02 (http://lists.w3.org/Archives/Member/w3c-query-editors/2002Oct/0007.html)

Scott: We can close this because {} does not create a problem.

Decision by: xsl on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

Decision by: xquery on 2002-10-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0379.html)Joint f2f

It has been confirmed that there are no problems, example:

<e a="{(validate {bookdoc})/title}"/>

268. string-anySImpleTyped-data-behaviour: xsd:string and anySimpleType'd data behave the same?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery WG

Description

Should we simplify the relationship between xsd:string and the anySimpleType'd data to have them both behave the same operationally by providing implicit coercions and being type compatible?

Alternate, in some peoples view mutually exclusive, issue:

Should we simplify the relationship between xsd:string and the anySimpleType'd data to have them both behave the same operationally by disallowing implicit coercions on anySimpleType and being type compatible?

Actual Resolution

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)

Only in backwards compatibility mode do they behave in the same way. Otherwise they are and will be different. Issue closed with no change to document.

269. unknown-keyword-needed: Can we get rid of the unknown keyword

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery WG

Description

Can we get rid of the unknown keyword?

Interactions and Input

Input from Michael Rys:

Actual Resolution

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)

Decided to accept the current language: 'untyped' is used to refer to items whose most specific type is xs:anySimpleType or xs:anyType. Note that when the required type is xs:anySimpleType or xs:anyType, SequenceType matching will match any instance derived from these types; for 'unknown', it will not.

270. typing-coercions-conformance: Typing, coercions, and conformance

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery WG

Description

One difficulty in designing XQuery is that it must meet the needs of two quite different constituencies:

Convenient: Quickly write queries to explore a large body of data. Works best with implicit coercions and dynamic typing.

Reliable: Solidly engineer queries for web services. Works best with explicit coercions and static typing.

We've already agreed to have two conformance levels, one with dynamic typing and one with static typing. Perhaps the dynamic typing level should have implicit coercions and the explicit typing level should have explicit coercions.

Actual Resolution

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)

Decided to accept the current XQuery section on conformance.

271. heterogenous-union-types-compatibility: Type compatibility of heterogeneous union types

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XQuery WG

Description

Currently the formal semantics maps arithmetic and comparison operations that have union types as (at least of one of) their argument types to a runtime type switch. This has serious unwanted consequences for "algebraization" of queries and optimization and leads to some surprising static typing results.

Should we make non-promotable union types on such operations a type error instead?

Actual Resolution

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; the issue is now moot.

272. external-functions: External Functions

Locus: xpath Cluster: external-functions Priority: 1 Status: decided
Originator: Michael Kay

Description

The ability to call external functions is an established feature of XSLT 1.0, and is retained in XSLT 2.0. The facility is widely used, and some significant libraries of external functions have been developed by third parties. We made an attempt to standardize language bindings for external functions in the XSLT 1.1 working draft, but this proved highly controversial and has been dropped. The facility remains, however, even though the binding mechanisms remain implementation-defined.

The XPath 2.0 specification continues to tolerate external functions, though it doesn't really acknowledge their existence properly. All we say is that the repertoire of functions that can be called is part of the context.

The issue is: should the function function-available() function be transferred from XSLT to XPath?

This function tests whether a named function is available, and returns true if it is, and false if it isn't. A typical call is:

if  (function-available('my:debug')) then my:debug('Hi!') else ()

This has two implications:

(a) a call on my:debug must not be a static error if the function is not available

(b) the names of functions (and the in-scope namespaces needed to resolve their QNames) must be available at run-time.

Logically the function-available() function has no dependencies on XSLT so it should be transferred to XPath.

Actual Resolution

Decision by: xpath-tf on 2002-12-10 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0164.html)

Proposed to resolve by stating that the XPath specification to state that at the discretion of the host language, a call to a function that is not in the static context may generate a dynamic error rather than a static error.

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

This issue is also impacted by the following decision:

Decided to adopt 1B and 2A in proposal for issue #xquery-module-syntax.

273. external-objests: External Objects

Locus: xpath Cluster: external-objects Priority: 1 Status: decided
Originator: Michael Kay

Description

Part of the strength of external functions is that they can return objects that are outside the scope of the XPath type system. For example, a function library for performing SQL database access may have a function sql:connect() that returns an object representing a database connection. This object may be passed as an argument to calls on other functions in the SQL function library.

The way this is handled in XPath 1.0 is that the XPath specification defines four data-types, and explicitly leaves the host language free to define additional data types. We could probably live with a similar solution for XPath 2.0, but it's a fudge, and I think we ought to try and do better.

Note that the only things you can do with an external object (under the XSLT 1.0 rules) are to assign it to a variable, or pass it as the argument to another function. In practice I think implementations also allow external objects to have additional behavior, for example they might allow conversion to a string when used in a context where a string is required. I think we should leave such behavior implementation-defined rather than saying that it is always an error.

The question arises as to where external objects should fit into the type hierarchy. Should they be a top-level thing at the same level as "sequence", or should they be one level down, along with "node" and "atomic value"? I think it makes most sense to preserve the principle "everything is a sequence", which means that there are now three kinds of item: nodes, atomic values, and external objects.

Handling this rigorously sounds like quite a pervasive change to the spec, but I don't think it's as bad as it seems. I don't think we should add any language features to support external objects, with the possible exception of a keyword "external" in the type syntax so that one can test for it using "instance of". Functions and operators that work on any sequence (for example, count) should treat an external object like any other item in the sequence. Operations that expect nodes will fail if presented with an external object; operations that expect atomic values will also fail, except that implementations may define fallback conversions from external objects to atomic values.

Interactions and Input

Cf. Can (and should) keyword extensions be allowed in XQuery by equipping them with a namespace prefix?

Cf. XQuery Extension Mechanisms

Proposed Resolution

Technically, I believe we could close the issue with no change to the documents, on the basis that the definition for the static context (in both XPath and XQuery) states: "Additional type definitions may be added to the in-scope type definitions by the language environment." I think an implementation could take this as sufficient authority to extend the type hierarchy with additional types, including types needed to represent objects returned by extension functions (such as "an SQL database connection").

Editorially, I think it would be a good idea if we state this explicitly in a Note, as follows:

NOTE: an implementation may allow function calls in a Query/Expression to bind to functions written in languages that use a different type system (these are known as "extension functions" in XSLT, "external functions" in XQuery). In this case, the way in which the arguments and results of such functions are mapped between the two type systems is implementation-defined. An implementation may define new types anywhere within the type hierarchy of the [Data Model] that are designed to facilitate interworking with other languages, for example a type that encapsulates an object returned by an external function; or it may provide mechanisms for the user to define such types.

Actual Resolution

Decision by: xpath-tf on 2003-03-11 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0206.html)

Decision by: xquery on 2003-03-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0344.html)

Proposal accepted.

274. text-only-implementations: Text-node-only implementation possible?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: XSL WG

Description

The current proposed text for XQuery element constructors precludes a "text node only" implementation. Since XSL should have semantics aligned with XQuery a decision needs to be made by the XSL WG as to if this restriction is acceptable to construction in XSLT.

Actual Resolution

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)

It is poosible under "Alternative 1".

275. xquery-validate-identity: Should validation also check identity constraints?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Should validation also check identity constraints? Note that valid identity constraints of partial documents does not imply validity of the document as a whole. The current document says that identity constraints are not checked.

Actual Resolution

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)

Decided to accept statys quo - which says it should not.

276. xquery-superfluous-xsi_type: Does validation introduce new xsi:type attributes?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Does validation introduce new xsi:type attributes, or should xsi:type attributes introduced for validation be removed?

Note: The XPath telcon suggested that we eliminate this issue and simply say that any attributes introduced for the purpose of validation are removed as part of the validate semantics.

Actual Resolution

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)

Decided to accept statys quo - which says it does not.

277. xquery-add-xsi_type: Should validate introduce xsi:type?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Should validate introduce xsi:type to reflect type annotations that are not explicitly stated using an xsi:type in the source document?

The current draft introduces xsi:type to reflect inferred or dynamically computed types.

Actual Resolution

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)

Decided to accept statys quo - which says it does not.

278. xpath-is-xsi_type-attribute: Does //@xsi:type match an xsi:type attribute?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Does //@xsi:type match an xsi:type attribute? Compare to xml:lang, xml:space, xmlns, which are not represented as attributes in the XML Information Set. Note, however, that xsi:type is represented as an attribute in the Infoset. Should we treat it like other special XML attributes in the Data Model?

Actual Resolution

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)

xsi:type (as well as xml:lang, and xml:space) are ordinary attributes and you can match on them.

279. xpath-lightweight-cast: Should there be a lightweight cast?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: Jonathan Robie

Description

Should there be any provision for a lightweight cast that does not observe facets? Phil Wadler has suggested that 'validate' be used whenever full schema validation is desired, and 'cast' be used as a lightweight validation, which can be used for either simple or complex types, but which does not supply defaults, enforce facets, or check integrity constraints. It may be easier to optimize through cast than through validate, but supporting both constructs may confuse users due to their similarity. He suggests the following syntax for these expressions:

('cast'|'validate') as SequenceType ()
('cast'|'validate') 'in' ContextExpr { Expr }

Actual Resolution

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)

Decided to reject this proposal. Cast checks all facets.

280. xpath-list-simple-type: Do we need to distinguish atomic simple types and list simple types?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

XML Schema supports both atomic simple types and list simple types. Do we need to distinguish them in our grammar?

Actual Resolution

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)

Decided to close. We use sequences where XML Schema uses list types.

281. xpath-unknown-simple-type: Representing the type name of untyped character data

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

We need a way to represent the type name of untyped character data. In XML Schema, there is no one type that corresponds to this - in strict mode, elements whose content is untyped character data will have the type 'anyType' and attributes whose content is untyped character data will have the type 'anySimpleType', but this interacts in somewhat complex ways with lax and skip validation.

For now, we assume that character data may be associated with a SimpleType whose name is 'xs:unknownSimpleType'. This type does not currently exist in XML Schema, so we must coordinate with them on this issue.

If Schema does not provide a single type to represent untyped character data, we will provide a keyword for it in the ItemType production.

Actual Resolution

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)

Decided to accept status quo: For elements, this type is 'xs:anyType'; for attributes, it is 'xs:anySimpleType'.

282. xpath-xs_numeric-type: xs:numeric type

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

For our Formal Semantics, it would be very helpful to have a simple type to represent all numerics. For now, we are using the SimpleType name "xs:numeric". In XML Schema terms, this would be a union type. We must coordinate with XML Schema to see if they can support this. If not, we will provide a keyword for numerics in the ItemType production.

Actual Resolution

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)

It would be useful if Schema had such a type, but in the meantime we can get by.

Decided to close the issue with no change to document.

283. xpath-document-element-production: Is the DocumentElement syntax production necessary?

Locus: xpath Cluster: syntax-productions Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Is DocumentElement necessary?

Proposed Resolution

No.

Actual Resolution

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)

Decided to accept status quo: no such production.

284. xquery-static-named-typing: Static Named Typing

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

The typing must be covered by a static interpretation. If the Formal Semantics encounters difficulties in producing the static semantics, we may need to change the dynamic semantics.

Actual Resolution

Decision by: xpath-tf on 2002-11-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Nov/0187.html)

Decision by: xsl on 2002-11-14 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0044.html)

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

Decision by: xsl on 2003-01-09 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jan/0011.html)

Closed based on the adoption of the pure named typing proposal in all the books.

285. type-information-QName: Is the QName denoting type information optional or required?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: resolved
Originator: Phil Wadler

Description

Is the QName that denotes type information in an element or attribute optional or required?

Interactions and Input

Cf. Type of a newly constructed element

Cf. Should all elements and attributes have type annotations?

Actual Resolution

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)

Decided to accept status quo: it is optional.

286. element-construction-vs-streaming: Element Construction vs Streaming

Locus: xquery Cluster: constructor-expr Priority: 1 Status: decided
Originator: Michael Rys

Description

The element construction rules in 2.8 make efficient streaming of element construction difficult/impossible. For example, we execute the following expression on a stream and serialize the result in a streaming processing (such as XSLT like applications):

<foo>{"foo", "bar", if (expr) then "baz" else <baz/>}</foo>

If expr is true, then this is serialized:

<foo>foo bar baz</foo>

If expr is false, then this is serialized: <foo>foobar<baz/></foo>

The implementation must cache up the "foo" and "bar" strings, just in case a sub-element node is constructed. If not, then I must insert a space between "foo" and "bar". This seems to contradict one of our explicit use scenarios in the XML Query Requirements (section 2.5).

Interactions and Input

Cf. Functional Status of Comma

Cf. Element Constructor Attribute Order

Actual Resolution

Decision by: xquery on 2002-09-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Sep/0078.html)

This issue has been addressed by the recent changes to the element constructor.

287. functional-status-of-comma: Functional Status of Comma

Locus: xpath Cluster: syntax Priority: 1 Status: resolved
Originator: Michael Rys

Description

Is , a dyadic operator or (, , ,) a polyargument operator? The element construction rules seem to indicate the later, but the document is not clear. If , is a dyadic node-concatenation operation, then it would be more streamable than as an argument separator for the element constructor.

Interactions and Input

Cf. Element Construction vs Streaming

Cf. Element Constructor Attribute Order

Actual Resolution

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, with no change to current document. It clearly states that it is a dyadic operator.

288. element-constructor-attribute-order: Element Constructor Attribute Order

Locus: xquery Cluster: constructor-expr Priority: 1 Status: resolved
Originator: Michael Rys

Description

Unlike XSLT, attributes seem to be allowed anywhere which makes streaming implementations impossible. XSLT has the following rule:

"The following are all errors:

* Adding an attribute to an element after children have been added to it; implementations may either signal the error or ignore the attribute."

Example:

let $e := expr
return <a>{<b/>, ($e/@* | $e/*)</a>

XSLT would consider this an error. XQuery does not. This makes streaming impossible (see #element-construction-vs-streaming). Note that while the above query can easily be rewritten, there are cases (e.g. function calls) where the rewrite is not possible.

Interactions and Input

Cf. Element Construction vs Streaming

Cf. Functional Status of Comma

Proposed Resolution

XQuery should allow implementations to disallow attribute nodes that are specified after the first child node in the sequence. It should not allow disregarding them.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. The issue is resolved by the current text in section 3.7.4.1

If the content sequence contains an attribute node following a node that is not an attribute node, an error is raised. Attribute nodes occurring at the beginning of the content sequence become attributes of the new element node.

289. attribute-value-construction-from-elements: Attribute Value Construction from Elements

Issue Class: T Locus: xquery Cluster: constructor-expr Priority: 1 Status: resolved
Originator: Michael Rys

Description

What does XQuery do if assigning a list of element nodes to an attribute if the type of the attribute is not a list type?

Example:

<book isbn="{$i/booknum}" />:

This query implicitly gets rewritten to: <book isbn="{data($i/booknum)}" />

What happens if there are more than one booknum elements and ISBN is untyped or not a list type?

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Atomization is applied to generate the value assigned to the attribute and subsequent validation may detect errors. A static type error may be raised by this just as it may be raised by other uses of atomization.

Close issue no change to the documents.

290. element-attribute-constructor-name-type: Element Attribute Constructor Name Type

Locus: xquery Cluster: constructor-expr Priority: 1 Status: decided
Originator: Michael Rys

Description

Does the name expression on dynamically computed names in element/attribute constructors be of type QName without implicit cast from string, QName with implicit cast from string, or string?

Proposed Resolution

If the name is constructed by an expression, the expected type is xs:QName. Xs:string is in general implicitly cast to xs:QName (and xs:anyURI).

Proposed Resolution

(1) In Section 3.7.1 ("Direct Element Constructors"), modify the paragraph below the first example as follows:

"Unqualified element names used in a direct element constructor are implicitly qualified by the default namespace for element names. In a direct element constructor, the name used in the end tag must exactly match the name used in the corresponding start tag (including its prefix or absence of a prefix)."

(2) In Section 3.7.2.1 ("Computed Element Constructors"), add a new first paragraph as follows:

"The name expression of a computed element constructor is processed as follows:

1. If the name expression returns a QName, that QName is used as the name of the constructed element. If the QName returned by the name expression is unqualified, the name of the constructed element is in default namespace for element names.

2. If the name expression returns a string, that string is implicitly cast to a QName by using the fn:QName-in-context function with its $use-default parameter set to True. The resulting QName is used as the name of the constructed element.

3. If the name expression does not return a QName or a string, a dynamic error is raised."

(3) In Section 3.7.2.2 ("Computed Attribute Constructors"), add a new first paragraph as follows:

"The name expression of a computed attribute constructor is processed as follows:

1. If the name expression returns a QName, that QName is used as the name of the constructed attribute. If the QName returned by the name expression is unqualified, the name of the constructed attribute is in no namespace.

2. If the name expression returns a string, that string is implicitly cast to a QName by using the fn:QName-in-context function with its $use-default parameter set to True. The resulting QName is used as the name of the constructed attribute.

3. If the name expression does not return a QName or a string, a dynamic error is raised."

Actual Resolution

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)

Recommend Don's proposal as the closure of this issue.

291. element-construction-anySimpleType-sequence-content: Element Construction anySimpleType Sequence Content

Issue Class: T Locus: xquery Cluster: constructor-expr Priority: 1 Status: resolved
Originator: Michael Rys

Description

The current element construction treats sequences of anySimpleType values different from other simple typed values. This seems inconsistent. The document should make it clear why there is a difference. If there is a reason, is the reason good enough?

Actual Resolution

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)

The problem identified no longer exists in our documents. Michael Rys confirms this.

292. element-construction-sequence-vs-multi-expr: Element Construction Sequence vs Multi-expr

Locus: xquery Cluster: constructor-expr Priority: 1 Status: resolved
Originator: Michael Rys

Description

Which element construction rules cover

<e>{1, 2}</e>
vs
<e>{1}{2}</e>

Actual Resolution

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)

The problem identified no longer exists in our documents. Michael Rys confirms this.

293. cdata-charref-semantics: Cdata and CharRef Semantics

Locus: xquery Cluster: Priority: 1 Status: decided
Originator: Michael Rys

Description

The data model cannot represent CDATA or CharRef, since the Information Set looses this information.

Proposed Resolution

The XQuery document should make it clear that:

1. CDATA sections and CharRefs inside XQueries that are not embedded inside XML (which is what the XQuery document only talks about), are syntactic helps to write queries that otherwise would need entitization (in the case if CDATA sections) or a unicode input device (CharRefs).

2. Implementations can chose to use this information as serialization hints to preserve the CDATA and entitization.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Decided to close, with document changes as described by Mike Kay in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0095.html, including editorial comments.

294. type-annotations-on-all-elems-attrs: Should all elements and attributes have type annotations?

Issue Class: T Locus: xquery Cluster: type-semantics Priority: 1 Status: resolved
Originator: Philip Wadler

Description

Should all elements and attributes have type annotations? In particular, should a newly-constructed element or attribute have a generic type annotation such as "anyType", rather than the current proposal in which it has no type annotation at all? (This is largely a cosmetic issue, about whether "anyType" should be denoted by an explicit annotation or by the absence of an annotation.)

Interactions and Input

Cf. Type of a newly constructed element

Cf. Is the QName denoting type information optional or required?

Cf. Should all elements and attributes have type annotations?

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

This has been resolved by adoption of "pure named typing". All elements and attributes now have a type annotation. So, issue closed.

295. lexical-representation-of-atomic-values: Lexical Representation of Atomic Values

Locus: xquery Cluster: lexical-representation Priority: 1 Status: decided
Originator: xquery/xsl f2f

Description

The wording in section 2.8.3 needs to be aligned with Data model and F&O; 'lexical representation' needs to be defined differently and be consistent in XQuery, Datamodel, F&O. It probably needs to be string value (canonical value of integer in W3C Schema has a "." so not appropriate [or we need to have our own definition of the canonical value...]).

Actual Resolution

Decision by: xsl on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

3.7.2.4 "text node constructors", that's the one that should be aligned to "string-value".

296. definition-leading-slash: What is definition of leading "/"?

Locus: xpath Cluster: path-semantics Priority: 1 Status: resolved
Originator: XQuery Editors

Description

The current Working Drafts are inconsistent in their definition of a leading slash in a path expresion. A consistent definition needs to be developed.

Actual Resolution

Decision by: xpath-tf on 2002-07-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0455.html)

Decision by: xquery on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Decision by: xsl on 2002-07-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Aug/0101.html)joint f2f, decision missing from minutes confirmed

Leading "/" on a path expression means "root(self::node())": the root node of the tree containing the context item. Note that self::node() (and therefore leading "/") raises a dynamic error if the context item is not a node.

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.

297. binding: Should XPath have "type binding" in variable?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: XQuery Editors

Description

The 2002-06-24 grammar introduces the "binding" production. "assert" is removed from both XQuery and XPath. "binding" currently requires reserved words. Should "binding" be in XPath?

Several reasons NOT to include it in XPath:

- grammar

- semantics don't match function call semantics

- rarely useful

- reads oddly for range variables if (some integer $x in (1,2,"fred") satisfies $x=1)

- biggest of all, users are asking us to simplify. We will get a very adverse reaction if we make "for" expressions more complicated.

But it is worrying to have such a big split between XPath and XQuery.

Actual Resolution

Decision by: xpath-tf on 2002-11-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Nov/0187.html)

Decision by: xsl on 2002-11-14 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0044.html)

Decision by: xsl on 2003-01-09 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jan/0011.html)

Closed based on the XSLT recommendation to not include type declarations in XPath.

298. name-sequence-of-homogenous-types: Add Schema type names for sequences of homogeneous types?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: XPath TF

Description

Should we (or ask schema to) add Schema type names for sequences of homogeneous types?

If we add them now and Schema decide to add them later these would be different as the namespace for the type would be different...

Actual Resolution

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)

This is no longer needed following the adoption of "Alternative 1". Issue closed with no change to document.

299. character-reference-whitespace: Does character reference to whitespace change whitespace handling?

Locus: xquery Cluster: whitespace Priority: 1 Status: resolved
Originator: XPath TF

Description

In the whitespce proposal the treatment of whitespace character reference is different than treatment of literal whitespace (for "compatibility with XSLT/XPath 1.0") and this does not seem to align with XML parsing.

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Closed with no further changes to the documents.

Michael Kay states:

My belief is that the specs now state clearly what happens, and that the text describing what happens was properly reviewed and agreed, and that we should therefore close the issue.

It's true that the effect is still subtly different from the effect that you would get if you first put the query through an XML parser and then through an XQuery parser. But we've now made it very close, and unless we change our parsing model to do XML parsing first (before XQuery parsing), we will never achieve 100% alignment.

300. sorting-untyped-data: Should sorting of untyped data be prohibited?

Locus: xquery Cluster: sort Priority: 1 Status: resolved
Originator: XPath TF

Description

Should sorting of untyped data be prohibited? This would catch some user errors.

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

This issue is closed, as the definition of order-by clause converts untyped data to string.

301. basic-xquery-sql-xml-mappings: Supporting SQL/XML mappings in Basic XQuery

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Must Basic XQuery support the SQL/XML mappings? One of the original purposes for Basic XQuery was support for mapping relational data, but the SQL/XML mappings would not be allowed as data in the current definition of Basic XQuery, because they contain (a) user-derived simple types, and (b) named complex types, which would result in type annotations in our data model. Since SQL/XML is the only proposed standard for relational mappings, do we need to ensure that we support it in Basic XQuery?

Actual Resolution

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)

Decided to accept status quo: it does.

302. arbitrary-documents-types: Support for arbitrary XML documents

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Must it be possible to query arbitrary XML documents with Basic XQuery?

Actual Resolution

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)

Decided to accept status quo: yes.

303. scale-down-type-mappings: Define "scale-down" mappings?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

The Data Model document defines mappings from the PSV Infoset. If we decide it is essential to query arbitrary XML documents with Basic XQuery, should we define interoperable mappings that would create a representation that has no named types other than built-in XML Schema types? For instance, we might state Basic XQuery implementations map user-derived types to the nearest built-in type, do not create type annotations for named complex types.

Actual Resolution

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)

Decided to accept status quo: it should.

304. declare-required-conformance-features: Declare required conformance features?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

Should there be a way to declare in the Query Prolog which conformance features are required for processing a given query?

Actual Resolution

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)

Decided to close the issue with no change: no facility required.

305. conformance-prerequisites: Schema Import Feature prerequisite for Static Typing Feature?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

Should the Schema Import Feature be a prerequisite for the Static Typing Feature? Mike Kay has observed that this is not technically necessary.

Actual Resolution

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)

Decided that these are independent. Issue closed with no change to document.

306. PSVI-Data-Model-mapping-normative: PSVI to Data Model mapping part of normative text?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

Should the mapping from PSVI to Query Data Model be part of the normative language specification? (The mapping is affected by the presence or absence of the Schema Import Feature).

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Close issue: mapping already exists and is Normative).

Decision by: xquery on 2003-10-01 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0005.html)Joint telcon

Decision by: xsl on 2003-10-01 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0005.html)Joint telcon

The normativity of the mapping (and noting that it is only ONE of the ways in which a datamodel can be constructed) is reaffirmed and some adjustments to the text in the Datamodel approved.

307. schema-types-from-input-documents: Schema Types from input documents?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: Don Chamberlin

Description

During the analysis phase, in-scope schema definitions are derived from schemas named in Schema Import clauses.

Should there be additional in-scope schema definitions that are part of the static context? Should there be another set of in-scope schema definitions that are part of the dynamic context? What would that do to static typing? Would this interfere with interoperability?

In particular:

1. Should an environment be allowed to statically predefine schema definitions for a query? This would allow queries on fixed collections or known message types to provide strong type information without forcing users to explicitly import the corresponding schemas.

2. How does type information found dynamically in queried documents affect the query environment?

Does data() dynamically use the type information found in the instances that are queried, even when the types have not been declared in imported schemas? Note that Basic XQuery does not work properly if this is not true, since it must be able to discover the types of elements without importing their definition.

May an instance contain types that have not been imported into the static environment? If we say it may not, then schema imports are needed to query any document that contains types that are not predefined in XQuery.

May documents that are queried have different definitions for the same names? Note that solutions that dynamically load type information from a document into the in-scope schema definitions may try to introduce all such definitions into the static environment, which should cause an error according to our current rules.

Proposed Resolution

If we want Basic XQuery to be able to query documents that have types that are not predefined, then data() must be able to use type information from instances. But if we want to be able to query validated documents that have different schemas this information must not be added to the static environment (or else we must find a way to add more than one schema definition for a given name to the static environment, or say that the static environment is dynamic, or....).

My tentative conclusions:

1. The in-scope schema definitions should be determined statically.

2. data() and many operators must be able to utilize the type information found in a document.

3. As a matter of convenience, it should be possible to import the schemas associated with a single document or with all documents in a collection. For instance, a syntax like the following may be useful:

import schema from collection
"jdbc:datadirect:sqlserver://localhost:1433;database='airports'"

or

import schema from document
"file:///C:/projects/query/requirements/xml-spec.xsd"

4. Implementations should be allowed to implicitly import schemas into the environment before executing a query, using any of the approved ways above.

Proposed Resolution

Proposal (3): Types in Queries, Types in Documents

This proposal distinguishes the relationship between types known statically in the query and types that are discovered dynamically in documents during query processing. This version of the proposal follows the results of a telcon on the subject, as recorded in:

Re: Issue 307 Telcon: Friday, 15 Nov, 12:00 EST From: Jonathan Robie (jonathan.robie@datadirect-technologies.com) Date: Fri, Nov 15 2002 http://lists.w3.org/Archives/Member/w3c-query-editors/2002Nov/0148.html

This proposal addresses the following issue:

Issue 307 schema-types-from-input-documents: Schema Types from input documents?

And here is the proposal itself:

1. Static Types in Queries

Implementations are allowed to implicitly import schemas into the environment before executing a query. The in-scope schema definitions are determined statically, containing the built-in type definitions, any schemas imported explicitly into the query, and any schemas imported implicitly from the query environment.

In a query, it is a static error to use a name in a SequenceType production if the name is not found in the in-scope schema definitions.

2. Types in Input Documents

An input document may be accessed via an input function or via an externally defined variable that is bound to the input document by the query environment. An input document may refer to type names that have not been imported into the in-scope schema definitions, but it must not contain types that have the same names as types in the static environment, but conflicting definitions. Input functions and the query environment must promote unknown type names to the nearest type name in the in-scope schema definitions that is known to be substitutable for the unknown type name. If the unknown type name is derived from a known type by extension, list, or union, then the type name is changed to xs:anySimpleType if it is a simple type, or to xs:anyType if it is a complex type. This loses type information, but ensures that all type names in input documents are also in the in-scope schema definitions.

Note: This approach guarantees that the built-in types and the static in-scope-schema definitions are the only types found in an input document. As a result, there is no need to extend the known types when a new document is read.

Note: One ramification of this approach is that types derived by extension are not substitutable for their base types unless the schemas defining these types are imported into the query. We consider this a fair tradeoff for type safety. If people want to exploit the full type hierarchy, they need to import the schema that defines it.

Note: Mapping all the types when an input function is called is obviously an inefficient implementation strategy. Many implementations will take a different approach, but this is a simple way to specify the desired behavior.

Actual Resolution

Decision by: xquery on 2002-12-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0167.html) Proposal (3) accepted.

Decision by: xpath-tf on 2003-03-25 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0326.html) Revoke resolution of Issue 307. Type annotations are not "dumbed down".

Decision by: xsl on 2003-09-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0039.html)Joint telcon

Decision by: xquery on 2003-09-10 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0039.html)Joint telcon

Modified "Winged Horse" proposal accepted.

Decision by: xquery on 2003-09-15 (http://www.w3.org/XML/Group/2003/09/toronto-minutes.txt)Joint face to face

Decision by: xsl on 2003-09-15 (http://www.w3.org/XML/Group/2003/09/toronto-minutes.txt)Joint face to face

Reaffirming decision and amending the text slightly as recorded in RE: Revised Issue 307 Usage Scenarios for Today's Call and adding a one sentence clarification as per RE: Revised Issue 307 Usage Scenarios for Today's Call.

308. type-soundness: Type Soundness

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: Don Chamberlin

Description

The Static Typing Feature is claimed to have a property called "type soundness." However, Dana says she has counterexamples to the claim of type soundness as described in this section (Section 2.4.2.3). (At least sequence type matching breaks TYPE SOUNDNESS so what else breaks it?) We need to examine the claim and make sure it is stated correctly.

Actual Resolution

Decision by: xpath-tf on 2002-11-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Nov/0187.html)

Decision by: xsl on 2002-11-14 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0044.html)

Decision by: xsl on 2003-01-09 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jan/0011.html)

Closed due to the definition of type errors in language and FS books.

309. type-error-value: What should be the type of an error value?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

What should be the type of an error value? Section 2.4.3 says that it can be one item. Some people think it should be more flexible (any sequence of items), and other people think it should be less flexible (an item of a particular type). Some people think it should be an element with a well-defined structure.

Actual Resolution

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)

Decided to accept status quo: Since an error item may be any item, that's the type.

310. type-annotations-child-of-element: Are the children of a newly constructed element typed?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: decided
Originator: Dana F

Description

What happens with the type annotation of the children of a newly constructed element? Type annotation kept or given xs:anyType.

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

Decision to accept the propsal of Phil Wadler in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0378.html.

Decision by: xquery on 2003-01-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0502.html)

Decided to reopen the issue.

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)

Decided NOT to reopen the issue.

311. whitespace-attribute-constructors: Whitespace and Attribute Constructors

Locus: xquery Cluster: whitespace Priority: 1 Status: decided
Originator:

Description

Whitespace in an XSLT attribute value template is significant insofar as it survives the XML rules for normalization of attributes. This means that CRLF combinations and tabs are normalized to x20 spaces, unless they are written as XML character references. I think it's an open question whether XQuery wants to emulate the XML attribute normalization rules.

In XSLT,

<foo bar="
   {'x'}
"/>

will produce the result <foo bar=" x "/>

while <foo bar=" "/> produces an element containing an attribute whose value is a single CR character.

If XQuery wants to reproduce this behavior exactly, then it's going to have to reproduce the XML treatment of whitespace as well as the XSLT treatment.

But whether it does so or not, I think Mary is right that

<foo bar=" {'x'} "/>

should produce lt;foo bar=" x "/> and not <foo bar="x"/>. There is a difference between element and attribute constructors: attributes have quotes around them, and this sets a different expectation.

Actual Resolution

Decision by: xquery on 2002-12-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0167.html)

Confirmed that Mary's proposal for whitespace, that was accepted 2002-11-27, closes this issue.

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Resolved by the recent adoption of the revised text on attribute constructors.

312. list-types: What to do about list types?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: resolved
Originator: XQuery WG

Description

Merged section on errors and conformance: What to do about list types?

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Close issue no change to the documents.

313. union-types: What to do about union types?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: resolved
Originator: XQuery WG

Description

Merged section on errors and conformance: What to do about union types?

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Close issue no change to the documents.

314. schema-import-basic-xquery: Partial support for SCHEMA IMPORT in Basic XQuery?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: subsumed
Originator: XQuery WG

Description

Merged section on errors and conformance: Partial support for SCHEMA IMPORT in Basic XQuery?

Clarification of issue: Basic XQuery implementations might want to add its own predefined types to the static context, but cannot do so given the current definition.

Actual Resolution

Subsumed by :conformance-levels.

315. whitespace-in-names: Whitespace allowed in the name of a variable!

Locus: xpath Cluster: syntax Priority: 1 Status: resolved
Originator: Dana

Description

The current Xquery/Xpath grammar allows a whitespace in between the '$' sign and the rest of the name of the variable. This should be forbidden.

Actual Resolution

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)

Decided to continue permitting space. Issue close with no change to document.

316. cardinality-typed-comparison: Is anySimpleType = anySimpleType*?

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: Michael Rys

Description

Given the following function:

define function foo(xs:anySimpleType $x) returns xs:anySimpleType {$x}

and the untyped data

<a a="1"/><a a="2"/><a a="3"/>

should the following be a (static or dyamic) type error or should it work?

foo(/a/@a)

If it should work, what should the following query return?

count(data(<e>1 2</e>))
count(data(<a b="1 2"/>/@b))

Should it be 1 or 2?

Proposed Resolution

anySimpleType is the base type of all the *primitive* XML Schema datatypes.

List and union types are *generated* (my word, Schema uses the word *derived*) from primitive types and thus, not included in anySimpleType. See the extract from the XML Schema datatypes spec below.

"[Definition:] There exists a conceptual datatype, whose name is anySimpleType, that is the simple version of the ur-type definition from [XML Schema Part 1: Structures]. anySimpleType can be considered as the *base type* of all *primitive* types. The *value space* of anySimpleType can be considered to be the *union* of the *value space*s of all *primitive* datatypes."

Thus, the function call above should result in a (static or dynamic, depending on typing conformance) type error.

The count expressions would always return 1.

Actual Resolution

Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0252.html)

Decided that anySimpleType is a list one. This needs to be carried out clearly in the documents.

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

To solve issues 316 and 524 we need to do eliminate three constructor functions from F&O, and integrating with the changes described in the message: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0021.html.

This was agreed.

317. extension-mechanism: XQuery Extension Mechanisms

Locus: xquery Cluster: extensions Priority: 1 Status: decided
Originator: Andrew Eisenberg

Description

Issue: XQuery has not determined what extension mechanisms might be supported. XQuery may support the following:

  • implementation-defined extensions to the XQuery grammar
  • an XQuery-flagger that identifies extensions to XQuery 1.0
  • implementation-defined extensions to the functions that are available to
  • an XQuery author. The author would be required to explicitly declare the
  • namespaces of any extension functions that are used

Interactions and Input

Cf. We need a way to declare external functions

Cf. External Objects

Cf. Can (and should) keyword extensions be allowed in XQuery by equipping them with a namespace prefix?

Proposed Resolution

This proposal adds the following to the XQuery language document (in
section 2.5 Errors and Conformance):


2.5.5 Extensions

Conforming XQuery implementations are permitted to make two different kinds
of extensions to the specifications: grammar extensions and semantic
extensions. There are two types of grammar extensions: pragmas and
must-understand extensions. While an XQuery implementation may support some
or all of these types of extensions, this does not negate the requirement
to support the XQuery functionality defined in this specification.


2.5.5.1 Pragmas

A pragma may be used to provide additional information to an XQuery
implementation.

[x1]  Pragma            ::=   "(::" "pragma" PragmaQName PragmaContents
"::)"

[x2]  PragmaQName       ::=   ExplicitQName

[x3]  ExplicitQName     ::=   QName

[x4]  PragmaContents    ::=   .*

An ExplicitQName requires that QName contain a Prefix. Pragmas may be used
anywhere that ignorable whitespace is allowed, and within element content.
See A.1 Lexical structure for the exact lexical states where pragmas are
recognized. A pragma is identified by its PragmaQName.

If an implementation does not support a pragma, then that pragma shall be
ignored. If an implementation does support a pragma and the implementation
determines that the PragmaContents are invalid, then a static error is
raised. Otherwise, the effect of the pragma on the result of the Query is
implementation-defined.

The following example shows how a pragma might be used:

   declare namespace exq = "http://example.org/XQueryImplementation"

   (:: pragma exq:timeout 1000 ::)

   count(input()//author)

An implementation that supports the exq:timeout pragma might raise a
dynamic  error if it is unable to count the authors within 1000 seconds. An
implementation that did not support this pragma would execute as long as
necessary to count the authors.


2.5.5.2 Must-Understand Extensions

An implementation may extend the XQuery grammar by supporting
must-understand extensions.

[y1]  MustUnderstandExtension ::=
            "(::" "extension" ExtensionQName ExtensionContents "::)"

[y2]  ExtensionQName          ::=   ExplicitQName

[y3]  ExtensionContents ::=   .*

A MustUnderstandExtension may be used anywhere that ignorable whitespace is
allowed, and within element content. See A.1 Lexical structure for the
exact lexical states where pragmas are recognized. A must-understand
extension is identified by its ExtensionQName.

If an implementation does not support a must-understand extension, then a
static error is raised. If an implementation does support an
must-understand extension and the implementation determines that the
ExtensionContents are invalid, then a static error is raised. Otherwise,
the effect of the must-understand extension on the result of the Query
being executed is implementation-defined.

The following example shows how a must-understand extension might be used:

   declare namespace exq = "http://example.org/XQueryImplementation"

   for $e in doc("employees.xml")//employee
   order by $e/lastname (:: extension exq:RightToLeft ::)
   return $e

An implementation that supports the exq:RightToLeft must-understand
extension might order the last names by examining characters from right to
left instead of left to right. An implementation that did not support this
must-understand extension would raise a static error.


2.5.5.3 Semantic Extensions

An implementation may extend XQuery by supporting semantic extensions. A
semantic extension allows a conforming Query to be processed in a
non-conforming way. The way in which such semantic extensions are enabled
is implementation-defined.

The effect of a semantic extension on the result of a Query is
implementation-defined.

The following example shows how a command line might be used to enable a
semantic extension:

   xquery q12.xquery
   98

   xquery q12.xquery -EmptyIdentity=on
   100

The execution of the query contained in q12.xquery might treat an empty
sequence as 0 when it is being used in addition and subtraction and treat
it as 1 when it is being used in multiplication and division.


2.5.5.4 XQuery Flagger

An XQuery Flagger is a facility that is provided by an implementation that
is able to identify queries that contain extensions other than pragmas. If
an implementation supports extensions other than pragmas, then an XQuery
Flagger must be provided. The XQuery Flagger is disabled by default; the
mechanism by which the XQuery Flagger is enabled is implementation-defined.
When enabled, the XQuery Flagger will raise a static error for an otherwise
valid Query that contains either must-understand extensions or semantic
extensions.

An XQuery Flagger is provided to assist programmers in producing queries
that are portable among multiple conforming XQuery implementations.

The following examples show how an XQuery Flagger might be used:

   xquery q10.xquery
   <employee> ... </employee>

   xquery q10.xquery -Flagger=on
   [static error] A must-understand extension is being used:
   exq:RightToLeft

   xquery q12.xquery -EmptyIdentity=on
   100

   xquery q12.xquery -EmptyIdentity=on -Flagger=on
   [static error] A semantic extension is being used: EmptyIdentity

Updates to proposal:

- Usage of (:: ::) syntax.

- must-understand extension.

Actual Resolution

Decision by: xquery on 2003-03-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0232.html)

#1 PRAGMAS: Adopted Unanimously.

#2 MUST-UNDERSTAND EXTENSIONS: Adopted.

#3 SEMANTIC EXTENSIONS: Rejected.

#4 FLAGGER: Adopted.

318. sort-in-FLWR: Add 'order by' clause to FLWR?

Locus: xquery Cluster: sort Priority: 1 Status: decided
Originator: Jonathan Robie

Description

Four issues were raised in a proposal to restructure sorting in XQuery [1]:

1. Should we add an 'order by' clause to FLWR?

The following syntax has been proposed:

FLWRExpr ::= (ForClause |  LetClause)+ SortClause? WhereClause?
"return"  Expr
OrderClause ::=  "order by" stable? SortSpecList
SortSpecList ::= Expr SortModifier ("," SortSpecList)?
SortModifier ::= ("ascending" |  "descending")? ("empty" "greatest"
|  "empty" "least")?

The OrderClause sorts the tuple stream based on the conditions specified in the SortSpecList.

In the status quo, 'sortby' is a standalone postfix expression. FLWR is used to iterate, and 'sortby' is used to sort. This causes certain difficulties, because iteration and sorting are not distinct, unrelated operations - in general, the order in which the output sequence is ordered determines the best order to choose when iterating over the input.

When sorting data created with element constructors, it can sometimes be quite tricky to determine the original source of data in a constructed element. The more complex the expressions that construct the element, the more tricky this becomes. It is also tricky to iterate in an order determined by data that is not returned in a generated sequence.

If we add this clause, should a FLWOR expression that contains an OrderClause but no ForClause result in a semantic error, since there is no tuple stream to sort?

2. If we add an 'order by' clause, should we keep the sortby() expression, or remove it from our language?

Keeping it is convenient for some expressions. Removing it leaves us with a simpler language, and does not require us to explain to our users why we have two ways of doing the same thing.

3. How should we formalize 'order by' - or should we formalize it in Version 1.0?

The most straightforward way to formalize 'order by' is to use tuples, which do not exist in our Data Model, and these would cause significant change to our Formal Semantics. However, the semantics of 'order by' are straightforward.

Our options seem to be:

3.a. Ensure that we know how it would be formalized using tuples, but postpone including this in the Formal Semantics until after Version 1.

3.b. Refuse to add the feature unless it can be formalized with our current Data Model.

3.c. Restrict the feature to functionality easily formalized with our current Data Model.

I believe there was significant enthusiasm for 3.a. in today's telcon.

4. Is the 'order by' clause part of the XPath spec, or is it only in XQuery?

Jonathan

[1] http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Jul/0177.html

Interactions and Input

Cf. Sorting by Non-exposed Data

Actual Resolution

Decision by: xpath-tf on 2002-10-16 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0278.html)

'order by' has been added.

319. namespace-definitions-and-validate: Namespace definitions and in-scope namespaces

Locus: xquery Cluster: namespaces Priority: 1 Status: decided
Originator: XPath TF

Description

Addition of namespaces in the query prolog to the in-scope namespaces; how is this information carried through to provide input to validation?

Additional aspecs are:

(a) the whole question of how the namesapce context is affected by namespace declarations in element constructors

(b) the general notion (in XQuery, specifically), that the static context can vary for different parts of a query

(c) what information gets through to act as input to validation

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decided to accept the "Processing Model" Proposal which addresses this issue.

320. types-conformancelevels-same-results: Should different conformance levels give the same result for the same query and data?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: decided
Originator: Anders Berglund

Description

Are different conformance levels going to give the same results? Is it possible to get different results for the same query? The principle should be that you either get the same result or a failure. Currently this isn't the case.

Interactions and Input

Input from Anders Berglund:

Input from Kristoffer Rose:

Cf. Schema Import, Static Typing: what is interoperable?

Cf. Optional Features vs. Conformance Levels

Actual Resolution

Decision by: proc-mod-tf on 2003-02-11 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Feb/0110.html)

Decision by: xquery on 2003-02-19 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0404.html)

Given that types add semantics, there is no way to achieve the proposed principle between basic XQuery and schema import without adding additional specification in the query.

It is decided not to add any such functionality and close this issue without action.

321. validate-lax-strict: Is validate strict or lax?

Locus: xquery Cluster: validate Priority: 1 Status: decided
Originator: XSL/XQuery joint

Description

Does "validate" do strict or lax validation?

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

Decision to accept the propsal of Phil Wadler in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0378.html.

322. validate-lax-strict-override: "validate" strict/lax override?

Locus: xquery Cluster: validate Priority: 1 Status: decided
Originator: XSL/XQuery joint

Description

Should the user should be able to override which type (strict/lax) of validation "validate" does?

Actual Resolution

Decision by: xquery on 2002-12-18 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0167.html)

Decision to accept the propsal of Phil Wadler in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0378.html.

323. unordered-in-xpath: Should "unordered" be included in XPath?

Locus: xpath Cluster: Priority: 1 Status: resolved
Originator: XSL/XQuery joint

Description

Should "unordered" keyword be included in XPath? It does cause problems with the grammar (keyword issue).

Actual Resolution

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

It is a function and already included in F&O.

324. variables-external: How can variables be bound external to XQuery itself?

Locus: xquery Cluster: variables Priority: 1 Status: resolved
Originator: XSL/XQuery joint

Description

How can variables be bound external to XQuery itself (e.g. like parameters to the query)?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Resolved by action at Chapel Hill and reflected in current document.

325. element-def-not-in-in-scope: Refering to element that is not in the in-scope schema def.

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: XQuery

Description

In recent discussions on the type system and when reviewing the documents I noticed that many people interpret

element foo

differently than the spec indicates it needs to be interpreted. This seems to indicate that we have a problem.

The semantics that people expect seems to be:

element foo is the same as element foo of type xs:anyType and matches all elements with the given name (regardless where or whether the element was declared in the schema).

attribute foo is the same as attribute foo of type xs:anySimpleType and matches all attributes with the given name regardless where or whether it was declared in the schema).

However our spec [1] says:

Another form of ElemOrAttrType is simply a QName, which is interpreted as the required name of the element or attribute. The QName must be an element or attribute name that is found in the in-scope schema definitions. The match is successful only if the given element or attribute has the required name and also conforms to the schema definition for the required name. This can be verified in either of the following ways:

If the schema definition for the required name has a named type, the given element or attribute must have a type annotation that is the same as that named type or is known (in the in-scope schema definitions) to be derived from that named type. For example, suppose that a schema declares the element named location to have the type State. Then the SequenceType element location will match a given element only if its name is location and its type annotation is State or some named type that is derived from State.

If the schema definition for the required name has an anonymous (unnamed) type definition, the actual content of the given element or attribute must structurally comply with this type definition. For example, suppose that a schema declares the element named shippingAddress to have an anonymous complex type consisting of a street element followed by a city element. Then the SequenceType element shippingAddress will match a given element only if its name is shippingAddress and its content is a street element followed by a city element.

The constraint that an element must have a required name is considered to be satisfied if the element has been validated and found to be a member of a substitution group whose head element has the required name. Substitution groups are described in [XML Schema].

which seems to indicate that this is not the case.

I would like to open an issue on this. I think even if people do not want to use schema types, they may still want to restrict the argument type of a function to an element with a given name.

In addition, many people are surprised to see the SchemaContext in the SequenceType production for other usages than for validate in ...

While there is a use case, I wonder whether this needs to be a required feature for XQuery V1 given the leap in complexity. Maybe it would be useful to solve the above problem by saying that you have to use

element foo in /

to force the name to be in the in-scope schema definition? This would mean that / becomes allowed in the SchemaGlobalContext production.

Actual Resolution

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

In sequence type it is an error, it is valid in a path expression.

326. require-type-definition: Semantics of element foo of type T

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: subsumed
Originator: XQuery

Description

When using the form 'element foo of type T', should 'foo' be a globally declared element in the in-scope schema or not? Should there be constraints on which type T is allowed? The language document assumes foo is globally declared and T is a restriction of the type of foo. The formal semantics does not make that assumption.

Actual Resolution

Decision by: xsl on 2003-01-09 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jan/0011.html)

Subsumed by element-def-not-in-in-scope.

327. functions-parameter-evaluation: Evaluate unused function parameters?

Locus: xpath Cluster: functions Priority: 1 Status: decided
Originator: XSL/XQuery joint

Description

Is an implementation obligated to evaluate all its parameters (and raise any errors doing so) even when they're not needed in the function body?

Actual Resolution

Decision by: xpath-tf on 2002-10-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0449.html)as part of Agendum 1.

There is no need to evaluate "non needed" expressions.

Decision by: xquery on 2002-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0511.html)accepting text for next publication, but keep issue active.

Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)accepting text for next publication, but keep issue active.

Decision by: xpath-tf on 2003-03-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0232.html)

No adverse public comments received. Close issue with no change.

328. cdata-section: What does CDATA section constructor construct?

Locus: xquery Cluster: cdata section Priority: 1 Status: decided
Originator: Michael Kay

Description

Section 3.7.5 describes CDATA section constructor, but these cannot be represented in the data model.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Decided to close, with document changes as described by Mike Kay in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0095.html, including editorial comments.

329. duplicate-attribute-constructors: Duplicate attribute constructors

Locus: xquery Cluster: constructors Priority: 1 Status: decided
Originator: Michael Kay

Description

If there are multiple constructors for the same attribute on an element; which one is taken or is it an error?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Decided to make it an error for an element constructor to specify two attributes with the same name. Error to be documented in XQuery Section 3.7.4.1.

330. some-filter-on-type: Should "some" do type filtering?

Issue Class: T Locus: xquery Cluster: types Priority: 1 Status: resolved
Originator: Michael Kay

Description

Currently "some" doesn't do any filtering, which seems unnatural. We could change the some behaviour to actually do the type filtering.

It is easy to imagine that "some hatsize $h in $seq satisfies $h=3" ignores items in $seq that are not hatsizes. Currently, of course, it causes an error if the sequence might contains things other than hatsizes.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Decided to close with no change to documents.

331. static-dynamic-dispatch: Static vs. dynamic dispatch for arithmetics

Issue Class: T Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Dana Florescu

Description

The current XPath/XQuery specification, as well as the Formal semantics document, mandate that the specific arithmetic operation to be executed depends on the runtime type of the arguments. For example, the addition of two variables $x and $y will be executed as an integer addition if the dynamic types of the two values are both subtypes of integer, and does not depend on the static type of the variables $x and $y (which may be decimal).

Implementing this semantics requires a runtime dispatch plus an runtime interaction with the type system for subtype testing. This can be very costly. Moreover, this semantics can prohibit other useful compile time optimizations like index utilization.

We may allow implementations to use either a static or dynamic dispatch for arithmetic operations in order to improve performance.

Actual Resolution

Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0259.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

The cost is not currently believed to be real. Decided to close with no action (ie keeping dynamic dispatch).

332. schema-import-static-typing-interoperable-results: Schema Import, Static Typing: what is interoperable?

Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: XPath TF

Description

What interoperability is expected for queries that are executed with and without Schema Import? Does the current text reflect the desired goals?

What interoperability is expected for queries that are executed with and without Static Typing? Does the current text reflect the desired goals?

Interactions and Input

Input from Phil Wadler:

Cf. Should different conformance levels give the same result for the same query and data?

Cf. Optional Features vs. Conformance Levels

Actual Resolution

Decision by: proc-mod-tf on 2003-02-11 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Feb/0110.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)Second question.

First question is related to 320. See 320 for resolution.

Second question boils down to the question whether static typing allows to change the result or only can raise a static error. We already follow the principle to not change results except by raising a static error.

Decided to point to this principle as the resolution and close the issue without changes to the documents.

333. optional-features-vs-conformance-levels: Optional Features vs. Conformance Levels

Locus: xpath Cluster: conformance Priority: 1 Status: subsumed
Originator: XPath TF

Description

Should "Schema Import" and "Static Typing" be independent, optional features or should there be a layer of conformance levels? For XQuery the latter might be "Basic XQuery", "Basic XQuery" + "Schema Import", and "Basic XQuery" + "Schema Import" + "Static Typing".

Interactions and Input

Cf. Should different conformance levels give the same result for the same query and data?

Cf. Schema Import, Static Typing: what is interoperable?

Actual Resolution

Subsumed by :conformance-levels.

334. xquery-failed-validation: How are documents for which validation has failed processed?

Issue Class: T Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: Jonathan Robie

Description

What is the result of a failed validation? Can you inspect the result to detect this? Do you just get anySimpleType and anyType?

Interactions and Input

Cf. Support for schema-less and incompletely validated documents

Cf. input(), collection(), document(); validation semantics

Actual Resolution

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

Access to documents that fail validation is not supported.

335. semantics-interfering-with-optimization: XPath/XQuery's current semantics greatly interferes with optimization

Locus: xpath Cluster: formal-semantics Priority: 1 Status: decided
Originator: Michael Rys

Description

Current semantics basically defines the semantics by mapping FLWRs and path expression to go top-down. Errors are normative. Problem is that we can not apply many optimizations. Simple query rewrites such as pushing or pulling filters, etc. Like to be able to push predicates down and evaluate them. Potentially the predicate might raise an error you would not have gotten if you processed top down. Want to allow implementations to do bottom up evaluations.

Suggested resolution:

The formal semantics defines dynamic evaluation in terms of a naive, top-down reduction of a core expression to a data-model value. Implementations may choose alternative evaluation strategies, which, for example, may reduce a core expression bottom-up. If an evaluation of a core expression yields a value (i.e., it does not raise an error), the value must be the same value as would be produced by the dynamic semantics defined in this document. The evaluation of a core expression may raise an error that may not be raised by the dynamic semantics as defined in this document.

Actual Resolution

Decision by: xpath-tf on 2002-10-29 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Oct/0449.html)as part of Agendum 1.

Expressions, with the exception of "if", may be reordered and thus some errors may be raised that using another evaluation strategy may not have occurred.

Decision by: xquery on 2002-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Oct/0511.html)accepting text for next publication, but keep issue active.

Decision by: xsl on 2002-10-31 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2002Nov/0004.html)accepting text for next publication, but keep issue active.

Decision by: xpath-tf on 2003-03-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Mar/0232.html)

No adverse public comments received. Close issue with no change.

336. error-decide-on-markup: Markup in documents for errors

Locus: all Cluster: editorial Priority: 1 Status: postponed
Originator: XPath TF

Description

The editors need to agree on the markup to be used for errors in the documents. Some markup is currently used in the XSLT spec.

337. error-add-markup: Add markup in documents for errors

Locus: all Cluster: editorial Priority: 1 Status: postponed
Originator: XPath TF

Description

The markup for errors to be added to the documents.

338. whitespace-character-reference: Handling of whitespace and character references

Locus: xquery Cluster: whitespace Priority: 1 Status: decided
Originator: Michael Kay

Description

The effect of CharRef in Element or Attribute content is underspecified. For example, if the value of the CharRef is whitespace, does it behave like whitespace in Element or Attribute content, or does it behave like ordinary characters? Either way, it is hard to make it behave exactly like the XML construct that it mimics: in XML, a character reference such as suppresses certain effects such as whitespace normalization. It is not clear whether such normalization happens in XQuery.

Interactions and Input

Cf. How to get quotes etc in string literals?

Cf. Cdata and CharRef Semantics

Actual Resolution

Decision by: xquery on 2002-12-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0167.html)

Confirmed that Mary's proposal for whitespace, that was accepted 2002-11-27, closes this issue.

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Resolved by the recent adoption of the revised text on attribute constructors.

339. element-attribute-construction-order: Error type for attributes constructed too late

Locus: xquery Cluster: errors Priority: 2 Status: decided
Originator: Don Chamberlin

Description

What kind of error should be raised by an element constructor in which an attribute is encountered after other element content?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

This a type error. Type error to be documented in XQuery Section 3.7.2.

340. errors-unique-identification: How to identify errors?

Locus: xpath Cluster: errors Priority: 1 Status: decided
Originator: XPath TF

Description

How should we allocate codes or identifiers to errors defined in the spec? We should not use "explanatory sentences" as these are not appropriate for I18N reasons.

Actual Resolution

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

(not really an issue); Ashok and Norm will investigate whether we can editorially markup errors consistently.

Decision by: xpath-tf on 2003-01-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0101.html)

Issue should remain open pending proposal on: ACTION XPATH-091-11 Mary adds herself to XPATH-091-11.

Decision by: xpath-tf on 2003-04-08 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Apr/0075.html)

1. All occurrences of static and dynamic errors should be identified in the F&O, DM, language, and FS specs using distinguished error markup.

2. Error markup should include unique alpha-numeric identifier for each error which permits the source to refer to unique error definitions and to include reverse indices on errors.

3. In first cut, alpha-numeric error codes will not be revealed in printed documents, but we can reveal them at a later time if we decide to make error codes part of conformance requirements.

4. Until we consider an API for conveying errors to the evaluation environment, we recommend *not* requiring implementations to return specific error codes (and possibly additional context info such as location of error in query body or name of built-in function, etc.)

Decision by: xquery on 2003-04-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0247.html) with amendment: instead of tying the codes to conformance, we are suggesting to publish these in a non-normative appendix so implementers can use them if see fit

Decision by: xquery on 2003-04-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0007.html)

The XML Query WG has agreed that errors be identified with a code and and some English text as recommended by the I18N folks. The XSL WG has not discussed this yet.

The markup suggested for errors:

        <error id="code> English text </error>

seems fine, but we need to decide how to assign the codes.

Jim Melton suggessted 5 or 6 digit fixed length codes partitioned in some manner to indicate the type of error: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0259.html

Liam Quin suggested words separated by hyphens: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0267.html

Mike Kay would like them to be QNames: unprefixed in the case of codes defined by W3C, namespace-prefixed in the case of implementation-defined or user-defined codes. See http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0284.html

SUGGESTION ON HOW TO MOVE FORWARD Since the error codes will encompass the language documents, the F&O and possibly the formal semantics we need folks representing all these constituencies to decide on the structure of the error codes and how to partition them. I suggest a small task force to address this. This taskforce would also address the issue of the non-normative appendix and where it should reside.

341. SequenceType-problems: Problems with SequenceType

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: Michael Kay

Description

Using the "instance of SequenceType" construct within a predicate of a path expression, or in an XSLT match pattern, is very unwieldy: the verbose English-like syntax of a SequenceType does not go well with the terse syntax of path expressions, leading to inelegant constructs like

select="//*[.instance of element of type address]"

Interactions and Input

Input from Michael Kay:

Proposed Resolution

1. Motivation

Many people have asked for the ability to test for elements of a given
type in path expressions, and to be able to write path expressions
that would retrieve nodes with types that match the declared types of
function parameters. For instance, consider the following query in the
syntax of our current Working Draft:

       define function name($e as element person)
         returns element name
       {
            $e/name
       }

       for $p in input()//person
       return name($p)

This query can fail at runtime, because the path expression matches
any element named person, and the function parameter requires a valid
element conforming to a globally declared element named person.

This proposal adds ElementType and AttributeType nodetests to path
expressions, and aligns the syntax of SequenceType with the syntax of
type tests done in path expressions. For instance, in the following
syntax, the KindTest "element(person)" matches only person elements
that are valid instances of the globally declared person element, and
the same test is used for the function's parameter type:

       define function name($e as element(person))
         returns element name
       {
            $e/name
       }

       for $p in input()//element(person)
       return name($p)

Using the same syntax and semantics for these tests in both path
expressions and SequenceType ensures that they are well aligned, and
reduces the number of expressions users of the language must learn. In
addition, it allows us to fix some problems with SequenceType that
have made the grammar complex to maintain.

ElementType and AttributeType nodetests also allow the names of types
to be used to select nodes, eg:

       define function name($e as element(person, surgeon))
         returns element name
       {
            $e/name
       }


       for $p in input()//element(person, surgeon)
       return name($p)

Or:

      for $date in input()//element(*, xs:date)
      return <date>{ $date }</date>

Note that the above queries provide enough type information to be
statically valid without 'treat as'. If a NameTest were used instead
of the ElementType nodetest, the above query would not be statically
valid, and the query writer would need to use treat as to make it so.

Using this proposal, the most convenient way to match locally declared
types in a path expression is to use the globally declared types in
which they are contained to establish a type context; eg, the
following query from use case STRONG is statically valid as modified
below:


define function names-match(
    $s as element(ipo:purchaseOrder/ipo:shipTo),
    $b as element(ipo:purchaseOrder/ipo:billTo)
    as xs:boolean
{
        $s/ipo:name = $b/ipo:name
}

for $p in document("ipo.xml")//element(ipo:purchaseOrder)
where not( names-match( $p/ipo:shipTo, $p/ipo:billTo ) )
return $p


ElementType and AttributeType nodetests can also be used in match
patterns on XSLT stylesheets, eg:

     <xsl:template match="element(person)">

     <xsl:template match="attribute(*,xs:date)">

For more examples of ElementType and AttributeType nodetests in match
patterns, see [1].

This proposal steals liberally from proposals by Phil Wadler, Jeni
Tennison, Michael Rys, and Mike Kay. Don Chamberlin gave detailed
review and pointed out important problems and their solutions.  Scott
Boag tested the grammar.


========================================================================
2. Examples of ElementTypeTest and AttributeTypeTest

Informally, the principles for matching an ElementTypeTest or
AttributeTypeTest are as follows:

- element() matches elements, attribute() matches attributes.

- names in ElementTypeTest and AttributeTypeTest test the name of a
   node. If the name of an element identifies a Corresponding Element
   Declaration which is the head of a substitution group, the name of
   an ElementTypeTest also matches other names in the substitution
   group.

- types in ElementTypeTest and AttributeTypeTest match type
   annotations.  If no type is supplied, there must be a Corresponding
   Element Declaration or a Corresponding Attribute Declaration, which
   is used to nominate a type.

The following examples illustrate these semantics by stating what
nodes an ElementTypeTest would match.

  element()
  element(*)
  element(*,*)

    Matches any element. These three forms are equivalent.

  element( person )

    Matches any element named 'person' with the type corresponding to
    the globally declared 'person' element; if this element is
    nillable, also matches any empty element named person containing an
    xsi:nil attribute with the value 'true'. If the globally declared
    'person' element is the head of a substitution group, also matches
    element names from the substitution group. If there is no globally
    declared 'person' element, a type error is raised.

  element( person, * )

    Matches any element named person or any element whose name is in
    the substitution group of the globally declared element person, if
    one exists. This is equivalent to the earlier ~person syntax, which
    we feel is no longer needed.

  element( person, personType nillable )

    Matches any element named 'person' with the type 'personType',
    including any empty element named person containing an xsi:nil
    attribute with the value 'true'. If the globally declared 'person'
    element is the head of a substitution group, also matches element
    names from the substitution group.

  element( *, xs:integer nillable )

   Matches any element of type xs:integer, including any such element
   with xs:nil="true" and no content.

  element( foo/bar/person )

    Matches any element named 'person' with the type of the
    corresponding element declaration.

  element( foo/bar/person, personType )

    Syntax Error.

  attribute()

    Matches any attribute.

  attribute( foo/bar/person/@id )

    Matches any attribute named 'id' with the type of the corresponding
    attribute declaration.

  element( @*, xs:integer )

   Matches any attribute of type xs:integer.

  attribute( @price, xs:integer )

   Matches any attribute named price of type xs:integer.


========================================================================
3. Syntax


Tokens

Scott currently has the following as tokens, and is working on making
them productions:

[22]    SchemaGlobalContext    ::=    QName |  ("type" "(" QName ")")
[23]    SchemaContextStep    ::=    QName

Productions

[112]    SequenceType    ::=    (SequenceSingleType OccurrenceIndicator?)
                              |  <"empty" "(" ")">
[113]    SequenceSingleType    ::=    AtomicType |  ItemType
[114]    AtomicType    ::=    QName
[115]    ItemType    ::=   KindTest |  <"item" "(" ")">
[116]    KindTest    ::=   DocumentTest
                         |  ElementTypeTest
                         |  AttributeTypeTest
                         |  ProcessingInstructionTest
                         |  CommentTest
                         |  TextTest
                         |  AnyKindTest


[117]    DocumentTest    ::=    <"document" "(" ")">
[118]    ElementTypeTest ::=    <"element" "("> ((SchemaContextPath LocalName)
                             |  (NodeName ("," TypeName "nillable"?)?))? ")"
[119]    AttributeTypeTest ::=  <"attribute" "("> ((SchemaContextPath "@"
LocalName)
                             |  ("@" NodeName ("," TypeName)?))? ")"
[120]    SchemaContextPath ::=  <SchemaGlobalContext "/">
<SchemaContextStep "/">*
[122]    LocalName    ::=    QName
[123]    NodeName    ::=    QName |  "*"
[124]    TypeName    ::=    QName |  "*"
[125]    OccurrenceIndicator    ::=    "*" |  "+" |  "?"


========================================================================
4. Semantics

A ContextName identifies a valid path from a globally declared element
declaration or type definition in the in-scope schema definitions. For
instance, the following indicates a shipTo element on a purchaseOrder:

   purchaseOrder/shipTo

If a ContextName begins with type(t), then the path starts with a
global named type in the in-scope schema definitions. For instance,
the following indicates a shipTo element in a complex type called
purchaseOrderType:

   type(purchaseOrderType)/shipTo

The rules for matching an ElementTypeTest depend on the Corresponding
Element Declaration, which is determined as follows:

   An ElementName is the first argument of an ElementTypeTest.

   If the ElementName has the form NodeName, and it matches the name of
   a globally declared element declaration in the in-scope schema
   definitions, it is the "Corresponding Element Declaration". If the
   ElementName has the form SchemaContextPath LocalName, then the
   element declaration which would correspond to an element named
   LocalName in the given context is the "Corresponding Element
   Declaration".

The rules for matching an AttributeTypeTest depend on the
Corresponding Attribute Declaration,

   An AttributeName is the first argument of an AttributeTypeTest.

   If the AttributeName has the form NodeName, and it matches the name
   of a globally declared element declaration in the in-scope schema
   definitions, it is the "Corresponding Element Declaration". If the
   AttributeName has the form SchemaContextPath LocalName, then the
   element declaration which would correspond to an element named
   LocalName in the given context is the "Corresponding Attribute
   Declaration".

An ElementTypeTest matches a node if the node is an element, the
element's name matches the ElementName of the ElementTypeTest, and the
element's type matches the type and nillability of the
ElementTypeTest.

An ElementName is matched as follows:

   If the ElementName is absent or "*", it matches an
   element of any name.

   If the ElementName has the form NodeName, it matches an element if
   the expanded-QNames of the element and the ElementName match. If the
   ElementName has the form SchemaContextPath LocalName, it matches an
   element if the expanded-QNames of the element and the LocalName
   match.

   If the Corresponding Element Declaration is the head of a
   substitution group, then the ElementName also matches an element if
   the expanded-QNames of the element and any element in the
   substitution group match.

   Otherwise, the ElementName does not match the element's name.

An element's TypeName is matched as follows:

   If the TypeName is "*", it matches an element of any type.

   If the TypeName is absent, then the default TypeName is selected,
   which is the type of the Corresponding Element Declaration. The
   default nillability is also selected, which is the nillability of
   the Corresponding Element Declaration.

   If the expanded-QName of the TypeName matches the element's type or
   any of its subtypes, then the TypeName matches the element's type if
   the type nillability is also satisfied.

   If the element's type name is an anonymous local type, the TypeName
   must be a default type chosen from the Corresponding Element
   Declaration, and they match if the element's type is the same as or
   derived by restriction or extension from the type of the TypeName,
   provided the type nillability is also satisfied.

   An element's type nillability is not satisified when the type is not
   nillable, and the element's dm:nil property is 'true'; otherwise, it
   is satisfied.

The semantics of AttributeTypeTest are parallel, substituting the word
'attribute' for 'element' in the above description and eliminating
substitution groups and nillable, which do not apply to attributes. An
AttributeTypeTest matches a node if the node is an attribute, the
attribute's name matches the AttributeName of the AttributeTypeTest, and
the attribute's type matches the type and nillability of the
AttributeTypeTest.


An AttributeName is matched as follows:

   If the AttributeName is absent or "*", it matches any attribute.

   If the AttributeName has the form NodeName, it matches an element if
   the expanded-QNames of the element and the AttributeName match. If
   the AttributeName has the form SchemaContextPath LocalName, it
   matches an element if the expanded-QNames of the element and the
   LocalName match.

   Otherwise, the AttributeName does not match the attribute's name.

An attribute's TypeName is matched as follows:

   If the TypeName is "*", it matches an attribute of any type.

   If the TypeName is absent, then the default TypeName is selected,
   which is the type of the corresponding attribute declaration.

   If the expanded-QName of the TypeName matches the attribute's type
   or any of its subtypes, then the TypeName matches the attribute.

   If the attribute's type name is an anonymous local type, the
   TypeName must be a default type chosen from the Corresponding
   Attribute Declaration, and they match if the attribute's type is the
   same as or derived by restriction or extension from the type of the
   TypeName.


========================================================================
6. attribute() and default axes

To allow attribute() to be used in path expressions, abbreviated steps
need to be modified as follows:

Current text:


   >     The most important abbreviation is that child:: can be omitted
   >     from a step. In effect, child is the default axis. For example,
   >     a path expression section/para is short for
   >     child::section/child::para.


Proposed text:


   >     The most important abbreviation is that child:: can be omitted
   >     from a step, or attribute:: can be omitted from a step that
   >     contains an AttributeTypeTest. In most cases, child is the
   >     default axis. For example, a path expression section/para is
   >     short for child::section/child::para. However, if the step
   >     contains an AttributeType, the default axis is attribute::. For
   >     example, child::section/attribute( id ) is short for
   >     child::section/attribute::attribute( id ).



========================================================================
7. Static Semantics

    To be supplied.


========================================================================
8. Issues

Issue:

     Should a WildCard be allowed for the names of attributes and
     elements? For instance, one might imagine wanting to select only
     HTML elements of type xs:string:

         element(html:*, xs:string)

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Proposal accepted resolving issue.

342. grammar-prolog-problems: Prolog syntax

Locus: xquery Cluster: grammar Priority: o-1 Status: resolved
Originator: Scott Boag

Description

The prolog productions require special handling, but there is no special prolog state. Right now prolog productions must be distinguished by compound keywords such as &lt;"declare" "namespace">. We either need to make sure we're happy with this, or make some sort of prolog container.

Actual Resolution

Decision by: xquery on 2003-01-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0215.html)Joint F2F

Closed with no action because existing solutions are good enough.

343. namespaces-functions: Do functions in the null namespace clash with functions in the default namespace?

Locus: xpath Cluster: namespaces Priority: 1 Status: decided
Originator: XPath TF

Description

If you define the DFN (default function namespace) to be the null namespace, which you must do if you are going to call functions in this namespace, can you still use unprefixed names to refer to functions in the built-in namespace?

Interactions and Input

Cf. Should we keep the default function namespace, and the xf: namespace?

Actual Resolution

Decision by: xquery on 2003-01-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0435.html)A static error is raised when there is a clash between a user-defined function in the default namespace and any other function of the same name in the default namespace.

Decision by: xpath-tf on 2003-05-14 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0037.html)

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Given the decision on issue #default-namespace-functions it is a (statically detectable) error to define functions in the null namespace.

344. FS-Issue-0001: Attributes

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

One example of the need for support of #FS-Issue-0049, but also: Attributes need to be constrained to contain white space separated lists of simple types only.

Actual Resolution

Decision by: fs-editors on 2000-10-16

Attributes are represented by attribute attribute-name { content }.

345. FS-Issue-0002: Namespaces

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Namespaces

Actual Resolution

Decision by: fs-editors on 2000-10-16

Namespaces are represented by {uri-of-namespace}localname.

346. FS-Issue-0003: Document Order

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The data model and algebra do not define a global order on documents. Querying global order is often required in document-oriented queries.

Actual Resolution

Decision by: fs-editors on 2000-12-16

Resolved by adding < operator defined on nodes in same document. See #FS-Issue-0079 for order between nodes in different documents.

347. FS-Issue-0004: References vs containment

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The query-algebra datamodel currently does not explicitly model children-elements by references (other than the XML-Query Datamodel. This facilitates presentation, but may be an oversimplification with regard to #FS-Issue-0005.

Actual Resolution

Decision by: fs-editors on 2000-10-16

This issue is resolved by subsumption as follows: (1) All child-elements are (implicit) references to nodes. (2) Thus, having resolved #FS-Issue-0005 this issue is resolved too.

348. FS-Issue-0005: Element identity

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Do expressions preserve element identity or don't they? And does "=" and distinct use comparison by reference or comparison by value?

Actual Resolution

Decision by: fs-editors on 2000-10-16

The first part of the question has been resolved by resolution of #FS-Issue-0010. The second part raises a more specific issue #FS-Issue-0066.

349. FS-Issue-0006: Source and join syntax instead of "for"

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Another term for "source and join syntax" is "comprehension".

Actual Resolution

Decision by: fs-editors on 2000-10-16

This issue is resolved by subsumption under #FS-Issue-0021. List comprehension is a syntactic alternative to "for v in e1 do e2", which has been favored by the WG in the resolution of #FS-Issue-0021.

350. FS-Issue-0007: References: IDREFS, Keyrefs, Joins

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Currently, the Algebra does not support reference values, such as IDREF, or Keyref (not to be mixed up with "node-references" - see #FS-Issue-0005, which are defined in the XML Query Data Model. The Algebra's type system should be extended to support reference types and the data model operators ref, and deref should be supported (similar to id() in XPath).

Actual Resolution

Decision by: fs-editors on 2001-04-02

Delegated to XPath 2.0. Algebra should adopt solutions (e.g., id()/keyref() functions) provided in XPath 2.0. There may be an interaction between IDREFs and RefNodes, but we're not going to cover that now.

351. FS-Issue-0008: Fixed point operator or recursive functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

It may be useful to add a fixed-point operator, which can be used in lieu of recursive functions to compute, for example, the transitive closure of a collection.

Currently, the Algebra does not guarantee termination of recursive expressions. In order to ensure termination, we might require that a recursive function take one argument that is a singleton element, and any recursive invocation should be on a descendant of that element; since any element has a finite number of descendants, this avoids infinite regress. (Ideally, we should have a simple syntactic rule that enforces this restriction, but we have not yet devised such a rule.)

Impacts optimization; hard to do static type inference; current algebra is first-order

Actual Resolution

Decision by: fs-editors on 2002-05-30

The functionality described is appropriately covered by the use of recursive functions. XQuery is a functional language and does not provide a fixed-point operator in its current version.

352. FS-Issue-0009: Externally defined functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

There is no explicit support for externally defined functions.

The set of built-in functions may be extended to support other important operators.

Actual Resolution

Decision by: fs-editors on 2001-04-02

Algebra editors endorse a solution that uses XP for specifying signatures of external functions. Algebra will adopt solution provided by [XPath/XQuery].

353. FS-Issue-0010: Construct values by copy

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Need to be able to construct new types from bits of old types by reference and by copy. Related to #FS-Issue-0005.

Actual Resolution

Decision by: fs-editors on 2000-09-21

The WG wishes to support both: construction of values by copy, as well as references to original nodes. This needs some further investigation to sort out all technical difficulties (see #FS-Issue-0062) so the change has not yet been reflected in the Algebra document.

354. FS-Issue-0011: XPath tumbler syntax instead of index?

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Algebra Editors

Description

XPath provides as a shorthand syntax [integer] to select child-elements by their position on the sibling axes, whereas the xml-query algebra uses a combination of a built-in function index() and iteration.

Addendum by JS (submitted by MF) Dec 19/2000: The typing of index is lossy : it produces a factored type. Jerome suggests the more precise range operator:

e : q min m  max n   n' - (m'-1) = r  m' >= m   n' <= n
-----------------------------------------------
            range(e;m';n') : q min r  max r
nth(e;n) == range(e;n;n)

The range operator takes a repetition of prime types and those values in the range m' to n'; if the repetition does not include that range, a run-time error is raised. The range and nth operators could also be defined in terms of head and tail and polymorphic recursive functions. In the absence of parameteric polymorphism, it is not possible to define range and nth with precise types.

Here are Peter's rules:

e : p min m  max n     n!=*
-------------------------------------------------
range(e;m';n') : p{n'-max(m,m')+1,min(n',n)-m'+1}
For example:
let v1 = a[] min 2  max 4
range(v1;3;3): a[] min 1  max 1
range(v1;1;3): a[] min 2  max 3
range(v1;3;5): a[] min 1  max 2
range(v1;1;5): a[] min 2  max 4
e : p min m  max *
-----------------------------
range(e;m';n') : p min 0  max n'-m'+1
let v2 = a[] min 0  max *
range(v2;1;3): a[] min 0  max 2
this follows the typical semantics for head() and tail():
head(()) = tail(()) = ()
and the semantics behind
range(e;m',n') = tail o ...(m' times)   ... o tail o head,
                 tail o ...(m'+1 times) ... o tail o head,
                 ...
                 tail o ...(n' times)   ... o tail o head

I would have no troubles in restricting ourselves to nth() instead of range() in the algebra (range can always be enumerated by nth()). Furthermore, we should consider whether m',n' can be computed numbers.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

Issue outdated and moot.

355. FS-Issue-0012: GroupBy - needs second order functions?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The type system is currently first order: it does not support function types nor higher-order functions. Higher-order functions are useful for specifying, for example, sorting and grouping operators, which take other functions as arguments.

Actual Resolution

Decision by: fs-editors on 2000-09-21

The WG has decided to express groupBy by a combination of for and distinct. Thus w.r.t. to GroupBy this Issue is resolved. Because GroupBy is not the only use case for higher order functions, a new issue #FS-Issue-0063 is raised.

356. FS-Issue-0013: Collations

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Collations identify the ordering to be applied for sorting strings. Currently, it is considered to have an (optional parameter) collation "name" as follows: "SORT variable IN exp BY +(expression {ASCENDING|DESCENDING} {COLLATION name}). An alternative would be to model a collation as a simple type derived from string, and use type-level casting, i.e. expression :collationtype (which is already supported in the XML Query Algebra), for specifying the collation. That would make: "SORT variable IN exp BY +(expression:collationname {ASCENDING|DESCENDING}). But that requires some support from XML-Schema.

More generally, collations are important for any operator in the Algebra that involves string comparison, among them: sort, distinct, "=" and "<".

Actual Resolution

Decision by: fs-editors on 2001-04-02

Formal semantics will adopt solution provided by Operators.

357. FS-Issue-0014: Polymorphic types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The type system is currently monomorphic: it does not permit the definition of a function over generalized types. Polymorphic functions are useful for factoring equivalent functions, each of which operate on a fixed type.

The current type system has already a built-in polymorphic type (lists) and is likely to have more (unordered collections). The question is, whether to allow for user-defined polymorphic types and user defined polymorphic functions.

Actual Resolution

Decision by: fs-editors on 2002-05-30

It has been decided this feature was not required for XQuery 1.0.

358. FS-Issue-0015: 3-valued logic to support NULLs

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

3-valued logic to support NULLs

Actual Resolution

Decision by: fs-editors on 2002-03-11

The Formal Semantics supports the current semantics of NULL values, as described in the XQuery December working draft. The Formal Semantics will reflect further resolution of open issues on NULLs and 3 valued logic as decided by XQuery.

359. FS-Issue-0016: Mixed content

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The XML-Query Algebra allows to generate elements with an arbitrary mixture of data (of simple type) and elements. XML-Schema only allows for a combination of strings interspersed with elements (aka mixed content). We need to figure out whether and how to constrain the XML-Query Algebra accordingly (e.g. by typing rules?)

Actual Resolution

Decision by: fs-editors on 2000-12-09

The type system has been extended to support the interleaving operator & - see #FS-sec_typesystem. Mixed content is defined in terms of &.

360. FS-Issue-0017: Unordered content

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

All-groups in XML-Schema, not to be mixed up with #FS-Issue-0049

Actual Resolution

Decision by: fs-editors on 2000-10-16

The type system has been extended with the support of all-groups - see #FS-sec_typesystem.

361. FS-Issue-0018: Align algebra types with schema

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The Algebra's internal type system is the type system of XDuce. A potentially significant problem is that the Algebra's types may lose information when converted into XML Schema types, for example, when a result is serialized into an XML document and XML Schema.

James Clark points out : "The definition of AnyComplexType doesn't match the concrete syntax for types since it applies unbounded repetition to AnyTree and one alternative for AnyTree is AnyAttribute." This is another example of an alignment issue.

This issue comprises also issues #FS-Issue-0016, #FS-Issue-0017, #FS-Issue-0053, #FS-Issue-0054, #FS-Issue-0019, substitution groups.

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. See Sections 3 and 7 of the Formal Semantics document.

362. FS-Issue-0019: Support derived types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The current type system does not support user defined type hierarchies (by extension or by restriction).

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. Derived types are now supported in the type system. See Sections 3 and 7 of the Formal Semantics document.

363. FS-Issue-0020: Structural vs. name equivalence

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The subtyping rules in #FS-sec_subtype_of only define structural subtyping. We need to extend this with support for subtyping via user defined type hierarchies - this is related to #FS-Issue-0019.

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. The Formal Semantics now support both named and structural typing. See Sections 3 and 7 of the Formal Semantics document.

364. FS-Issue-0021: Syntax

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

(e.g. for.<-.in vs for.in.do)

Actual Resolution

Decision by: fs-editors on 2000-09-21

The WG has voted for several syntax changes , "for v in e do e", "let v = e do", "sort v in e by e ...", "distinct", "match case v:t e ... else e".

365. FS-Issue-0022: Indentation, Whitespaces

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Is indentation significant?

Actual Resolution

Decision by: fs-editors on 2000-07-25

The WG has consensus that indentation is not significant , i.e., all documents are white space normalized.

366. FS-Issue-0023: Catch exceptions and process in algebra?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Does the Algebra give explicit support for catching exceptions and processing them?

Actual Resolution

Decision by: fs-editors on 2000-10-16

Subsumed by new issue #FS-Issue-0064.

367. FS-Issue-0024: Value for empty sequences

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

What does "value" do with empty sequences?

Actual Resolution

Decision by: fs-editors on 2000-10-25

The definition of value(e) has changed to:

value(e) = typeswitch children(e)
                     case v: AnyScalar do v
                     else()

Furthermore, the typing rules for "for v in e1 do e2" have been changed such that the variable v is typed-checked seperately for each unit-type occuring in expression e1.

Consequently the following example would be typed as follows:

query for b in b0/book do
      value(b/year): xs:integer min 0 max *

rather than leading to an error.

368. FS-Issue-0025: Treatment of empty results at type level

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

This is related to #FS-Issue-0024.

Actual Resolution

Decision by: fs-editors on 2000-10-25

Resolved by resolution of #FS-Issue-0025.

369. FS-Issue-0026: Project - one tag only

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Project is only parameterized by one tag. How can we translate a0/(b | c)?

Actual Resolution

Decision by: fs-editors on 2000-10-16

With the new syntax (and type system) a0/(b | c) can be translated to "for v in a0 do typeswitch case v1:b[AnyType] do v1 case v2:c[AnyType] do c else ()".

370. FS-Issue-0027: Case syntax

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt Comments et al.

Description

N-ary case can be realized by nested binary cases.

Actual Resolution

Decision by: fs-editors on 2000-10-16

New (n-ary) case syntax is introduced.

371. FS-Issue-0028: Fusion

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Michael Rys

Description

Does the Algebra support fusion as introduced by query languages such as LOREL? This is related to #FS-Issue-0005, because fusion only makes sense with support of element identity.

Actual Resolution

Decision by: fs-editors on 2001-04-02

Fusion is equivalent to 'natural full-outer join'. [XPath/XQuery] can reraise issue if desired. If added, the Algebra editors should review any solution w.r.t typing.

372. FS-Issue-0029: Views

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Michael Rys

Description

One of the problems in views: Can we undeclare/hide things in environment? For example, if we support element-identity, can we explicitly discard a parent, and/or children from an element in the result-set? Related to #FS-Issue-0005.

Actual Resolution

Decision by: fs-editors on 2001-04-02

[XPath/XQuery] can reraise issue if desired. If added, the Algebra editors should review any solution w.r.t typing.

373. FS-Issue-0030: Automatic type coercion

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

What do we do if a value does not have a type or a different type from what is required?

Proposed Resolution

We believe that the XML Query Language should specify default type coercions for mixed mode arithmetic should be performed according to a fixed precedence hierarchy of types, specifically integer to fixed decimal, fixed decimal to float, float to double. This policy has the advantage of simplicity, tradition, and static type inference. Programmers could explicitly specify alternative type coercions when desirable.

Actual Resolution

Decision by: fs-editors on 2001-04-02

Delegation to XPath 2.0, [XPath/XQuery], and/or Operators.

374. FS-Issue-0031: Recursive functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Recursive functions

Actual Resolution

Decision by: fs-editors on 2000-08-05

subsumed by #FS-Issue-0008

375. FS-Issue-0032: Full regular path expressions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Full regular path expressions allow to constrain recursive navigation along paths by means of regular expressions, e.g. a/b*/c denotes all paths starting with an a, proceeding with arbitrarily many b's and ending in a c. Currently the XML-Query Algebra can express this by means of (structurally) recursive functions. An alternative may be the introduction of a fixpoint operator #FS-Issue-0008.

Actual Resolution

Decision by: fs-editors on 2001-04-02

XPath 2.0 can raise issue if desired. The Algebra editors should review any solution w.r.t typing.

376. FS-Issue-0033: Metadata Queries

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Metadata queries are queries that require runtime access to type information.

Actual Resolution

Decision by: fs-editors on 2002-05-30

Metadata queries are believed to be appropriately covered by XQuery 1.0 (e.g., using typeswitch).

377. FS-Issue-0034: Fusion

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Fusion

Actual Resolution

Decision by: fs-editors on 2000-08-05

Identical with #FS-Issue-0028

378. FS-Issue-0035: Exception handling

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Exception handling

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0023 and #FS-Issue-0064.

379. FS-Issue-0036: Global-order based operators

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Global-order based operators

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0003

380. FS-Issue-0037: Copy vs identity semantics

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Copy vs identity semantics

Actual Resolution

Decision by: fs-editors on 2000-08-05

subsumed by #FS-Issue-0005

381. FS-Issue-0038: Copy by reachability

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Is it possible to copy children as well as IDREFs, Links, etc.? Related to #FS-Issue-0005 and #FS-Issue-0008

Actual Resolution

Decision by: fs-editors on 2001-01-17

Resolved by addition of "deep" copy operator in XQuery 1.0 and XPath 2.0 Data Model.

382. FS-Issue-0039: Dereferencing semantics

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Dana Florescu

Description

Dereferencing semantics

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0005

383. FS-Issue-0040: Case Syntax

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We suggest that the syntax for "case" be made more regular. At present, it takes only two branches, the first labelled with a tag-name and the second labelled with a variable. A more traditional syntax for "case" would have multiple branches and label them in a uniform way. If the algebra is intended only for semantic specification, "case" may not even be necessary.

Actual Resolution

Decision by: fs-editors on 2000-08-05

subsumed by #FS-Issue-0027

384. FS-Issue-0041: Sorting

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We are not happy about the three-step sorting process in the Algebra. We would prefer a one-step sorting operator such as the one illustrated below, which handles multiple sort keys and mixed sorting directions: SORT emp <- employees BY emp/deptno ASCENDING emp/salary DESCENDING

Actual Resolution

Decision by: fs-editors on 2000-09-21

The WG has decided to go for the above syntax, with an (optional) indication of COLLATION.

385. FS-Issue-0042: GroupBy

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We do not think the algebra needs an explicit grouping operator. Quilt and other high-level languages perform grouping by nested iteration. The algebra can do the same.

related to #FS-Issue-0012

Actual Resolution

Decision by: fs-editors on 2000-09-21

The WG has decided to skip groupBy for the time being.

386. FS-Issue-0043: Recursive Descent for XPath

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

The very important XPath operator "//" is supported in the Algebra only by writing a recursive function. This is adequate for a semantic specification, but if the Algebra is intended as an optimizable target language it will need better support for "//" (possibly in the form of a fix-point operator.)

Actual Resolution

Decision by: fs-editors on 2000-09-21

Resolved by subsumption under #FS-Issue-0043

387. FS-Issue-0044: Keys and IDREF

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We think the algebra needs some facility for dereferencing keys and IDREFs (exploiting information in the schema.)

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0007

388. FS-Issue-0045: Global Order

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We are concerned about absence of support for operators based on global document ordering such as BEFORE and AFTER.

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0003

389. FS-Issue-0046: FOR Syntax

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

We agree with comments made in the face-to-face meeting about the aesthetics of the Algebra's syntax for iteration. For example, the following syntax is relatively easy to understand: FOR x IN some_expr EVAL f(x) whereas we find the current algebra equivalent to be confusing and misleading: FOR x <- some_expr IN f(x) This syntax appears to assign the result of some_expr to variable x, and uses the word IN in a non-intuitive way.

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0021

390. FS-Issue-0047: Attributes

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Quilt

Description

See #FS-Issue-0001.

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0001

391. FS-Issue-0048: Explicit Type Declarations

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Group 1 at F2F, Redmond

Description

Type Declaration for the results of a query: The issue is whether to auto construct the result type from a query or to pre-declare the type of the result from a query and check for correct type on the return value. Suggestion: Support for pre-declared result data type and as well as to coerce the output to a new type is desirable. Runtime or compile time type checking is to be resolved? Once you attach a name to a type, it is preserved during the query processing.

Actual Resolution

Decision by: fs-editors on 2000-10-16

W.r.t. compile time type casts this is already possible with e:t. For run-time casts an issue has been raised in #FS-Issue-0062.

392. FS-Issue-0049: Unordered Collections

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors, Group 1, F2F, Redmond

Description

Currently, all sequences in the data model are ordered. It may be useful to have unordered forests. The distinct-node function, for example, produces an inherently unordered forest. Unordered forests can benefit from many optimizations for the relational algebra, such as commutable joins.

Handling of collection of attributes is easy but the collection of elements is complex due to complex type support for the elements. It makes sense to allow casting from unordered to ordered collection and vice versa. It is not clear whether the new ordered or unordered collection is a new type or not. It affects function resolution, optimization.

Our request to Schema to represent insignificance of ordering at schema level has not been fulfilled. Thus we need to be aware that this information may get lost, when mapping to schema.

Actual Resolution

Decision by: fs-editors on 2000-12-11

Unordered collections are described by {t} see #FS-sec_typesystem, some operators (sort, distinct-node, for, and sequence) are overloaded, and some operators (difference, intersection) are added). A new issue #FS-Issue-0076 is raised.

393. FS-Issue-0050: Recursive Descent for XPath

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Group 1, F2F, Redmond

Description

Suggestion: The group likes to add a support for fixed-point operator in the query language that will allow us to express the semantics of the // operator in an xpath expression. A path expression of the form a//b may be represented by a fixed-point operator fp(a, "/.")/b.

Actual Resolution

Decision by: fs-editors on 2000-08-05

Subsumed by #FS-Issue-0043

394. FS-Issue-0051: Project redundant?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

It appears that project a e could be reduced to sth. like

for v <- e in case v of a[v1] =>
        a[v1] | v2 => ()

... or would that generate a less precise type?

Actual Resolution

Decision by: fs-editors on 2000-10-16

With the new type system and handling of the for operator, project is indeed redundant.

395. FS-Issue-0052: Axes of XPath

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current algebra makes navigation to parents difficult to impossible. With support of Element Identity #FS-Issue-0005 and recursive functions #FS-Issue-0008 one can express parent() by a recursive function via the document root. More direct support needs to be investigated w.r.t its effect on the type system.

The WG wishes to support a built-in operator parent().

Actual Resolution

Decision by: fs-editors on 2001-04-02

XPath 2.0 and [XPath/XQuery] can reraise issue if desired. Algebra should review any solution w.r.t typing. Question: whether namespace axis (i.e., access namespace nodes) will be included in [XPath/XQuery]. Algebra currently has issues related to typing of parent() and descendant(). If sibling axes are included in [XPath/XQuery], then Algebra should review w.r.t. typing.

396. FS-Issue-0053: Global vs. local elements

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current type system cannot represent global element-declarations of XML-Schema. All element declarations are local.

Actual Resolution

Decision by: fs-editors on 2002-03-11

The type system now supports both local and global elements and attributes.

397. FS-Issue-0054: Global vs. local complex types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current type system does not distinguish between global and local types as XML-Schema does. All types appear to be fully nested (i.e. local types)

Actual Resolution

Decision by: fs-editors on 2002-03-11

The type system now supports both local and global types.

398. FS-Issue-0055: Types with non-wellformed instances

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The type system and algebra allows for sequences of simple types, which can usually be not represented as a well-formed document. How shall we constrain this? Related to #FS-Issue-0016.

Actual Resolution

Decision by: fs-editors on 2002-05-30

XQuery 1.0 supports non-well-formed heterogeneous sequences for intermediate results. The XQuery type system supports a way to type such intermediate results.

399. FS-Issue-0056: Operators on Simple Types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Fernandez et al.

Description

We intentionally did not define equality or relational operators on element and simple type. These operators should be defined by consensus.

Actual Resolution

Decision by: fs-editors on 2001-04-02

[XPath/XQuery] formal semantics adopts solution provided by Operators task force.

400. FS-Issue-0057: More precise type system; choice in path

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: LA-Team

Description

(This subsumes #FS-Issue-0051). If the type system were more precise, then (project a e) could be replaced by:

for v &lt;- e in
    case v of
      a[v1] =&gt; a[v1]
    | v2 =&gt; ()

One could also represent (e/(a|b)) directly in a similar style.

for v &lt;- e in
    case v of
      a[v1] =&gt; a[v1]
    | v2 =&gt; case v2 of
      b[v3] =&gt; b[v3]
            | v4 =&gt; ()

Currently, there is no way to represent (e/(a|b)) without loss of precision, so if we do not change the type system, we may need to have some way to represent (e/(a|b)) and similar terms without losing precision. (The LA team has a design for this more precise type system, but it is too large to fit in the margin of this web page!)

Actual Resolution

Decision by: fs-editors on 2000-10-16

See resolution of #FS-Issue-0051

401. FS-Issue-0058: Downward Navigation only?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: LA-Team

Description

Related to #FS-Issue-0052. The current type system (and the more precise system alluded to in #FS-Issue-0057) seems well suited for handling XPath children and descendant axes, but not parent, ancestor, sibling, preceding, or following axes. Is this limitation one we can live with?

Actual Resolution

Decision by: fs-editors on 2000-10-16

Subsumed by #FS-Issue-0052

402. FS-Issue-0059: Testing Subtyping

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: LA-Team

Description

One operation required in the Algebra is to test whether XML type t1 is a subtype of XML type t2, indicated by writing t1 <: t2. There is a well-known algorithm for this, based on tree automata, which is a straightforward variant of the well-known algorithm for testing whether the language generated by one regular-expression is a subset of the language generated by another. (The algorithm involves generating deterministic automata for both regular expressions or types.)

However, the naive implementation of the algorithm for comparing XML types can be slow in practice, whereas the naive algorithm for regular expressions is tolerably fast. The only acceptably fast implementation of a comparison for XML types that the LA team knows of has been implemented by Haruo Hasoya, Jerome Voullion, and Benjamin Pierce at the University of Pennsylvania, for their implementation of Xduce. (Our implementation of the Algebra re-uses their code, with permission.)

So, should we adopt a simpler definition of subtyping which is easier to test? One possibility is to adopt the sibling restriction from Schema, which requires that any two elements which appear a siblings in the same content model must themselves have contents of the same type. Jerome Simeon and Philip Wadler discovered that adopting the sibling restriction reduces the problem of checking subtyping of XML types to that of checking regular languages for inclusion, so it may be worth adopting the restriction for that reason.

Actual Resolution

Decision by: fs-editors on 2002-10-30

With pure named typing, subtyping can be checked using standard finite state automatas.

403. FS-Issue-0060: Internationalization aspects for strings

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: I18N

Description

These issues are taken from the comments on the Requirements Document by I18N

Further information can be found at http://www.w3.org/TR/WD-charreqhttp://www.w3.org/TR/WD-charreq.

It is a goal of i18n that queries involving string matching ("select x where x='some_constant'") treat canonically equivalent strings (in the Unicode sense) as matching. If the query and the target are both XML, early normalization (as per the Character Model) is assumed and binary comparison ensures that the equivalence requirement is satisfied. However, if the target is originally a legacy database which logically has a layer that exports the data as XML, that XML must be exported in normalized form. The XML Query spec must impose the normalization requirement upon such layers.

Similarly, the query may come from a user-interface layer that creates the XML query. The XML Query spec must impose the normalization requirement upon such layers.

Provided that the query and the target are in normalized form C, the output of the query must itself be in normalized form C.

Queries involving string matching should support various kinds of loose matching (such as case-insensitivity, katakana-hiragana equivalence, accent-accentless equivalence, etc.)

If such features as case-insensitivity are present in queries involving string matching, these features must be properly internationalized (e.g. case folding works for accented letters) and language-dependence must be taken into account (e.g. Turkish dotless-i).

Queries involving character counting and indexing must take into account the Character Model. Specifically, they should follow Layer 3 (locale-independent graphemes). Additional details can be found in The Unicode Standard 3.0 and UTR#18. Queries involving word counting and indexing should similarly follow the recommendations in these references.

Actual Resolution

Decision by: fs-editors on 2001-04-02

[XPath/XQuery] formal semantics adopts solution provided by Operators task force.

404. FS-Issue-0061: Model for References

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Group 3, F2F, Redmond

Description

Related to a number of issues around #FS-Issue-0005.

  • Use Cases Table of Contents REF *could* do this well if it were restructured - it does not maintain unforeseen relationships or use them... Bibliographies Recursive parts RDF assertions Inversion of simple parent/child references (related to #FS-Issue-0058).
  • What can we leave out? can we leave out transitive closure? can we limit recursion? can we leave out fixed point recursion? related to #FS-Issue-0008
  • Do we need to be able to... a. Find the person with the maximum number of descendants? b. Airplane routes: how can I get from RDU to Raleigh? (fixed point: guaranteeing termination in reasonable time...) c. Given children and their mothers, can I get mothers and their children? (without respect to the form of the original reference...) related to #FS-Issue-0008.
  • Should we abstract out the difference between different kinds of references? If so, should we be able to cast to a particular kind of reference in the output? a. abstracting out the differences is cheaper, which is kewl... b. the kind of reference gives me useful information about: locality (same document, same repository, big bad internet...) static vs. dynamic (xpointer *may* be resolved dynamically, or *may* be resolved at run time, ID/IDREF is static). related to #FS-Issue-0007.
  • do we need to be able to generate ids, e.g. using skolem functions? for a document in RAM, or in a persistent tree, identity may be present, implicit, system dependent, and cheap - it's nice to have an abstraction that requires no more than the implicit identity persistable ID is more expensive, may want to be able to serialize with ID/IDREF to instantiate references in the data model can use XPath instead of generating ID/IDREF, but these references are fragile, and one reason for queries is to create data that may be processed further persistable ID unique within a repository context persistable ID that is globally unique related to #FS-Issue-0005.
  • copy vs. reference semantics "MUST not preclude updates..." in a pure query environment, sans update, we do not need to distinguish these if we have update, we may need to distinguish, perhaps in a manner similar to "updatable cursors" in SQL programs may do queries to get DOM nodes that can that be modified. It is essential to be able to distinguish copies of nodes from the nodes themselves. copy semantics - what does it mean? copy the descendant hierarchy? copy the reachability tree? (to avoid dangling references) related to #FS-Issue-0038.

Actual Resolution

Decision by: fs-editors on 2001-04-02

Handled in current data model and algebra.

405. FS-Issue-0062: Open questions for constructing elements by reference

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez et al.

Description

(1) What is the value of parent() when constructing new elements with children refering to original nodes?

(2) Is an approach to either make copies for all children or provide references to all children, or should we allow for a more flexible combination of copies and references?

Actual Resolution

Decision by: fs-editors on 2001-01-17

Operational semantics specifies that element node constructor creates copies of all its children. Addition of RefNode in XQuery 1.0 and XPath 2.0 Data Model supports explicit reference value.

406. FS-Issue-0063: Do we need (user defined) higher order functions?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current XML-Query-Algebra does not allow functions to be parameters of another function - so called higher order functions. However, most of the Algebra operators are (built-in) higher functions, taking expressions as an argument ("sort", "for", "case" to name a few). Even a fixpoint operator, "fun f(x)=e, fix f(x) in e" (see also #FS-Issue-0008), would be a built-in higher order function.

Actual Resolution

Decision by: fs-editors on 2000-10-18

The XML Query Algebra will not support user defined higher order functions. It does support a number of built-in higher order functions.

407. FS-Issue-0064: Error code handling in Query Algebra

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Rezaur Rahman

Description

How do we return an error code from a function defined in current Query algebra. Do we need to create an array (or a structure) to merge the return value and error code to do this. If that is true, it may be inefficient to implement. In order for cleaner and efficient implementation, it may be necessary to allow a function declaration to take a parameter of type "output" and allow it to return an error code as part of the function definition.

Actual Resolution

Decision by: fs-editors on 2000-10-25

One does not need to create a structure to combine return values with error codes, provided each operator or function /either/ returns a value /or/ raises an error. The XML-Query Algebra supports means to raise errors, but does not define standard means to catch errors. Raising errors is accomplished by the expression "error" of type ^ (empty choice). Because ^ | t = t, such runtype errors do not influence static typing. The surface syntax and/or detailed specification of operators on simple types (see #FS-Issue-0056) may choose to differentiate errors into several error-codes.

408. FS-Issue-0065: Built-In GroupBy?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

We may revisit the resolution of #FS-Issue-0042 and reintroduce GroupBy along the lines of sort: "group v in e1 by [e2 {collation}]". One reason for this may be that this allows to use collation for deciding about the equality of strings.

Actual Resolution

Decision by: fs-editors on 2000-10-18

The WG has decided to close this issue, and for the time being not consider GroupBy as a built-in operator. Furthermore, #FS-Issue-0013 is ammended to deal with collations for all operators involving a comparison of strings.

409. FS-Issue-0066: Shallow or Deep Equality?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

What is the meaning of "=" and "distinct"? Equality of references to nodes or deep equality of data?

Actual Resolution

Decision by: fs-editors on 2001-01-17

XQuery 1.0 and XPath 2.0 Data Model defines "=" (value equality) and "==" (identity equality) operators. Description of distinct states that it uses "==".

410. FS-Issue-0067: Runtime Casts

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: ???

Description

In some contexts it may be desirable to cast values at runtime. Such runtime casts lead to an error if a value cannot be cast to a given type.

Actual Resolution

Decision by: fs-editors on 2000-10-25

caste:t has been introduced as a reducible operator expressed in terms of typeswitch.

411. FS-Issue-0068: Document Collections

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

Per our requirements document we are chartered to support document collections. The current XML-Query Algebra deals with single documents only. There are a number of subissues:

(a) Do we need a more elaborate notion of node-references? E.g. pair of (URI of root-node, local node-ref)

(b) Does the namespace mechanism suffice to type collections of nodes from different documents? Probably yes.

(c) Provided (a) and (b) can be settled, will the approach taken for #FS-Issue-0049 do the rest?

Actual Resolution

Decision by: fs-editors on 2002-05-30

Document collections are now supported in XQuery 1.0. Input functions have been added, the SequenceType production supports types for document nodes. The XQuery Type system has been extended to support document nodes.

412. FS-Issue-0069: Organization of Document

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current document belongs more to the genre (scientific) paper than to the genre specification. One may consider the following modifications: (a) reorganize intro to give a short overview and then state the purpose (strongly typed, neutral syntax with formal semantics as a basis for possibly multiple syntaxes, etc.) (compared to version Aug-23, this version has already gone a good deal in this direction). (b) Equip various definitions and type rules with id's. (c) Elaborate appendices on mapping XML-Query-Algebra Model vs. XML-Query-Datamodel, XML-Query-Type System vs. XML-Schema-Type System. (d) Maybe add an appendix on use-case-solutions. The problem is of course: Part of this is a lot of work, and we may not achieve all for the first release.

Actual Resolution

Decision by: fs-editors on 2000-10-18

The WG decided to dispose of this issue. The current overall organization of the document is quite adequate, but of course editorial decisions will have to made all the time.

413. FS-Issue-0070: Stable vs. Unstable Sort/Distinct

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Steve Tolkin

Description

Should sort (and distinct) be stable on ordered collections, i.e. lists, and unstable on unordered collections (see #FS-Issue-0049)?

Actual Resolution

Decision by: fs-editors on 2000-12-11

sort and distinct are stable on ordered collections, and unstable on unordered collections.

414. FS-Issue-0071: Alignment with the XML Query Datamodel

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Currently, the XML Query Algebra Datamodel does not model PI's and comments.

Actual Resolution

Decision by: fs-editors on 2001-01-17

Addition of operational semantics defines relationship of Algebra to Data Model.

415. FS-Issue-0072: Facet value access in Query Algebra

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Rezaur Rahman

Description

Each of the date-time data types have facet values as defined by the schema data types draft spec. This problem is general enough to be applied to other simple data types.

The question is : Should we provide access to these facet values on an instance of a particular data types? If so, what type of access? My take is the facets are to be treated like read-only attributes of a data instance and one should have a read access to them.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Semantics of named typing specifies that all simple types are represented by their name and their primitive base type. Facets are not represented explicitly in type system and can only be checked by validation.

416. FS-Issue-0073: Facets for simple types and their role for typechecking

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

XML-Schema introduces a number of constraining facets http://www.w3.org/TR/xmlschema-2/http://www.w3.org/TR/xmlschema-2/ for simple types (among them: length, pattern, enumeration, ...). We need to figure out whether and how to use these constraining facets for type-checking.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Semantics of named typing specifies that all simple types are represented by their name and their primitive base type. Facets are not represented explicitly in type system and can only be checked by validation.

417. FS-Issue-0074: Operational semantics for expressions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

It is necessary to add an operational semantics that formally defines each operator in the Algebra.

Actual Resolution

Decision by: fs-editors on 2001-03-30

The new document contains a full specification of the dynamic semantics.

418. FS-Issue-0075: Overloading user defined functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlain

Description

User defined functions can not be overloaded in the XML Query Algebra, i.e., a function is exclusively identified by its name, and not by its signature. Should this restriction be relaxed and if so - to which extent?

Actual Resolution

Decision by: fs-editors on 2001-04-02

No overloading in Query 1.0

419. FS-Issue-0076: Unordered types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Phil Wadler

Description

Currently unorderedness is represented at type level by {t}, and some (built-in) operators are overloaded such they have different semantics (and potentially different return type) depending on their input type. An alternative is to not represent unorderedness at type level, but rather support unordered for, unordered (unstable) sort, unordered (unstable) distinct.

Actual Resolution

Decision by: fs-editors on 2001-04-30

Removed unordered types from type system. Added support for unordered operator.

420. FS-Issue-0077: Interleaved repetition and closure

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

Regular Languages are closed w.r.t. to the interleaved product. However, they are not closed w.r.t. to interleaved repetition, which can (e.g) generate the 1 degree Dyck language D[1] = () | a D[1] b | D[1] D[1] = (a,b)^{0,*}, and more generally, any language that coordinates cardinalities of individual members from an alphabeth: E.g. (a ^ b)^ min 0 max * = all strings with equally many a's and b's. These are beyond regular languages. Should we thus try to do without interleaved repetition?

Actual Resolution

Decision by: fs-editors on 2001-04-02

if we use interleaved repetition (which we will because it is in MSL), they will be restricted to prime types.

421. FS-Issue-0078: Generation of ambiguous types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

Unambiguous content-models in XML 1.0 and XML Schema are not closed w.r.t. union. It appears that the XML Query-Algebra can generate result types which can not be transformed to an unambiguous content-model.

Actual Resolution

Decision by: fs-editors on 2002-05-30

The XQuery type system supports ambiguous types only for intermediate types generated during type inference.

422. FS-Issue-0079: Global order between nodes in different documents

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The global order operator < is defined on nodes in the same document, but not between nodes in different documents.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Resolution follows from the [XPath/XQuery] Data Model. Order between documents is implementation defined but stable.

423. FS-Issue-0080: Typing of parent

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: postponed
Originator: Algebra Editors

Description

Currently, the parent operator yields an imprecise type : AnyElement min 0 max 1. It might be possible to type parent more precisely, for example, by using the normalized names in MSL, which encode containment of types.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Issue closed for version 1.0. Can be reopened for version 2.0.

424. FS-Issue-0081: Lexical representation of Schema simple types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Schema simple types must be defined for the Algebra and [XPath/XQuery].

Actual Resolution

Decision by: fs-editors on 2001-04-02

Algebra will adopt lexical reps supported by [XPath/XQuery].

425. FS-Issue-0082: Type and expression operator precedence

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

The precedence of the type expressions is not defined.

Actual Resolution

Decision by: fs-editors on 2002-10-30

Precedence is the same as in XQuery.

426. FS-Issue-0083: Expressive power and complexity of typeswitch expression

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors, Michael Brundage

Description

When processing an XML document without schema information, i.e., the type of the document is AnyComplexType, then match expressions may be very expensive to evaluate:

  typeswitch x
  case t1 : AnyTree do 1
  case t2 : AnyTree min 0 max 2 do 2
  case t3 : *[*[*[*[* ... [AnyAttribute] ]]]] do 3
  else ERROR

typeswitch itself is not the issue. The real problem is having very liberal type patterns. We could restrict the kinds of type patterns that we permit.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Typeswitch types are now restricted to sequence types. Named typing will further help in reducing the complexity by allowing type annotation contained in the data model as a means for optimization.

427. FS-Issue-0084: Execution model

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Need prose describing execution model scenarios : interpretor vs. compile/runtime vs. translation into another query language. Explain relationship between static and dynamic semantics.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Section #FS-sec_procmodel defines a procesing model which serves as a framework for the Formal Semantics specification.

428. FS-Issue-0085: Semantics of Wildcard type

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors, Michael Brundage

Description

Cite: wildcard types cannot be implemented. If x!y means any name in x except names in y, what does x!y!z mean? In general, how do ! and | operate (precedence, associativity)? Parentheses are required to force the desired grouping of these two operators. Also, what does x!* mean? (There's an infinite family of such examples.)

Actual Resolution

Decision by: fs-editors on 2002-03-11

The [XPath/XQuery] type systyem now uses only simple wildcard names based on XPath's NameTest production.

429. FS-Issue-0086: Syntactic rules

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Need rules for specifying syntactic correctness of query: symbol spaces; variable def'ns precede uses; list of keywords, etc.

Actual Resolution

Decision by: fs-editors on 2001-04-02

Syntactic rules should be dealt with in [XPath/XQuery] document

430. FS-Issue-0087: More examples of Joins

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Algebra Editors, Michael Brundage

Description

Cite: no join operator; wants example of many-to-many joins, inner join, left and full outer joins.

Actual Resolution

Decision by: fs-editors on 2002-03-11

The XQuery document gives a number of such examples.

431. FS-Issue-0088: Align [XPath/XQuery] types with XML Schema : Formal Description.

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Sources of misalignment: [XPath/XQuery] types include comment and processing instruction; XML Schema: Formal Description does not. [XPath/XQuery] uses () for empty sequence; MSL uses the epsilon character. [XPath/XQuery] permits the names of attribute and element components to be wildcard expressions. MSL only permits literal names for attributes and elements, but permits stand-alone wildcard expressions. [XPath/XQuery] types call '&' interleaved repetition, but MSL says it means 'all g1 and g2 in either order'. Does MSL mean interleaved repetition?

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. The XQuery Type System aligns directly with XML Schema. See Sections 3 and 7 of the Formal Semantics document.

432. FS-Issue-0089: Syntax for types in XQuery

Locus: formal-semantics Cluster: Priority: 1 Status: subsumed
Originator: Mary Fernandez

Description

Formalism document gives a particular syntax for type expressions that is not supported in the [XPath/XQuery] surface syntax.

Actual Resolution

Decision by: fs-editors on 2002-28-11

Subsumed by #xquery-type-syntax

433. FS-Issue-0090: Static type-assertion expression

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Formalism document uses a static type-assertion expression that is not supported in the [XPath/XQuery] surface syntax.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Static type assertion is supported in XQuery with the new “assert as” expression.

434. FS-Issue-0091: Attribute expression

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

[XPath/XQuery] formal semantics has stand-alone attribute constructor/expression ATTRIBUTE QName (Exp) that is not supported in [XPath/XQuery] surface syntax.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Stand-alone attribute construction is supported in XQuery with the new syntax for element and attribute constructors.

435. FS-Issue-0092: Error expression

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

[XPath/XQuery] formal semantics has an error expression Error that is not supported in [XPath/XQuery] surface syntax.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Errors are raised by a function "dm:erorr()" instead of a separate expression.

436. FS-Issue-0093: Representation of Text Nodes in type system

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The data model distinguished between text nodes and strings, which are atomic values. Text nodes have identity, parents, and siblings. Strings do not. Text nodes are accessed by the children() accessor; strings and other atomic values are accessed by the typed-value() accessor. The distinction between text nodes and atomic values should exist in type system as well.

Actual Resolution

Decision by: fs-editors on 2002-03-11

Subsumed by new issue #FS-Issue-0105.

437. FS-Issue-0094: Static type errors and warnings

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

Static type errors and warnings are not specified. We need to enumerate in both the [XPath/XQuery] and formal semantics documents what kinds of static type errors and warnings are produced by the type system. See also #FS-Issue-0090.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft describes the semantics of errors.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

438. FS-Issue-0095: Importing Schemas and DTDs into query

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

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.

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. The new Formal Semantics document contains a complete mapping from XML Schema to the XQuery type system. See Section 7 of the Formal Semantics. Import of DTDs is supported, but should not be described in the Formal Semantics document.

439. FS-Issue-0096: Support for schema-less and incompletely validated documents

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin/Mary Fernandez

Description

This is related to #FS-Issue-0095. 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.

Actual Resolution

Decision by: fs-editors on 2002-05-30

XQuery supports schema-less document, and valid documents. It does not support invalid document, I.e., document with a schema for which validation fails. It can support those documents in a well-formed manner.

440. FS-Issue-0097: Static type-checking vs. Schema validation

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

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

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. XQuery and the XQuery Formals Semantics support both a validate operation and static typing.

441. FS-Issue-0098: Implementation of and conformance levels for static type checking

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: Don Chamberlin

Description

This issue is related to #FS-Issue-0059 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 [XPath/XQuery], in which some processors (or some processing modes) are more permissive about types. This would allow [XPath/XQuery] implementations that do not understand all of Schema, and it would allow customers some control over the cost/benefit tradeoff of type checking.

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Close issue 441 with no further work.

442. FS-Issue-0099: Incomplete/inconsistent mapping from [XPath/XQuery] to core

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

This mapping is still preliminary and contains inconsistencies. These inconsistencies will be addressed in detail in the next draft of the document.

Actual Resolution

Decision by: fs-editors on 2002-03-11

The Formal Semantics now provides a complete mapping from [XPath/XQuery] to the Core [XPath/XQuery]. Remaining issues with respect to that mapping are indicated separately.

443. FS-Issue-0100: Namespace resolution

Locus: formal-semantics Cluster: Semantics? Priority: 1 Status: resolved
Originator: FS Editors

Description

The way (when? where?) namespace prefixes are resolved is still an open issue.

Actual Resolution

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

444. FS-Issue-0101: Support for mixed content in the type system

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

Support for mixed content in the type system is an open issue. This reopens issue #FS-Issue-0016. Dealing with mixed content with interleaving raises complexity issue. See also #FS-Issue-0103.

Actual Resolution

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

The formal semantics is a specification of the behavior of an XQuery processor, not a recipe for implementation. The uses of interleaving in the specification are sufficiently restricted that a practical implementation can be written.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

445. FS-Issue-0102: Indentation, Whitespace

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

Whitespace normalization in [XPath/XQuery] is still an open issue. This reopens issue #FS-Issue-0022.

Actual Resolution

Decision by: fs-editors on 2002-07-26

New version now describes the semantics of element constructors and whitespace handling.

446. FS-Issue-0103: Complexity of interleaving

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: FS Editors

Description

The current type system allows interleaving is allowed on arbitrary types. Interleaving is an expensive operation and it is not clear how to define subtyping for it. Should we restrict use of interleaving on (optional) atomic types ? Should this restriction reflects the one in XML schema ? Related to #FS-Issue-0077.

Actual Resolution

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

The formal semantics is a specification of the behavior of an XQuery processor, not a recipe for implementation. The uses of interleaving in the specification are sufficiently restricted that a practical implementation can be written.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

447. FS-Issue-0104: Support for named typing

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

XML Schema is based on named typing, while the [XPath/XQuery] type system is based on strucural typing. Directly related issues are #FS-Issue-0019 and #FS-Issue-0018. Other impacted issues are #FS-Issue-0020, #FS-Issue-0072, #FS-Issue-0073, #FS-Issue-0088, #FS-Issue-0095, #FS-Issue-0097, #FS-Issue-0098, #FS-Issue-0111.

Actual Resolution

Decision by: fs-editors on 2002-05-30

Closed by the semantics of named typing. The Formal Semantics now support both named and structural typing. See Sections 3 and 7 of the Formal Semantics document.

448. FS-Issue-0105: Types for nodes in the data model.

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

The [XPath/XQuery] type system only supports element and attribute nodes. It needs to support other kinds of nodes from the [XPath/XQuery] datamodel, notably: text nodes and document nodes. Should it also include support for PI nodes, comment nodes and namespace nodes?

The data model distinguishes between text nodes and strings, which are atomic values. Text nodes have identity, parents, and siblings. Strings do not. Text nodes are accessed by the children() accessor; strings and other atomic values are accessed by the typed-value() accessor. The distinction between text nodes and atomic values should exist in type system as well.

Actual Resolution

Decision by: fs-editors on 2002-05-30

The new type system supports document and text nodes. Support for other kinds of nodes is discussed in #FS-Issue-0143

449. FS-Issue-0106: Constraint on attribute and element content models

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: Jerome

Description

The [XPath/XQuery] type system allows more content model than what XML Schema allows. For instance, the current type grammar allows the following types:

   element d { (attribute a | element b, attribute c)* }
   attribute a { element b }

Section #FS-sec_typesystem indicates corresponding constraints on the [XPath/XQuery] type system to avoid that problem. The status of these constraints is unclear. When are they enforced and checked?

Actual Resolution

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

Closed following the semantics of element constructors agreed at the December f2f meeting.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

450. FS-Issue-0107: Semantics of data()

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: FS Editors

Description

What is the semantics of data() applied to anything else than an element or attribute node ?

Proposed Resolution

XQuery 1.0 and XPath 2.0 Data Model
W3C Working Draft 17 January 2003
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0251.html

4.1.5 string-value Accessor
----------------------------

1. REPLACE entire section WITH:

    Every node has a string value; the way in which the string value
    is computed is different for each kind of node and is specified in
    the sections on nodes below.

4.1.6 typed-value Accessor
--------------------------

1. REPLACE:
      Otherwise, xs:anyType for elements or xs:anySimpleType for
attributes.

   WITH:
      Otherwise, xs:anyType for elements or xdt:untypedAtomic for
attributes.

2. REPLACE :

    * If the item is an element node with type xs:anyType, then its
      typed value is equal to its string value, as an instance of
      xdt:untypedAtomic.

  WITH:

    * If the node is an element node with type xs:anyType, then its
      typed value is equal to its string value, as an instance of
      xdt:untypedAtomic.

3. REPLACE :

    * The typed value of an element node with a simple type is derived
      from its string value and type in a way that is consistent with
      XML Schema validation.

  WITH:

    * If the node is an element node with a simple type or with a
      complex type of simple content, then its typed value is
      derived from its string value and type in a way that is
      consistent with XML Schema validation.

4. ADD:

    * If the item is an element node with complex type of empty
      content, then its typed value is the empty sequence.

    * If the node is an element node with a complex type of mixed
      content, then its typed value is its string value as an instance
      of xdt:untypedAtomic.

5. REPLACE:

    * If the item is an element node with complex content,
      dm:typed-value returns the empty sequence.

  WITH:

    * If the item is an element node with complex type of complex
      content, then its typed value is the empty sequence.

*************************************************
XQuery 1.0 and XPath 2.0 Functions and Operators
W3C Working Draft 10 December 2002
http://lists.w3.org/Archives/Member/w3c-archive/2002Dec/att-0035/02-xquery-operators.html

2.4 fn:data
-----------

1. REWRITE entire section as described in:
   http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Nov/0391.html

This text incorporates changes for nodes with complex type of mixed
content:

  fn:data($srcval as item*) as atomic value*

  The fn:data function takes a sequence of items and returns a
  sequence of atomic values.

  The result of fn:data is the sequence of atomic values produced by
  applying the following rules to each item in $srcval:

    If the item is an atomic value, it is returned.

    If the item is a node, fn:data returns the typed value of the
    node, as defined by the accessor function dm:typed-value defined
    for that kind of node in [XQuery 1.0 and XPath 2.0 Data Model].

    If the item is a comment, document, namespace,
    processing-instruction, or text node, then its typed value is
    equal to its string value, as an instance of xdt:untypedAtomic.

    If the item is an attribute node with type annotation
    xs:anySimpleType, then its typed value is equal to its string
    value, as an instance of xdt:untypedAtomic. The typed value of any
    other attribute node is derived from its string value and type
    annotation in a way that is consistent with XML Schema validation,
    as described in [XQuery 1.0 and XPath 2.0 Data Model].

    If the item is an element node whose type annotation
    denotes a complex type of empty content, then its typed value
    is equal to the empty sequence.

    If the item is an element node whose type annotation is xs:anyType
    or denotes a complex type of mixed content, then its typed value
    is equal to its string value, as an instance of xs:untypedAtomic.

    If the item is an element node whose type annotation denotes a
    simple type or a complex type of simple content, then its typed
    value is derived from its string value and type in a way that is
    consistent with XML Schema validation, as described in [XQuery 1.0
    and XPath 2.0 Data Model].

    If the item is an element node whose type annotation denotes a
    complex type with complex content (i.e., a type that permits
    subelements), fn:data raises a type error.

    [ Ed note: The typed-value accessor returns an empty sequence when
      applied to an element node with complex type of comple content,
      whereas fn:data() raises a type error, because type errors are a
      characteristic of the language, not the data model. ]

************************************************************************
XQuery 1.0: An XML Query Language
W3C Working Draft 15 November 2002
http://www.w3.org/TR/xquery/

and

XPath 2.0
W3C Working Draft 15 November 2002
http://www.w3.org/TR/xpath20/

2.3.2 Typed Value and String Value
----------------------------------

1. ADD definition of fn:data() as given above following:

  The typed value and string value for each kind of node are defined
  by the dm:typed-value and dm:string-value accessors in [XQuery 1.0
  and XPath 2.0 Data Model].

  The normative definitions are in the [XQuery 1.0 and XPath 2.0 Data
  Model] and is repeated here for convenience:

*****************************************************************************
XQuery 1.0 and XPath 2.0 Formal Semantics
W3C Working Draft 15 December 2002
http://lists.w3.org/Archives/Member/w3c-archive/2003Jan/0033.html

7.2.5 The fn:data function
--------------------------

1. This section is entirely rewritten to align with new semantics.

Introduction

  The fn:data function converts a sequence of items to a sequence of
  atomic values.

Notation

  Infering the type for the fn:data function is done by applying the
  fn:data function as a Filter, using the same approach as for the
  XPath steps.

    statEnv |- fn:data on Type1 : Type2

Static Type Analysis
--------------------

  The general rule for the function fn:data is to apply the filter
  [fn:data on] to the prime type of its argument type, then apply the
  quantifier to the result:

                 statEnv |- Expr : Type
          statEnv |- [fn:data on] prime(Type) : Type1
  ----------------------------------------------------
  statEnv |- fn:data(Expr) :  Type1 o quantifier(Type)


  The rules for the [fn:data on] filter always take a prime type
  (i.e., a union of item types) as an argument.

  When applied to none, [fn:data on] yields none.

    ---------------------------------
    statEnv |- [fn:data on] none : none


  When applied to the union of two types, [fn:data on] is applied to
each
  of the two types.  The resulting types are combined into a factored
  type.  This rule is necessary because [fn:data on] may return a
sequence
  of atomic types.


             statEnv |- [fn:data on] Type1 : Type3
             statEnv |- [fn:data on] Type2 : Type4
    ------------------------------------------------
    statEnv |- [fn:data on] Type1 | Type2 :
      prime(Type3 | Type4) o quantifier(Type3 | Type4)

  When applied to an atomic type, the [fn:data on] filter simply
  returns the atomic type:

                   Type <: xdt:anyAtomicType
               ---------------------------------
               statEnv |- [fn:data on] Type : Type

  When applied to comment, processing instruction, text, and document
  node types, the [fn:data on] filter returns xdt:untypedAtomic.

   Type <: comment | processing-instruction | text | document
  -----------------------------------------------------------
       statEnv |- [fn:data on] Type : xdt:untypedAtomic

  When applied to attribute node types with type annotation
  xs:anySimpleType or element node types with type annotation
  xs:anyType, the [fn:data on] filter returns xdt:untypedAtomic.

  statEnv |- AttributeType static lookup (of type xs:anySimpleType)
  -----------------------------------------------------------------
     statEnv |- [fn:data on] AttributeType : xdt:untypedAtomic

  statEnv |- ElementType static lookup (of type xs:anyType)
  -----------------------------------------------------------------
     statEnv |- [fn:data on] AttributeType : xdt:untypedAtomic

  When applied to an attribute type with any type annotation other
  than xs:anySimpleType, the [fn:data on] filter returns the attribute's
  simple type.

  statEnv |- AttributeType static lookup (of type TypeName)
             not(TypeName = xs:anySimpleType)
  statEnv |- (of type TypeName) expands to Type
  ----------------------------------------------------------
     statEnv |- [fn:data on] AttributeType : Type

  When applied to an element type whose type annotation denotes a
  simple type or a complex type of simple content or a complex type of
  empty content, the [fn:data on] filter returns the element's simple
  type.

     statEnv |- ElementType static lookup TypeReference
     statEnv |- TypeReference expands to Type
                 Type <: (Type1, Type2)
                 Type1 <: AttributeType*
                Type2 <: xs:anySimpleType
  ----------------------------------------------------------
          statEnv |- [fn:data on] ElementType : Type2

  When applied to an element type whose type annotation denotes a
  complex type of mixed content, the [fn:data on] filter returns
  xdt:untypedAtomic.

     statEnv |- ElementType static lookup (of type TypeName)
statEnv.typeDefn(TypeName) => define type TypeName Derivation? Mixed {
Type1? }
-------------------------------------------------------------------------------
        statEnv |- [fn:data on] ElementType : xdt:untypedAtomic

  The [fn:data on] filter is not defined on any element type whose
  type annotation denotes a complex type of complex content and
  therefore raises a static error.

Dynamic Evaluation
------------------

The dynamic semantics of fn:data() are specified in [2.4 fn:data] of
[XQuery 1.0 and XPath 2.0 Functions and Operators].

Actual Resolution

Decision by: xpath-tf on 2003-02-11 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Feb/0121.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)

Proposal accepted.

451. FS-Issue-0108: Principal node types in XPath

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Michael Kay

Description

There is a known bug in the formal semantics which does not deal properly with principal node types. This bug should be resolved based on some semantics previously proposed by Phil Wadler.

Actual Resolution

Decision by: fs-editors on 2002-05-30

The bug in the semantics of XPath has been fixed in the current version of the document. See #FS-sec_steps.

452. FS-Issue-0109: Semantics of order by

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: Jerome

Description

The precise semantics of order by is still open issue.

Proposed Resolution

1) The dynamic semantics of order by will not be formally specified. Instead the following text will be added to the appropriate FS section:

The dynamic semantics of order by is not formally specified. Formally
specifying order by may be done with the addition of tuples in the data
model and of operations on tuples. We believe this addition would add
much complexity to little benefit. The XQuery 1.0 document contains
enough information about the semantics of order by that can be used for
implementation purposes.

2) The satic semantics of order by will be specified. Here is how:

* Normalization:

The order by is normalized as an order by close in the single inner-most for or let clause. For instance:

for $x in //a,
    $y in //b
order by $x+$y
return
  $x

is normalized to

for $x in //a return
 for $y in //b
   order by $x+$y
     return $x

* Static typing:

The order by clause in a single for loop is statically typed as follows:

statEnv |- Expr1 : Type1
statEnv.varType($x : Type1) |- Expr2 : Type2
Type2 <: anySimpleType
statEnv.varType($x : Type1) |- Expr3 : Type3
--------------------------------------------
for $x in Expr1 order by Expr2 return Expr3

Actual Resolution

Decision by: xquery on 2003-05-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0024.html)

Proposal accepted.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

453. FS-Issue-0110: Semantics of element and attribute constructors

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome

Description

The precise semantics of element constructors is still an open issue.

Actual Resolution

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

Closed following the semantics of element constructors agreed at the December f2f meeting.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

454. FS-Issue-0111: Semantics of “instance of ... only”

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The "instance of" expression allows an optional "only" modifier. The use case for such a modifier is based on named typing, while the XQuery semantics is currently based on structural typing. It is not clear what the semantics of the "only" modifier under structural typing should be and how it can be supported.

Actual Resolution

Decision by: fs-editors on 2002-05-30

XQuery does not support only anymore.

455. FS-Issue-0112: Typing for the “typeswitch” default clause

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Jerome

Description

There is an asymetry in the typing for the default clause in typeswitch vs. the other case clauses. This results in a less precise type when the default clause can be applied.

It would be nicer to be able to have the type be more precise, like for the other case clauses.

The technical problem is the need for some form of negation. I think one could define a "non-common-primes" function that would do the trick, but I leave that as open for now until further review of the new typeswitch section is made.

Actual Resolution

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 resolves this issue.

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

Reaffirming decision.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

456. FS-Issue-0113: Incomplete specification of type conversions

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Not all the fallback conversion rules are specified yet in section #FS-sec_type_conversions. All the remaining rules in the fallback conversions table must be specified.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. There is no more XPath type conversions, and this is in fact subsumed by [FS-Issue-0178: Semantics of XPath 1.0 compatibility].

457. FS-Issue-0114: Dynamic context for current date and time

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome

Description

The following components dynamic contexts have no formal representation yet: current date and time.

Related question: where are these context components used?

Actual Resolution

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

Add current date and time in the Dynamic Environment.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

458. FS-Issue-0115: What is in the default context?

Locus: formal-semantics Cluster: Language Priority: 1 Status: decided
Originator: Jerome

Description

What do the default namespace and type environments contain? I believe at least the default namespace environment should contain the “xs”, “fn” and “op” prefixes, as well as the default namespaces bound to the empty namespace. Should the default type environment contain wildcard types?

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decided to accept the "Processing Model" Proposal which addresses this issue.

The "spreadsheet" contains a list of the items.

459. FS-Issue-0116: Serialization

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome

Description

Serialization of data model instances, and XQuery results is still an open issue.

Actual Resolution

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

Serialization is implemented in the data model.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

460. FS-Issue-0117: Data model constructor for error values

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome

Description

The [XPath/XQuery] data model supports an error value, but there is no constructor for it. Currently the formal semantics is using the notation dm:error() to create an error value. Should there be some function(s) in the XQuery 1.0 and XPath 2.0 Functions and Operators document to create error values?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. There is no error value in the data model. There is now an F&O function fn:error().

461. FS-Issue-0118: Data model syntax and literal values

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Phil Wadler

Description

Phil suggests the data model should support primitive literals in their lexical form, in which case no explicit dynamic semantic rule would be necessary.

More generally, should the data model support a constructor syntax?

Actual Resolution

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

The corresponding syntax is going to be implemented in the formal semantics.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

462. FS-Issue-0119: Semantics of op:to

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The binary operator “to” is not defined on empty sequences. The XQuery 1.0 and XPath 2.0 Functions and Operators document says operands are decimals, while the XQuery document says they are integers. What happens when Expr1 > Expr2?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Resolved by the current definition of F&O op:to().

463. FS-Issue-0120: Sequence operations: value vs. node identity

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The XQuery 1.0 and XPath 2.0 Functions and Operators document provides only one function for union (intersect, etc.) of sequences of nodes and values. The semantics is very different for node only and value only sequences. The semantics is undefined for heterogeneous sequences. Should we have two union (intersect, etc.) functions, one for nodes, and one for values?

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Value based sequence operations are in appendix of F&O as user-defined functions.

464. FS-Issue-0121: Casting functions

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome

Description

The XQuery 1.0 and XPath 2.0 Functions and Operators document does not provide any function for casting, just a table and casting rules. Wouldn't it be preferable to either have an explicit function to normalize to? This relates to Issue 17 in the XQuery 1.0 and XPath 2.0 Functions and Operators document.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

F&O now has casting functions.

465. FS-Issue-0122: Overloaded functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Denise Draper

Description

Some XQuery 1.0 and XPath 2.0 Functions and Operators functions are overloaded. How to deal with overloaded built-in functions in the Formal Semantics is still an open issue.

Actual Resolution

Decision by: fs-editors on 2002-10-30

overloaded (built-in) functions have distinct entries in the static and dynamic function environment.

466. FS-Issue-0123: Semantics of /

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: FS Editors

Description

Some of the semantics of the root expression / is still an open issue. For instance, what should be the semantics of '/' in case of a document fragment (I.e., created using XQuery element constructor).

Actual Resolution

Decision by: xquery on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0161.html)

Decision by: xsl on 2003-02-20 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0091.html)

Recommendation to close: the semantics of '/' is defined properly in the FS document submitted before the last f2f meeting and aligned with the other documents.

Close issue with no change to documents.

467. FS-Issue-0124: Binding position in FLWR expressions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

The only way to bind position() is through implicit operations. It would be useful and cleaner to also have a way to bind position in a sequence explicitely. The FS editors proposed several syntax for such an operation, one of these syntaxes look like “for $v at $i in E1 return E2” which modifies the for expression to bind a variable “$i” to the position in sequence “E1” explicitely.

Actual Resolution

Decision by: fs-editors on 2002-10-30

FLWR expressions now support an 'at $i' optional variable binding to the position within the input sequence. This is used to describe the semantics of position() in path expressions.

468. FS-Issue-0125: Operations on node only in XPath

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

Generally steps may operate on nodes and values alike; the axis rules only can operate on nodes (NodeValue). Is it a dynamic error to apply an axis rule on a value?

More generally, the XQuery document states that XPath operates on nodes only. Where that restriction should be applied is an open issue.

Actual Resolution

Decision by: fs-editors on 2002-10-30

The November 4th working draft fixes XPath normalization rules so that imposing sorting by document order is done correctly. Sorting by document order fails when the sequence contains items which are note nodes.

469. FS-Issue-0126: Semantics of effective boolean value

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: FS Editors

Description

Some of the semantics of effective boolean value is still an open issue.

Actual Resolution

Decision by: fs-editors on 2002-10-30

EBV is aligned with the fn:boolean() function.

470. FS-Issue-0127: SequenceType limitations

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: FS Editors

Description

Should the SequenceType production allow the following: fs:atomic, fs:numeric, fs:UnknownSimpleType ?

The formal semantics makes use of several built-in types which are not in XML Schema: fs:numeric, fs:atomic, and fs:UnknownSimpleType. These types are necessary for the specification of some of XPath type conversion rules, and will be accepted without raising an error.

Actual Resolution

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

Numeric not to be added, the other types are already handled. No change to documents.

471. FS-Issue-0128: Casting based on the lexical form

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The XQuery/XPath spec says : "If an operand is an untyped simple value (...), it is cast to the type suggested by its lexical form." It is not clear how to define the semantics for this.

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. Casting does not depend on lexical form anymore.

472. FS-Issue-0129: Static typing of union

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Michael Rys

Description

What should be the semantics of arithmetics expressions over unions. Right now, it would raise a dynamic error. Do we want to raise a static error?

Should operators and functions consistenly with respect to typing?

With the current semantics in Section 4.5 expr1 + expr2 raises a static type error if (e.g.) expr1 has type string and expr2 has type integer. It raises only a dynamic error, if expr1 has type (string | integer) and expr2 has type integer, and expr1 actually evaluates to a string. An alternative would be that this raises also a static error, because it cannot be guarantueed to succeed on all instances.

Proposed Resolution

For user-defined functions there is no issue and the current static typing rules work fine.

There is an issue about static typing for built-in overloaded functions (arithmetic and comparison operators). In that case, the following algorithm is proposed:

If one or both of the types of the operands are a union, static typing is performed for each par of item types in the union. If any of the cases raises a static type error, the whole static typing raises a static type error. Otherwise each resulting static type is unioned to form the final result type.

Here are examples for the expression (E1 + E2) in the case of various input types:

     E1 : int and E2 : int
then E1 + E2 : int

     E1 : float and E2 : int
then E1 + E2 : float

those cases did not change. In case there is a union:

     E1 : (float | int) and E2 : int
then E1 + E2 : (float | int)

since both cases (int + int) and (float | int) could occur.

E1 : (float | int) and E2 : (int | string)

raises a static error since (int + string) raises a static error.

Actual Resolution

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

Proposal accepted.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

473. FS-Issue-0130: When to process the query prolog

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome

Description

The query prolog needs to be processed before the normalization phase. This is not reflected yet in the processing model.

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decided to accept the "Processing Model" Proposal which addresses this issue.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

474. FS-Issue-0131: Boolean node test and sequences

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Michael Rys

Description

The current semantics for boolean node tests makes it “true if the expression is a sequence that contains at least one node and error if the sequence contains no node”. This is inefficient to implement. Some alternative semantics have been proposed.

Actual Resolution

Decision by: fs-editors on 2002-10-30

Boolean value of sequence now independ from whether it is nodes-only.

475. FS-Issue-0132: Typing for descendant

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Peter Fankhauser

Description

The current static typing for descendant is still under review and the inferences rules in that version are probably containing bugs.

Actual Resolution

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decided to accept the "Simplified typing" proposal in Simplified typing for XPath steps, which solves this issue.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

476. FS-Issue-0133: Should “to” also be described in the formal semantics?

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Michael Kay

Description

The current semantics of the op operator is using the op:to function from the XQuery 1.0 and XPath 2.0 Functions and Operators document. Should it be defined formally?

Mike Kay suggests the following definition: [A to B] => if A=B then (A) else (A, A+1 to B)

Actual Resolution

Decision by: xquery on 2002-12-11 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0317.html)

No change to document. op:to is described in the F&O document like other functions and operators.

477. FS-Issue-0134: Should we define for with head and tail?

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Michael Kay

Description

Mike Kay proposes to use the following recursion to define the dynamic semantics of for:

[for $x in () return E2] => ()
[for $x in SEQ return E2] =>
(let $x := head(SEQ) return E2, for $x in tail(SEQ) return E2)

Unfortunately head and tail are not define in XQuery 1.0 and XPath 2.0 Functions and Operators right now.

Actual Resolution

Decision by: xquery on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0161.html)

Decision by: xsl on 2003-02-20 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0091.html)

FS Editors decided this was not the way to do it - it would interfere with the non-deterministic definition of XQuery.

Close issue with no change to documents.

478. FS-Issue-0135: Semantics of special functions

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Michael Kay

Description

The current semantics does not completely cover built-in functions. Some functions used in the Formal semantics, or some functions from the XQuery 1.0 and XPath 2.0 Functions and Operators document need additional semantics specification.

Actual Resolution

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

Ashok has posted a list of functions for which we need special typing rules: http://lists.w3.org/Archives/Member/w3c-query-editors/2003Feb/0027.html

It is now editorial just to implement those typing rules in the formal semantics document.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

479. FS-Issue-0136: Non-determinism in the semantics

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Some operations, such as logical operations and quantified operations are not deterministics ("early-out" semantics allowing not to evaluate all of the expressions). The formal semantics cannot capture the non-determinism in those operations.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft describes non deterministic semantics.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

480. FS-Issue-0137: Typing of input functions

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: subsumed
Originator: Jerome Simeon

Description

Static typing for the input functions input, collection, and document is still undefined.

Actual Resolution

Subsumed by: input-and-schema-validation.

481. FS-Issue-0138: Semantics of Schema Context

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: Jerome Simeon

Description

The semantics of Schema Context types in the SequenceType production is still an open issue.

Actual Resolution

Issue resolved by implementing in the Formal Semantics the revised rules for matching an element or attribute name in a schema context path as posted by Jonathan in: http://lists.w3.org/Archives/Member/w3c-query-editors/2003Oct/0112.html.

The following sections implement the rules: Specification of schema context in [7.1.2 Context is] and in [7.2.4 Element and attribute type lookup].

In particular, the rule for element matching is:

element(SchemaContextPath ElementName) matches a given element node if:

* the name of the given element node matches the ElementName, and:

* type-matches(ST, AT) is true, where ST is the type of the element declaration that is associated with the element named ElementName in the context identified by SchemaContextPath. (This may be either a locally declared element or a top-level element.)

Decision by: xquery on 2003-10-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0002.html)

Decision approved.

Decision by: xsl on 2003-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0003.html)

Decision approved.

482. FS-Issue-0139: Type equivalence rules

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Michael Rys

Description

Should we add back equivalence rules for types (e.g., T1** == T1* or (T1 | T1) == T1). They are useful in practical implementations (e.g., to print an infered type or reduce complexity of infered types), and could be added in an appendix.

Actual Resolution

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

Decided to add back equivalence rules.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

483. FS-Issue-0140: Dependency in normalization and function resolution

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Michael Rys

Description

The normalization of functions calls depends on the function signature. But you cannot gather the function signature for built-in functions without knowing the type of the parameters.

Actual Resolution

Decision by: fs-editors on 2002-10-30

the dependencies on the static/dynamic environment of the normalization/analysis/evaluation phases is now in order (even if not always explicit).

484. FS-Issue-0141: Treatment of nillability and xsi:nil

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Michael Rys

Description

Nillability on an element declaration indicates that content of the corresponding element can be empty. The current data model preserves the xsi:nil attribute and this is used in the semantics at the type level. An alternative design would be to remove the xsi:nil attribute and add a 'nillable' marker in the schema component in the data model. This might be helping when we perform updates.

Actual Resolution

Decision by: xpath-tf on 2002-12-17 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2002Dec/0259.html)

Guided by Jerome the following was decided:

Assume: an element of type T may be nillable. Another element of type T may not be nillable.

There is a Bug in language book re. type matching. Element with nil='true' does not have content according to the given type.

Question 1 - Yes 10 Abstain 1, Recorded No from Vassilis

Question 4 - Yes (unanimous) Do not know Vasillis votes.

Question 3 - nil marker in datamodel and keep xsi:nil (both) Votes:1, 0, 8 MRys abstains as he wants update case clarified.

Question 2 - Not relevant due to Yes answer to 4.

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

Decided to accept Jerome's proposal in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Dec/0352.html.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

485. FS-Issue-0142: Treatment of xsi:type in validation

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: XQuery Editors

Description

The treatment of xsi:type in the formal semantics differs from the one specified in the XQuery and XPath documents. The XQuery and XPath documents indicate that validation is performed by serializing the data model value with newly created xsi:type attributes, then removing those xsi:type attributes after validation. The semantics of 'erases to' as described in the formal semantics document is not creating any xsi:type attributes. The semantics of 'annotate as' as described in the formal semantics document is not removing any xsi:type attributes.

Actual Resolution

Decision by: fs-editors on 2002-10-30

[XPath/XQuery] document and formal semantics document now treat xsi:type in the same way, taking them into account during validation, but never adding or removing those attributes.

486. FS-Issue-0143: Support for PI, comment and namespace nodes

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: FS Editors

Description

The [XPath/XQuery] type system does not currently support PI nodes, comment nodes and namespace nodes.

Actual Resolution

Decision by: xpath-tf on 2003-05-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0018.html)

Close by adding "namespace node type" to type system for XPath 2.0 only (not to XQuery 1.0). Action Jerome to determine how to add such a type for XPath only.

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Proposal accepted. It was also decided not to add it to "SequenceType".

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

487. FS-Issue-0144: Representation of text nodes in formal values

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jonathan Robie

Description

Formal Values described in section #FS-sec_values represents either text nodes for well-formed documents or values for validated documents. Do we need to support a dual representation with both text nodes and values in the formal semantics?

Actual Resolution

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

The formal semantics will keep the current formalism for values which uses either atomic values or text, but not both. The current version is easier to read and understand.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

488. FS-Issue-0145: Static typing of path expressions in the presence of derivation by extension

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The current static type analysis rules for Step expressions is broken in the presence of derivation by extension. This bug is impacting section #FS-sec_steps.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft fixes the static semantics of path expressions in the presence of derivation by extension.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

489. FS-Issue-0146: Support for substitution groups

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The formal semantics document gives a semantics of substitution groups. This is not aligned with the XQuery document. Support for substitution group in XQuery is still an open issue.

Note that this issue is related to the typing of substitution groups, and should be distinguished from the question about whether we need expressions in the language that operate on substitution groups.

Actual Resolution

Decision by: fs-editors on 2002-10-30

Type matching in XQuery is aligned with the formal semantics and takes substitution groups into account.

490. FS-Issue-0147: What should be the type annotation in the data model for anonymous types?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

It is not clear what should be the type annotation in the data model for anonymous types. The mapping from the PSVI to the data model and the formal semantics document need to be aligned.

Actual Resolution

Decision by: fs-editors on 2002-05-30

XQuery does not support only anymore.

491. FS-Issue-0148: Validation of an empty string against a string list

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The formal semantics assumes that the result of validating an element with empty content or with an empty text node against a list of strings is the empty sequence, not the empty string. Is that consistent with XML Schema?

Proposed Resolution

I think XML Schema is clear that validating and empty element validated against a list type yields an empty element in the PSVI and therefore an empty element in the data model. In the formal semantics that corresponds to validating the content of the element to result in an empty sequence.

I think this issue should be closed and that the current Formal Semantics documents is correct here.

Actual Resolution

Decision by: xquery on 2003-02-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0242.html)

JS's proposal ACCEPTED. No changes to the document.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

492. FS-Issue-0149: Derivation by extension in XQuery

Locus: formal-semantics Cluster: Language Priority: 1 Status: decided
Originator: Phil Wadler

Description

If type u is derived from type t by extension, then the formal semantics document specifies that type u may appear wherever type t is expected. It is not clear what the XQuery document says on this point.

Proposed Resolution

The relevant text in the XQuery document can be found in Section 2.4.2.1, "SequenceType Matching", under the description of "ElemOrAttrType", Rules 1 and 2.

Rule 1 describes matching by type-name. It says "The match is successful only if the given element or attribute has a type annotation that is the same as the required type or ... derived from the required type."

Rule 2 describes matching by element-name. It says "The match is successful only if the name of the given element or attribute is equal to the required name or ... derived from the required name, and if the element or attribute has been validated."

Rules 1 and 2 do not distinguish between derivation by extension or by restriction, so by implication they apply to both kinds of derivation. I do not believe that Rules 1 and 2 were intended to apply to derivation by list or union. I believe this should be clarified by changing "derived" to "derived by restriction or extension" in Rules 1 and 2.

I believe that this change will close Issue 492.

Actual Resolution

Decision by: xquery on 2003-01-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0502.html)

Decided to accept proposal and thus resolving issue.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

493. FS-Issue-0150: May the content of a text node be the empty string?

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Phil Wadler

Description

May the content of a text node be the empty string? None of the formal semantics, the datamodel, or the XQuery document addresses this point.

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Add a constraint that a text node must consist of at least one character information items to the Data Model.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

494. FS-Issue-0151: Should type annotations be optional?

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Phil Wadler

Description

The formal semantics and the data model both state that the type annotation is required, while the XQuery document says that it is optional.

Actual Resolution

Decision by: fs-editors on 2002-10-30

Type annotations are mandatory under pure named typing.

495. FS-Issue-0152: What is the type of the input functions?

Locus: formal-semantics Cluster: Priority: 1 Status: subsumed
Originator: FS Editors

Description

What are the (static) types for the input functions: document(), collection(), and input()?

Actual Resolution

Decision by: fs-editors on 2002-28-11

Subsumed by #schema-types-from-input-documents

496. FS-Issue-0153: Support for lax and strict wildcards

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: FS Editors

Description

The Formal Semantics does not currently model lax and strict wildcards. The mapping in Section 7, only describes how XML Schema wilcards with the 'skip validation' semantics are imported into the XQuery Type System.

Actual Resolution

Decision by: xquery on 2003-10-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0083.html)

Updated editorial notes to state that "lax" and "strict" wildcards are ignored in mapping. Updated "supported feature table" in Section 8.1.1.

497. FS-Issue-0154: Semantics of =>

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The Formal Semantics of the => operator is not defined.

Actual Resolution

Decision by: fs-editors on 2002-07-26

The => operator has been removed from the language.

498. FS-Issue-0155: Common primes for incomparable types

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The common-prime auxiliary type function does not deal with “incomparable” types, (i.e., types for which there is a non empty intersection, but subtyping does not hold -- e.g., element a | element b vs. element b | element c). One way to resolves that issue would be to re-introduce a limited form of intersection (i.e., returning true if the intersection is not empty instead of full-fledge intersection) and use it within the definition of common-prime.

Actual Resolution

Decision by: fs-editors on 2002-10-30

New version of common prime based on pure named typing is simpler and works for all kinds of items.

499. FS-Issue-0156: Casting and validation

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

Validation from text to simple type performs an operation similar to casting. Should validation of simple type values and 'cast as' in [XPath/XQuery] be aligned?

Actual Resolution

Decision by: xquery on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)

Close issue since Functions and Operators answers this question.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

500. FS-Issue-0157: Support for wildcard namespaces

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The Formal Semantics does not currently model wildcard namespaces.

Actual Resolution

Decision by: xquery on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0161.html)

Decision by: xsl on 2003-02-20 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0091.html)

Recommendation to close: the Formal Semantics does now describe wildcard namespaces.

Close issue with no change to documents.

501. FS-Issue-0158: Support for XML Schema groups

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

How to support XML Schema groups during the schema import phase is not clear. If the mapping is based on the XML Schema syntax, then it should be handled durin the mapping phase. Should we have support for XML Schema groups in the XQuery type system?

Actual Resolution

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

XML Schema groups are mapped in the type system. There is no need for a syntax for schema group in the type system.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

502. FS-Issue-0159: Element and attribute declarations in the static context

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The [XPath/XQuery] static context only contains type definitions, but no global element and attribute declarations. Element and attribute declarations are necessary to give the semantics of SequenceTypes.

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

This work has been done editorially and thus this issue can be resolved.

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

Alignment has been implemented in the latest XQuery document.

503. FS-Issue-0160: Collations in the static environment

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The Formal Semantics does not represent collations in the static environment. Should it?

Actual Resolution

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

Add collations in the Dynamic Environment.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

504. FS-Issue-0161: Type promotion in Atomization

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

Should the normalization rules for atomization also perform type promotion?

Actual Resolution

Decision by: fs-editors on 2002-10-30

Type promotion is done in function calls.

505. FS-Issue-0162: How to describe the semantics of built-in functions

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

The semantics of function calls assumes the function environment returns an [XPath/XQuery] expression which describes the function body. This only works for user-defined functions, but not for external functions or built-in functions.

Actual Resolution

Decision by: fs-editors on 2002-10-30

built-in functions given special rule that refers to "application" which in turn refers to FO, datamodel, etc.

506. FS-Issue-0163: Normalization of XPath predicates

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

The semantics of XPath predicates relies on whether they are applied on forward or reverse axis. The semantics of predicates applied on arbitrary expressions is not correctly specified.

Actual Resolution

Decision by: fs-editors on 2002-10-30

The November 4th working draft fixes XPath normalization rules for XPath predicates on arbitrary expressions. The semantics in that case is as for forward axis.

507. FS-Issue-0164: Coalescing text nodes in element constructors

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Don Chamberlin

Description

The semantics does not model how text nodes are coalesced in element or constructors. Whether it should be described or left out for the data model is still an open issue. Impact on this operation on the static semantics is still an open issue.

Actual Resolution

Decision by: fs-editors on 2002-07-26

The data model element constructor coalesces text nodes.

508. FS-Issue-0165: Namespaces in element constructors

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Denise Draper

Description

We do not supply either namespaces or schema-components to the constructor. We cannot do these things because of the bottom-up nature of element construction: we do not, in general, know either the namespaces in scope or the validation-associated schema type until this element has been "seated" in some containing element (and so on recursively).

Proposed Resolution

"A namespace node is created corresponding to the namespace used in the name of the element and in the name of each of its attributes."

And add the following note:

"Note: The set of namespace nodes does not need to be minimal, in that an implementation may choose to provide different prefixes for the same namespace URI on the same element (see example N1)."

The reason is that this gives implementation more freedom to generate the namespace declarations efficiently while not really changing the information content. Note that it does not say that you can loose the prefix of the active namespace node, only, that you may be able to add more.

The example N1 would be:

Let $in be bound to
<a:b xmlns:a="foo"/>

Consider the query (assuming that we copy all namespace nodes):

<r:a xmlns:r="foo">{$in}</r:a>

The data model at a minimum should have the following namespace nodes:

{foo}a has xmlns:r="foo" and the xml namespace

{foo}b has xmlns:r="foo" and the xml namespace as a minimum, but an implementation may chose to also provide xmlns:NS="foo" and serialize the result as

<r:a xmlns:r="foo"><NS:b xmlns:r="foo" xmlns:NS="foo"/></r:a>

Actual Resolution

Decision by: xquery on 2003-06-04 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jun/0039.html)

The copy case will be decided separately later.

Proposal adopted subject to following changes:

1. Delete: unless there is already a namespace node for this namespace URI.

2. Add: The namespace node need not be created if there is already a namespace node for this namespace URI on the given element.

The editors may also choose to change the placement of the namespace node in the example:

<r:a xmlns:r="foo" xmlns:NS="foo"><NS:b xmlns:r="foo" /></r:a>

The editors may also choose whether to include a negative example along these lines:

<p xsi:type="xs:integer">3</p>

The resulting p element will have three namespace nodes:

xmlns:NS0="<http://www.w3.org/2001/XMLSchema-instance>http://www.w3.org/2001/XMLSchema-instance"
xmlns:xml="<http://www.w3.org/XML/1998/namespace>http://www.w3.org/XML/1998/namespace"

And then point out that validation will obviously fail. This example is important for people to understand that the statically active/passive namespaces are dealt with before validation occurs.

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)

Decision for the "copy case".

It was decided to stay with status quo; always copy all in-scope namespaces when constructing elements.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

XQuery only.

509. FS-Issue-0166: Static typing for validate

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

Although validate should always return a typed value, there is no way to do static analysis for it, since the type against which it is validated cannot be known at static type (it depends on the result of evaluation for the input expression).

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Ignore content's type. Assign static type using element name and validation context.

May raise type error if element content will NEVER validate successfully.

<fixbrain>{ validate { input()/fixsink/person } }</fixbrain>

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

510. FS-Issue-0167: Is validate working on sequences?

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

We have not yet reached consensus on the semantics of validate for all sequences. In particular:

1. Can validate be applied to a sequence, or only to a single item?

2. Can validate be applied to any item? Some believe that it should apply only to elements and document nodes - the two kinds of nodes for which it is well defined - and raise an error if other items are encountered. Others believe that validate should validate elements and document nodes, returning other items without change. Should an attribute node be validated? Note that XML Schema does not define stand-alone validation for attribute nodes.

We need to carefully consider the usage scenarios in which validation might be applied to sequences or items that are not elements or document nodes to determine which behavior is most desirable.

Should validate work on sequences of nodes, or only on a single node?

Proposed Resolution

At today's Query telcon, we discussed the semantics of the validate expression. We need to decide whether it applies to a sequence, or only to a single node. We also need to define its semantics for various kinds of nodes (and for atomic values, if they occur in a validated sequence).

Most people agreed that the validate operator, applied to an attribute node, should raise an error. This is because we rely on the XML Schema specification for the semantics of validation, and XML Schema does not specify how to validate a stand-alone attribute node.

For text, comment, and PI nodes and atomic values, some people believe that validate should raise an error, and others believe that validate should simply return the original node or value unchanged. We did not reach a consensus on this.

If validate is defined to operate on a sequence, the sequence may contain some items for which validate is well-defined and others for which it is not well-defined. In order for users to invoke validate on a sequence, they will first need to filter the sequence to keep only items for which validate is well-defined. If users need to do this work anyway, they might as well invoke validate expressions only on the individual items for which validation is well-defined. This was considered a strong argument for not allowing sequences to be passed to a validate expression.

At the end of the discussion, a consensus seemed to be emerging around the following points:

(1) The operand of validate must be a single element node or a single document node (anything else raises a type error).

(2) The semantics of validate on an element node are as defined in Section 3.13 ("Validate Expressions") of the current language document.

(3) The semantics of validate on a document node are as defined in Karun's proposal, http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0015.html, approved by the Query working group on 2/12/03.

Actual Resolution

Decision by: xquery on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)

Proposal accepted. It was rejected to allow validation of attribute nodes, even though Schema defines the semantics.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

XQuery only.

511. FS-Issue-0168: Sorting by document order

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

There is no way in [XPath/XQuery] to express sorting by document order as a core expression. Since order by is doing atomization, there is no way it can be used to express sorting by document order.

Actual Resolution

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

No change to documents. A user can write E/self::node() if he wants to sort by document order.

512. FS-Issue-0169: Conformance Levels

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

[XPath/XQuery] supports several conformance levels. Whether the formal semantics need to distinguish those conformance levels is an open issue. If yes, how to distinguish those conformance levels in the formal semantics is an open issue.

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decided to accept the "Processing Model" Proposal which addresses this issue.

There are no changes required to the documents.

513. FS-Issue-0170: Imprecise static type of constructed elements

Locus: formal-semantics Cluster: Static typing Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Implementation of Alternative 1 means that the static type for constructed elements and attributes is very imprecise. E.g., the type of {(1,2,3)} is element a { xs: anyType }. See remark by Denise in section on element constructors for possible fix.

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Applies to literal element constructor and computed element constructor with literal name

Raise type error if element content will NEVER validate successfully.

If static typing is enabled, it is a static type error if the type of the content of the element is NOT a subtype of type declared for the element. Untyped content treated "liberally".

Parallels semantics of static typing rules for function calls.

type plumber { element name of type xs:string }
type surgeon { element name of type xs:string }
element fixsink { element person of type plumber }
element fixbrain { element person of type surgeon }

<fixbrain>{ input()/fixsink/person }</fixbrain>

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

XQuery only.

514. FS-Issue-0171: Raising errors

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

The semantics of raising errors in [XPath/XQuery] is not formally specified.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft describes the semantics of errors.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

515. FS-Issue-0172: Element constructors aligned with XSLT

Locus: formal-semantics Cluster: Language Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

Should the semantics of element constructors be aligned with XSLT?.

Actual Resolution

Decision by: xquery on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0161.html)

Decision by: xsl on 2003-02-20 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0091.html)

Recommendation to close. There is a semantics for element constructors in XQuery.

Close issue with no change to documents.

516. FS-Issue-0173: Typeswitch and type substitutability

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: XSL Working Group

Description

It seems that some examples of typeswitch with xs:anySimpleType might break type substitutability.

Proposed Resolution

The required changes include the new (simpler!) normalization and typing
rules below, plus:

  1. A new formal-semantics function fs:cast-untypedAtomic, which
     takes two arguments and :

     a. If the first argument is the empty sequence, returns the empty
        sequence.

     b. If first argument is untypedAtomic, and

        b1. If the second argument is untypedAtomic, returns the first
            argument cast to string;

        b2. Else if the second argument is numeric, returns the first
            argument cast to double;

        b3. Otherwise, returns the first argument cast to the type of
            the *second* argument.

     c. Otherwise, returns the first argument, unchanged.

     Thus fs:cast-untypedAtomic encapsulates the implicit coercion
     semantics of the arithmetic and general comparision operators.

     The "generic" signature of fs:cast-untypedAtomic is:

       fs:cast-untypedAtomic ($v1 as xdt:anyAtomicType?, $v2 as
       xdt:anyAtomicType?) as xdt:anyAtomicType?

     The specific type rules for fs:cast-untypedAtomic are below.

  2. New signatures for the overloaded (op:numeric-OP) operators such
     that they are all defined on the empty sequence.  If either
     argument is the empty sequence, these operators return the
     empty sequence.

     E.g., here's the new signature for op:numeric-add (similar
     signatures for the other op:numeric-op functions):

     op:numeric-add($operand1 as numeric?, $operand2 as numeric?) as
numeric?

New normalization rules:
~~~~~~~~~~~~~~~~~~~~~~~
Given the changes above, here are the normalization rules for the plus
and the general less-than operators.  (The general rules for any
arithmetic or general comparison operator are similar -- it's just
easier to explain by example).

Plus:

  [Expr1 + Expr2]_Expr   ==
    let $e1 := fn:data ( [Expr1]_Expr ) return
    let $e2 := fn:data ( [Expr2]_Expr ) return
    let $v1 := fs:cast-untypedAtomic ($e1, 1.0e0) return
    let $v2 := fs:cast-untypedAtomic ($e2, 1.0e0) return
      op:numeric-add($v1, $v2)

Note that arithmetic operators always cast an untypedAtomic argument
to a double -- the call to fs:cast-untypedAtomic above performs this
cast.

Less-than:

  [Expr1 < Expr2]_Expr   ==
    some $v1 in fn:data( [Expr1]_Expr ) satisfies
    some $v2 in fn:data( [Expr2]_Expr ) satisfies
      let $v1' := fs:cast-untypedAtomic($v1, $v2) return
      let $v2' := fs:cast-untypedAtomic($v2, $v1) return
        op:less-than($v1', $v2')

Note that general comparison operators always cast an untypedAtomic
argument to the type of the other argument -- the call to
fs:cast-untypedAtomic performs this cast.

Static type rules for fs:cast-untypedAtomic:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Rule (a) above:

              statEnv |- Expr1 : ()
  ----------------------------------------------------
  statEnv |- fs:cast-untypedAtomic(Expr1, Expr2) : ()

Rule (b1) above:

  statEnv |- Expr1 : Type1   statEnv |- Type1 <: xdt:untypedAtomic
  statEnv |- Expr2 : Type2   statEnv |- Type2 <: xdt:untypedAtomic
  -----------------------------------------------------------------
  statEnv |- fs:cast-untypedAtomic(Expr1, Expr2) : xs:string

Rule (b2) above:

  statEnv |- Expr1 : Type1   statEnv |- Type1 <: xdt:untypedAtomic
statEnv |- Expr2 : Type2   statEnv |- Type2 <: (xs:decimal | xs:float |
xs:double)
----------------------------------------------------------------------------------
     statEnv |- fs:cast-untypedAtomic(Expr1, Expr2) : xs:double

Rule (b3) above:

      statEnv |- Expr1 : Type1   Type1 <: xdt:untypedAtomic
                 statEnv |- Expr2 : Type2
statEnv |-  not(Type2 <: xdt:untypedAtomic | xs:decimal | xs:float |
xs:double)
--------------------------------------------------------------------------------
          statEnv |- fs:cast-untypedAtomic(Expr1, Expr2) : Type2

Rule (c) above:

             statEnv |- Expr1 : Type1
           not(Type1 <: xdt:untypedAtomic)
   ---------------------------------------------
   fs:cast-untyped-atomic(Expr1, Expr2) : Type1

Static type rules for typeswitch:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

The static rules for typeswitch are now very simple. We type each case
expression and take the union of these types:

     statEnv |- Expr0 : Type0
     statEnv |- Type0 [case] case Variable1 as SequenceType1 return
Expr1 : Type1
        ...
     statEnv |- Type0 [case] case Variablen as SequenceTypen return
Exprn : Typen
     statEnv |- Type0 [case] default Variablen+1 return Exprn+1 :
Typen+1

--------------------------------------------------------------------------------
     statEnv |-
       (typeswitch (Expr0)
        case Variable1 as SequenceType1 return Expr1
        ...
        case Variablen as SequenceTypen return Exprn
        default Variablen+1 return Exprn+1)
     : Type1 | ... | Typen+1


The type of the case clauses is inferred based on the CaseType, independently
of the typeswitch expression type.

             CaseType = [ SequenceType ]_sequencetype
        statEnv + varType(Variable : CaseType) |- Expr : Type1
-------------------------------------------------------------------------
statEnv |- Type0 [case] case Variable as SequenceType return Expr : Type1


The type of the default branch is inferred based on the typeswitch expression
type.

        statEnv + varType(Variable : Type0) |- Expr : Type1
      ------------------------------------------------------------
      statEnv |- Type0 [case] default Variable return Expr : Type1

Actual Resolution

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)

Proposal accepted resolving this issue.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

517. FS-Issue-0174: Semantics of 'element foo of type T'

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

When using the form 'element foo of type T', should 'foo' be a globally declared element in the in-scope schema or not? Should there be constraints on which type T is allowed? The language document assumes foo is globally declared and T is a restriction of the type of foo. The formal semantics does not make that assumption.

Actual Resolution

Decision by: fs-editors on 2002-10-30

Sequence type matching in the language book is aligned with the formal semantics in the case in the case of 'element foo of type T'. 'T' must be a globally defined name. 'foo' is just considered as a local element name.

518. FS-Issue-0175: Static typing for atomization, effective boolean values, and function arguments.

Locus: formal-semantics Cluster: Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

Currently, normalization rules for atomization, effective boolean values, and function arguments are not type safe. They cannot raise a static errors, but can only raise dynamic errors. This makes the static semantics much less usable.

Actual Resolution

Decision by: fs-editors on 2002-10-30

atomization and function parameters are now strictly typed, EBV uses the all-accepting fn:boolean function.

519. FS-Issue-0176: Type of document node

Locus: formal-semantics Cluster: Typing Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

What should the type of a document node be? Should a document node be described by a type name?

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

SequenceType extended to include document-node(ElementTypeTest)

Formal types extended to include document { Type }

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

520. FS-Issue-0177: Coercion between untyped and atomic values

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: decided
Originator: Jerome Simeon

Description

Function calls, arithmetics expressions, etc. should cast untyped data to values. This is not currently formally specified.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft describes coercion between untyped and atomic values in function calls.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

521. FS-Issue-0178: Semantics of XPath 1.0 compatibility

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The semantics is not specified in the case the XPath 1.0 compatibility flag is on.

Actual Resolution

Decision by: fs-editors on 2003-01-12 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jan/0097.html)

Dec. FS working draft describes xpath 1.0 backward compatibility semantics.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

522. FS-Issue-0179: Primitive function applications

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The semantics of primitive function applications must be defined precisely.

Actual Resolution

Decision by: xquery on 2003-02-05 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0161.html)

Decision by: xsl on 2003-02-20 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Feb/0091.html)

Recommendation to close: the semantics of primitive functions is defined in the F&O document. There is no need to define their semantics in the Formal Semantics.

Close issue with no change to documents.

523. input-and-schema-validation: input(), collection(), document(); validation semantics

Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: XPath TF

Description

What are the semantics of the functions input(), collection(), document(), and the implicit context that binds variables to documents with respect to schema validation.

Interactions and Input

Cf. Support for schema-less and incompletely validated documents

Cf. How are documents for which validation has failed processed?

Actual Resolution

Decision by: xpath-tf on 2003-07-08 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jul/0032.html)

Closed by the addition of the "Statically known documents/collections" and "Accessible documents/collections" to the static and dynamic contexts and the addition of the constraints in Section 2.2.5. of the current document.

ACTION XPATH-124-01 to verify the semantics of fn:document() and fn:doc() w.r.t. failed validation.

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision accepted, with a change of "Accessible" to "Available" in order to avoid confusion with "WAI".

524. schema-plural-data-types: Plural datatypes different from Singular *?

Locus: xpath Cluster: type semantics Priority: 1 Status: decided
Originator: XPath TF

Description

Is there any semantic difference between eg NMTOKEN* and NMTOKENS? Statically? Dynamically?

Actual Resolution

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

To solve issues 316 and 524 we need to do eliminate three constructor functions from F&O, and integrating with the changes described in the message: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0021.html.

This was agreed.

525. FS-Issue-0180: Static context accessible from the dynamic context

Locus: formal-semantics Cluster: Semantics Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

The formal semantics states that the static context is available from the dynamic context at run time. This should only be the case for part of the static context. Moreover certain parts of the dynamic context must be updated appropriately from during the dynamic evaluation (e.g., namespaces).

Proposed Resolution

My recollection is that Mary implemented some changes in the internal FS document. I think we never reported that change to the working group.

I'm not sure how to deal with this one. Maybe Mary can explain the change and the issue be closed?

Actual Resolution

Decision by: fs-editors on 2003-04-07 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Apr/0059.html)

The new FS working draft specifies that the whole of the static context is available from the dynamic context.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0013.html)

Resolution endorsed.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

526. static-semantics-anySimpleType-untypedAtomic: Semantics for anySimpleType and untypedAtomic

Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: XPath TF

Description

1. If you statically infer xs:anySimpleType, can you error if the expected type is a subtype or do you handle it as xdt:untypedAtomic at runtime?

2. If you statically infer xdt:untypedAtomic, can you recast into expected type statically?

Actual Resolution

Decision by: xquery on 2003-04-09 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Apr/0175.html)

Decision by: xpath-tf on 2003-05-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0018.html)

The two questions are answered in the current draft of the formal semantics.

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xsl on 2003-05-22 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003May/0063.html)

It was also noted that the Datamodel needs some changes due to this.

527. static-typing-index-expressions: Static typing of XPath index expressions

Locus: formal-semantics Cluster: types Priority: 1 Status: resolved
Originator: Algebra Editors

Description

Typing for XPath predicate expressions of the form E1[Integer] is not precise (often of the form ItemType* instead of ItemType or ItemType?). Should we have specific typing rules for XPath predicate expressions of the form E1[Integer], or is the use of 'type relief' functions, as described in: http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2002Nov/0161.html sufficient?

Actual Resolution

Decision by: xquery on 2003-01-22 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jan/0435.html)

The general static type of the general expression:

Expr1[Expr2]

Is (assuming normalization has taken place)

TYPE{Expr1[Expr2]} == IF TYPE{Expr2} <: numeric THEN TYPE{Expr1}

Decided that if Expr2 is a literal number, then do cardinality reduction, otherwise don't.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-09-11 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Sep/0042.html)

Resolution endorsed.

528. text-constructor-empty-sequence: Semantics of text constructor on empty sequence

Locus: xpath Cluster: semantics Priority: 1 Status: decided
Originator: XPath TF

Description

Semantics of text constructor on empty sequence: should it return empty sequence or raise an error?

Actual Resolution

Decision by: xquery on 2003-02-26 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Feb/0459.html)

Change the language document, adding that a text node constructor on empty sequence returns the empty sequence.

529. node-identity-modeling: Node identity in the formal semantics

Locus: xquery Cluster: constructor-expr Priority: 1 Status: decided
Originator: Phil Wadler

Description

The fs currently does not model node identity. The position of the formal semantics editors is that a formal semantics need not model everything. So it is not absolutely required that we model node identity, though it would be desirable for us to do so, not least because a clear description of node identity may help clarify the semantics of update. The formal semantics should include a mode of node identity if time permits.

Actual Resolution

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

Decided to define node identity in the Formal Semantics. Required some editorial work to be done.

530. default-validation-mode: Default default validation mode

Locus: xquery Cluster: validation Priority: 1 Status: decided
Originator: Jim Melton

Description

The adoption of implicit validation of element constructors specified that syntax be provided to allow query authors to specify the validation mode (skip, lax, or strict) for a given constructor, as well as syntax to allow query authors to specify in the query prolog the default validation for all constructors in the query. If neither syntax is used, there must be a "default default" mode. That mode can be specified by the XQuery specification itself, or it can be made implementation-defined to account for varying implementation requirements. Specifying the default mode in the XQuery specification would seem to improve interoperability, but there are strong user requirements that are best satisfied by allowing the XQuery implementation determine the default mode based on customer needs and other factors. In order to improve interoperability, XQuery authors can specify their default mode in their XQuery prologs.

Actual Resolution

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)

This issue is an example of a more generic issue: how should the default value be determined for the parts of the static context and evaluation context that are not explicitly assigned values in the query prolog? I believe that this generic issue should be addressed by a well-defined and uniform policy that is documented in the language books. I propose the following resolution:

(1) Section 2.1.1, "Static Context": Add the following sentence just before the bullet-list of context items (XQuery only): "Any part of the Static Context that is not assigned a value in the Query Prolog may be assigned a default value by the XQuery implementation."

(2) Section 2.1.2, "Evaluation Context": Add the following sentence just before the bullet-list of context items: "Any part of the Evaluation Context may be assigned an initial value by the XPath/XQuery implementation."

Proposal accepted.

531. type-copied-subelement: Should discard the type of copied subelement

Locus: xquery Cluster: type-semantics Priority: 1 Status: decided
Originator: Michael Rys

Description

Currently element construction untypes all simple content (untypedAtomic) but preserves the type of subnodes.

This is seen as inconsistent by some and thus an issue.

The proposed resolution would be to erase the type for any node under the new element (make it element/attribute of type xs:anyType/xdt:untypedAtomic or potentially (and preferably) untypedComplex for elements).

Actual Resolution

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

Element construction should behave like skip validation and erase the type of all subnodes.

532. sequence-type-path-alignment: Alignment between path expressions and sequence types

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: Phil Wadler

Description

Should there be better alignment between path expressions and sequence types?

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Proposal in issue #SequenceType-problems accepted resolving issue.

533. automatic-coersion-strict-or-not: Strict static typing for automatic coercion of untyped atomic to atomic values

Locus: formal-semantics Cluster: type-semantics Priority: 1 Status: resolved
Originator: Mary Fernandez

Description

Should static typing for automatic coercion of untyped atomic to atomic values be strict or not? For instance:

Should the following function call:

define function f($x as xs:integer)  ....

let $x := <a>1</a> return f($x/node())

be allowed or not?

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

In principle, xdt:untypedAtomic is typed liberally rather than conservatively. That is, it is made statically well-typed whenever possible.

Thus, addition of xdt:untypedAtomic to xs:integer is well-typed and has type xs:double. Comparing xdt:untypedAtomic to any other type is well-typed.

This resolution applies only to the general comparison (=, <), not to value comparison (eq, lt), so that the latter retains transitivity.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

534. function-calls-and-expected-type: Semantics of function calls and notion of "expected type"

Locus: formal-semantics Cluster: type-semantics Priority: 1 Status: decided
Originator: Kristoffer Rose

Description

While the "expected type" is well defined for user and non-overloaded standard functions, it is not so for the overloaded built-in functions. For general [XQuery/XPath] use (without XPath 1.0 compatibility flag) we must ensure that each overloaded argument is either always atomic or non-atomic so it is unambiguous for every function argment which of the two normalization choices to pick. With XPath 1.0 compatibility flag some other solution must be found as several functions are now overloaded with, e.g., numeric and non-numeric types allowed for the same argument.

Actual Resolution

Decision by: fs-editors on 2003-05-01 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003May/0007.html)

Decision by: xquery on 2003-05-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0024.html)

Clarification to be added in FS document:

Furthermore notice that the normalization is only well-defined when it is guaranteed that overloading is restricted to atomic types with the same quantifier.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0003.html)

Decision approved.

535. lexical-state-tables: Lexical state tables

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: Scott Boag

Description

Should the state tables be removed or made non normative?

Actual Resolution

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

Decided to keep them normative.

536. datamodel-infoset-types: Data model to infoset mapping and type information

Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Michael Rys

Description

When mapping from a data model to the infoset (as it is used in the definition of validate), we need to loose any type properties that may be part of the data model. In particular, this means that the infoset will not populate the attribute's type property. We need to make sure that the documents reflect this.

Actual Resolution

Decision by: xpath-tf on 2003-05-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0018.html)

Mary checked the data model to infoset mappings for elements and attributes and neither conveys their type annotations.

Thus close with no change to documents.

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision ratified.

537. imported-schemas-used-function-signatures: What happens to imported schemas that are used in function signatures?

Locus: xquery Cluster: modules Priority: 1 Status: decided
Originator: Michael Rys

Description

If a function module imports a schema and uses it in the function signature, is the import of the function module implicitly importing the schema components needed by the function signatures?

Example:

The module says:

import schema namespace foo = "abc"
namespace f = "xyz"
define function f:foo($x as foo:bar) as xs:int { ... }

Does

import module namespace f = "xyz"

import the schema and one only needs to bind a prefix to the schema namespace or does the schema have to be explicitly imported?

Actual Resolution

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)

The adopted module proposal implicitly resolves this issue. An example showing this clearly needs to be added.

538. keyword-extensions: Can (and should) keyword extensions be allowed in XQuery by equipping them with a namespace prefix?

Locus: xquery Cluster: extensions Priority: 1 Status: decided
Originator: Peter Fankhauser

Description

Can (and should) keyword extensions be allowed in XQuery by equipping them with a namespace prefix?

Example:

declare namespace my = http://example.com/myextensions

for $e in document ("employees.xml")//employee
order by $e/lastname my:fastorder
return $e

The advantage of this is that namespaces are a well-established concept for extending vocabularies, and different prefixes may be used for multiple extensions (my:fastorder vs. real:fastorder). The possible disadvantage may be that namespaces are regarded as too clumsy for this purpose.

Note that using namespaces for keyword extensions does not appear to provide a generic mechanism to make the XQuery grammar extensible (one cannot simply allow a sequence of Qnames at arbitrary places without running into ambiguities). An implementation providing some extensions still needs to modify the XQuery grammar accordingly. However this also holds for the other two options, unless "x-" is added to the reserved keywords.

Interactions and Input

Cf. External Objects

Cf. XQuery Extension Mechanisms

Actual Resolution

Decision by: xquery on 2003-03-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0232.html)

The decision for #extension-mechanism also covers this issue.

539. cast-untypedAtomic-backward-compatibility-mode: Semantics of fs:cast-untypedAtomic in backward compatibility mode

Locus: formal-semantics Cluster: types Priority: 1 Status: decided
Originator: Jerome Simeon

Description

What should be the semantics of fs:cast-untypedAtomic in the XPath 1.0 backward compatibility mode?

Actual Resolution

Decision by: fs-editors on 2003-05-01 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003May/0007.html)

Decision by: xquery on 2003-05-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0024.html)

Resolved by the addition of the following section: [Section 6.1.4 The fs:convert-simple-operand function] which deals with XPath 1.0 backward compatibility.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

540. static-semantics-input-unions: How does the static semantics works in the case where the input types are unions?

Locus: formal-semantics Cluster: types Priority: 1 Status: decided
Originator: Jerome Simeon

Description

How does the static semantics works in the case where the input types are unions? (union propagation) For instance, what is the static type obtained for an input (untypedAtomic | int) + (float) [the expected result is (double | float)].

Actual Resolution

Decision by: fs-editors on 2003-05-01 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003May/0007.html)

Decision by: xquery on 2003-05-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0024.html)

Resolved by the current text in [Section 4.1.4 Function Calls].

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

Decision by: xsl on 2003-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0003.html)

Decision approved.

541. static-type-empty-error: Should it be a static error if an expression other than () has type empty?

Locus: formal-semantics Cluster: type-semantics Priority: 1 Status: decided
Originator: static typing task force

Description

Motivation: This catches common errors such as $x/e when there is no e element.

Interactions and Input

Cf. Queries with Invalid Content

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Yes this should be a static error.

542. type-of-well-formed: What should be the type of an attribute or element that is well-formed but not validated, or is validated in skip mode?

Locus: formal-semantics Cluster: type-semantics Priority: 1 Status: resolved
Originator: Phil Wadler

Description

Currently, attributes are given type xs:anySimpleType and elements are given type xs:anyType. In order to do a better job of static typing for well-formed data, it might be better to give attributes type xdt:untypedAtomic and to give elements type xdt:anyUntyped (where the latter is a newly minted type).

Actual Resolution

Decision by: xpath-tf on 2003-05-14 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0037.html)

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Unvalidated elements from well-formed docs and skip-validated elements labeled with [xdt:untypedAny].

Relationships with other types:

xdt:untypedAny <: xs:anyType

xdt:untypedAtomic <: xdt:anyAtomicType <: xs:anySimpleType

Benefits

* Can distinguish unvalidated/skip-validated elements from validated elements

* Aligns with type annotations for unvalidated/skip-validated attributes (xdt:untypedAtomic).

NB: xdt:untypedAny is lousy name.

Decision by: xquery on 2003-05-28 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0177.html)

> Status: Michael Rys believes we need to consider what data() does in this case. Skipped at F2F meeting.

Proposal:

Two corrections below: First data will never return a list type, but an atomic typename with an occurance indicator. Second, the atomization of element(xs:anyType) needs to raise a type error now since it could be a complex element with non-mixed complex content (note: this cannot occur with dynamic typing, since no instance will be of type element(xs:anyType) anymore).

So the new rules should be

   data(attribute(xs:anySimpleType))   has type  xdt:anyAtomicType*
   data(element(xs:anySimpleType))     "         xdt:anyAtomicType*
   data(element(xs:anyType))           raises a type error

   data(attribute(xdt:untypedAtomic))  has type  xdt:untypedAtomic
   data(element(xdt:untypedAtomic))    "         xdt:untypedAtomic
   data(element(xdt:untypedAny))       "         xdt:untypedAtomic

Also we need to add the following definition:

1.3.x xdt:untypedAny

The abstract datatype xdt:untypedAny is a child of xs:anyType and serves as a special type annotation to indicate the type of element nodes that have not been validated by a XML Schema or have received an instance type annotation of xs:anyType in the PSVI. This datatype cannot be used in [XML Schema Part 1: Structures] type declarations; nor can it be used as a base for user-defined atomic types. It can be used in the [XQuery 1.0: An XML Query Language] SequenceType production to define a required type (for example in a function signature) to indicate that only an element with untyped content is acceptable. This datatype resides in the namespace http://www.w3.org/2003/03/xquery-datatypes and is considered to be non-atomic.

Agreed: as written.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

543. xpath-matching-substitution-groups: How can a path expression match elements in the substitution group of a given element?

Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: Jonathan Robie

Description

How can a path expression match elements in the substitution group of a given element?

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Proposal in issue #SequenceType-problems accepted resolving issue.

544. xpath-matching-types: How can a path expression match nodes of a given type?

Locus: xpath Cluster: type-semantics Priority: 1 Status: decided
Originator: Jonathan Robie

Description

How can a path expression match nodes of a given type?

Actual Resolution

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-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Decision by: xquery on 2003-03-06 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0269.html)Joint meeting

Proposal in issue #SequenceType-problems accepted resolving issue.

545. implicitly-element-attribute: Are XS element/attribute declarations implicitly added to the schema context?

Locus: xpath Cluster: types Priority: 1 Status: resolved
Originator: Processing Model TF

Description

Are XS element/attribute declarations implicitly added to the schema context?

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decided to accept the "Processing Model" Proposal which addresses this issue.

They are not added.

546. conformance-levels: Are there more processing model options that could make sense as consistent features and thus as conformance levels?

Locus: xpath Cluster: conformance-levels Priority: 1 Status: postponed
Originator: Processing Model TF

Description

Are there more processing model options that could make sense as consistent features and thus as conformance levels? What types can these "predefine" in the static context? Do these options have the desired/expected interoperability characteristics?

Actual Resolution

Decision by: xquery on 2003-10-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0002.html)

Paul proposes to mark as postponed, but continue the discussion in the WG, including at the F2F. The WG agreed to dispose of this issue as Paul suggested.

547. grammar-declare: Use "declare" for declarations

Locus: xquery Cluster: syntax Priority: 1 Status: decided
Originator: Michael Rys

Description

G3. Section 4.3 Validation Declaration

[118]     ValidationDecl

   ::=     <"validation" "lax"> |  <"validation" "strict"> |
<"validation" "skip">

Add declare keyword in order to align with general declaration syntax

Proposal:

<"declare" "validation" ("lax" |  "strict" |  "skip")>

G4. Section 4.4 Xmlspace Declaration

[104]     XMLSpaceDecl

   ::=     <"declare" "xmlspace"> "=" ("preserve" |  "strip")

drop "=" in order to align with general declaration syntax (this is an option and not a value like in namespace declarations)

Proposal:

<"declare" "xmlspace"> ("preserve" |  "strip")

G5. Section 4.5 Default Collation

[105]     DefaultCollationDecl

   ::=     <"default" "collation" "="> StringLiteral

drop "=" and add "declare" in order to align with general declaration syntax.

Proposal:

<"declare" "default" "collation"> StringLiteral

Actual Resolution

Decision by: xsl on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

(1) use of a declare keyword accepted without objection

(2) remove "=" in 3 places

548. lexical-rules: Lexical Rules: states normative?

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: Michael Rys

Description

G6. Section A.1.2 Lexical Rules

Current wording: "The lexical contexts and transitions between lexical contexts is described in terms of a series of states and transitions between those states."

Make all states non-normative except those that are needed for XML construction, string literal and XQuery context.

Actual Resolution

Decision by: xsl on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

They are normative. They define things not defined elsewhere. An implementation doesn't need to work in terms of lexical states; they are a declarative way to specify the results.

549. namespace-constructor: Computed namespace-constructor

Locus: xquery Cluster: namespaces Priority: 1 Status: decided
Originator: XQuery WG

Description

Is the following construction is a valid XQuery expression or not:

element foo:bar {
  attribute a1 {"foo"},
  attribute xmlns:foo {"urn1"},
  element e1 {"goo"}
}

The XML Query WG has decided to forbid the above construct by defining an explicit constructor for namespaces in computed constructor syntax, and to disallow the use of computed attribute constructors for declaring namespaces. The WG also believes that there should be a constructor for comments.

The WG also agreed that the namesapce constructor should have a syntax parallel to that of attribute constructors, be restricted to constant namespace prefixes and URLs, and should appear first in the children of an element constructor, as in the following example:

element foo:bar {
     namespace test { "urn1" },
     attribute a1 {"foo"},
     element e1 {"goo"}
}

The above example is precisely equivalent to:

<foo:bar xmlns:test="urn1">{
      attribute a1 {"foo"},
      element e1 {"goo"}
}</foo:bar>

Proposed Resolution

The proposal itself is quite simple:

Syntax:

ComputedElementConstructor    ::=    (<"element" QName "{">
      |  (<"element" "{"> Expr "}" "{")) NamespaceCList? ExprSequence?
"}"

NamespaceCList ::= ComputedNamespaceConstructor (","
ComputedNamespaceConstructor)* ","

ComputedNamespaceConstructor ::= (<"namespace" NCName "{"> StringLiteral
"}"

A NamespaceCList may appear as the first expressions in the ExprSequence of an element constructor, using either computed or XML element constructor syntax. It is syntactically impossible for ComputedNamespaceConstructors to appear in any other context.

Semantics:

If two ComputedNamespaceConstructors in the same element declare the same prefix, a type error is raised. A namespace declared using a ComputedNamespaceconstructor is in scope within the constructed element, including the name of the element itself.

If the name of an attribute in a computed attribute constructor begins with the string "xmlns", a type error is raised.

In an ElementConstructor, if an attribute in an AttributeList begins with the string "xmlns", then it is treated as a namespace declaration, and is equivalent to a computed namespace constructor that declares the same prefix and URI.

Actual Resolution

Decision by: xquery on 2003-03-12 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Mar/0232.html)

Adoption of the proposal.

550. comments-location: Location of Comments

Locus: xquery Cluster: syntax Priority: 1 Status: decided
Originator: Don Chamberlin

Description

XQuery 1.0 states "Comments may be used anywhere that ignorable whitespace is allowed, and within element content." I am trying to understand what that means and whether it is still true.

What does this mean?

<a>A (:big:) cat</a>

Does (:big:) get recognized as a comment and removed from the element content, and then the two surrounding pieces of text get coalesced into a single text node with the content "A cat"?

Or does the tag get a text node containing the string "A (:big:) cat"? If this is not the case, then how would I construct an element that actually has this content?

Have we thought carefully about whether we want comments to be recognized inside tag content? In most other ways, element-content is treated much like a string. I believe that comments are not recognized inside strings, right? Is this a strong argument for not recognizing comments inside element content? Is there any argument for recognizing them?

Actual Resolution

Decision by: xsl on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Comments to be allowed everywhere ignorable whitespace can occur in an XQuery expression.

551. constructor-functions-user-types: Constructor functions for unprefixed user defined types

Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: XSL WG

Description

We state that there is (implicitly) a constuctor function in the static context for each user defined type. How do you refer to such a constructor function for a non-prefixed type?

Actual Resolution

Decision by: xpath-tf on 2003-05-14 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0037.html)

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

No technical change to documents.

Add note (in Functions and Operators) indicating that to construct types defined in null namespace, use "cast as" expression.

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Wording reviewed and accepted.

552. processing-instruction-quotes: Should the quotes in processing-instruction("...") be optional?

Locus: xpath Cluster: syntax Priority: 1 Status: decided
Originator: XSL WG

Description

Do we want to make the quotes in processing-instruction() optional? It is always a string literal and we have introduced element() and attribute() that already do not look like functions...

Proposed Resolution

Here are the changes that would be needed to implement this change in the current Working Draft of XQuery:

1. Change the ProcessingInstruction Test production to:

[123] ProcessingInstructionTest ::= <"processing-instruction" "("> NCName ")"
        |   <"processing-instruction" "("> StringLiteral? ")"

2. Replace the following text:

 >    4. processing-instruction(N ) matches any processing instruction
 >       node whose name (called its "PITarget" in XML) is equal to N,
 >       where N is a StringLiteral. Example:
 >       processing-instruction("browser") matches any processing
 >       instruction directed to the application named browser.

Here is the replacement text:

4. processing-instruction(N) matches any processing instruction
   node whose name (called its "PITarget" in XML) is equal to N,
   where N is an NCName. Example: processing-instruction(browser)
   matches any processing instruction directed to the application
   named browser.

   Note:

    For backwards compatibility with XPath 1.0, the argument to a
    processing instruction may also be a string literal,
    surrounded by quotes,
    e.g. processing-instruction("browser"). This string literal
    must be an NCName, or a static error is raised.

Actual Resolution

Decision by: xpath-tf on 2003-05-06 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0018.html)

Proposal accepted.

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Proposal accepted.

553. dynamic-errors-reported-statically: Rules for reporting dynamic errors statically

Locus: xpath Cluster: errors Priority: 1 Status: decided
Originator: XSL WG

Description

Under what circumstances can a dynamic error detected early be reported statically, for example if it occurs in code that might not be executed. A host language may determine this, e.g. an <xsl:if> construct.

Interactions and Input

Cf. XPath/XQuery's current semantics greatly interferes with optimization

Actual Resolution

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

As just a minor addition to the doc is needed and the other addition is the raise of the following other error: a constructor function with a constant argument that is not in the lexical space it was decided to close this issue.

Decision by: xpath-tf on 2003-07-08 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jul/0032.html)

Adopted the actual text in http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jun/0087.html.

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Wording reviewed and accepted.

554. what-is-normative: What is the really normative text?

Locus: xpath Cluster: editorial Priority: 1 Status: decided
Originator: XPath TF

Description

Some normative material in XPath/XQuery specifications occurs in more than one location. The specifications need to be clear which of the replicated material is the unique normative definition to ensure ease of implementation and avoid conflicts.

Proposed Resolution

The language book(s) and the Formal Semantics book define together what the semantics of the XQuery 1.0 and XPath 2.0 languages is.

However, there is often duplication (the language book(s) using English while the FS book uses formal notations), and often one document is more specific than the other (for instance the static typing optional feature is mostly described in the FS document). In addition, despite all our hard work some inconsistencies are probably still lurking. Finally, we need to deal with the question about which part of the documents is going to be normative.

Here is a small proposal, laying out a plan to deal with those issues. This plan was discussed at last week's FS editors call, people liked it, and that I was actioned to write it down.

The proposal

(1) For all expressions in the language, the language book should clearly specify in English prose the dynamic semantics of the expression. This English text will serve as the normative version for the dynamic semantics.

(2) For all expressions, the formal semantics book should have dynamic rules which align with (1) above.

(3) For all expressions in the language, the corresponding section in the language book should point to the corresponding FS section which contain the formal rules.

(4) For all expressions, the formal semantics book should have static rules which specify the static semantics of the language. Those formal rules will serve as the normative version for the static semantics.

This plan will obviously require some significant work on our documents, but we believed this would solve all of our alignment/normative problems and improve the quality of our specifications.

Actual Resolution

Decision by: xpath-tf on 2003-05-14 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003May/0037.html)

Decision by: xsl on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Decision by: xquery on 2003-05-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0176.html)Joint F2F

Accepting this general approach and the details with respect to the Formal Semantics. Similar to be worked out for the

"language books" and Datamodel

"language books" and Functions and Operators

Functions and Operators and Formal Semantics

The links that we will put into the documents need to be bi-directional.

Decision by: xquery on 2003-10-29 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0002.html)

Paul proposes this is Decided. The language document is normative for dynamic semantics; the formal semantics document is normative for static semantics; sequence type matching is normative in both. In other documents, e.g. F&O, the editors have added pointers to normative material.

The WG agreed with Paul recommendation on Issue 554.

555. module-import-fs: Formal Semantics of Module Import

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: active
Originator: fs editors

Description

The semantics of Module Import is not formally specified.

556. variable-definitions-fs: Formal Semantics of Variable Definitions

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: decided
Originator: fs editors

Description

The semantics of Variables Definitions in the XQuery prolog is not formally specified.

Actual Resolution

Decision by: xquery on 2003-10-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0083.html)

Resolved by text in Section 5.8.

Decision by: xsl on 2003-10-23 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0093.html)

Decision noted, no objections.

557. validation-declaration-fs: Formal semantics of Validation Declaration

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: decided
Originator: fs editors

Description

The semantics of Validation Declaration in the XQuery prolog is not formally specified.

Actual Resolution

Decision by: xquery on 2003-10-08 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0083.html)

Resolved by text in Section 5.9.

Decision by: xsl on 2003-10-23 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0093.html)

Decision noted, no objections.

558. FS-allow-PIs-comments: The content of element types should always allow PI's and comment node types

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: decided
Originator: Michael Rys

Description

The content of element types should always allow PI's and comment node types. This is not currently taken into account in the FS document. The best way to deal with that problem is still an open issue. Two possible options are to add PI and comment types during XML Schema import into the XQuery type system (Section 8). Another option is to add PI and comment types during type expansion (judgment expands_to in 7.2.7 Type expansion).

Actual Resolution

Decision by: fs-editors on 2003-05-01 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003May/0007.html)

Decision by: xquery on 2003-05-07 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003May/0024.html)

Fix is in [Section 7.2.6 Type adjustment] which now adds pi and comment types when accessing an element type.

Decision by: xsl on 2003-10-30 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0003.html)

Decision approved.

559. FS-support-new-sequence-type: New Sequence Type needs to be fully implemented in Formal Semantics

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: active
Originator: Michael Rys

Description

The formal semantics of the new form of sequence types is incomplete and is still under work.

560. exactness-type-inference: Exactness of Type Inference

Locus: formal-semantics Cluster: formal semantics Priority: 1 Status: resolved
Originator: Micheal Rys

Description

We currently have a couple of static type inference rules (child, descendent) that preserve the more complex type consisting of interleaf, union and sequence. The question is whether this complexity is really needed.

In many cases (such as the FLWR expression used to define /) we just change the inferred type into prime x quantifier.

If we could just infer prime x quantifier, often our inference rules could be simplified.

So the question becomes: Do we really need the more complex and precise types for performing static type checking?

Actual Resolution

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decided to accept the "Simplified typing" proposal in Simplified typing for XPath steps, which solves this issue.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

561. normativity-external-internal-mapping: Normativity of External Mappings

Locus: xpath Cluster: conformance Priority: 1 Status: decided
Originator: Jonathan Robie

Description

Our specifications describe three mappings between the Query Processing environment and the External Processing environment: (1) the Data Model provides optional mappings from a PSVI or Infoset to a Data Model Instance; (2) the Serialization specification provides optional mappings from a Data Model Instance to serialized XML; (3) the Formal Semantics provides optional mappings from an XML Schema to the In-Scope Schema Definitions.

How normative are these mappings?

The following alternatives seem plausible:

1. The mappings are purely informative.

2. Implementations may choose whether to conform to one or more of these mappings, which will be identified by name.

3. As an aid to conformance testing, implementations are required to support a mode in which these mappings are available as specified.

Are there other alternatives we should consider? What are the relative advantages of these approaches?

Actual Resolution

Decision by: xpath-tf on 2003-07-18 (http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Jul/0092.html)

The mappings are non-normative.

Decision by: xquery on 2003-10-01 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0005.html)Joint telcon

Decision by: xsl on 2003-10-01 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Oct/0005.html)Joint telcon

Mapping (1) is the topic for issue 306:

The normativity of the mapping (and noting that it is only ONE of the ways in which a datamodel can be constructed) is reaffirmed and some adjustments to the text in the Datamodel approved.

562. static-typing-fn-root: What static typing for fn:root?

Locus: formal-semantics Cluster: static typing Priority: 1 Status: decided
Originator: Michael Rys

Description

A: '/' is an important operation in XPath and XQuery and it should have a precise type. This is normalized to 'fn:root(self::node()). This means we need to have a special typing rule for fn:root.

B: Should fn:root($x) be a type error or a dynamic error, if the root node of $x is not a document node?

Some arguments in favor: If the root node is not a document but-let's say-an element node with name a, then it is non-obvious and confusing that /a does not select this element. Erroring would allow us to investigate this issue further and provide a solution at a later date. The current semantics does not. Also, in XPath 1.0, the root node always was a document node.

Possible argument against: You cannot use an absolute path expression starting with / on a data model instance that has no document node as a root node.

Proposed Resolution

B: Suggested resolution: The arguments in favor outweigh the arguments against and thus my proposal is to raise the error.

Proposed Resolution

#1 fn:root statically the same.

#2 implementations can extend the static semantics.

#3 fn:root dynamic semantics stay the same.

Actual Resolution

Decision by: xquery on 2003-06-25 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0031.html)

#1,2 Adopted.

No decision on item #3 pending comment from Michael Rys

Decision by: xquery on 2003-07-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision to decouple fn:root and "/". "/" is an error if there is no document node. Formally:

Expr[/] =
    fs:doc-root(self::node)

Expr[/Expr] =
Expr[fs:doc-root(self::node)/Expr]

define function fs:doc-root($n as node) as document
{
    fn:root($n) treat as document
}

Note that XSL WG will still need to review the proposal before deciding.

Decision by: xsl on 2003-07-16 (http://lists.w3.org/Archives/Member/w3c-xsl-wg/2003Jul/0063.html)

Accepting decisions on #1 and #2.

Decision by: fs-editors on 2003-08-11 (http://lists.w3.org/Archives/Member/w3c-query-editors/2003Aug/0043.html)

Text is in working draft; approved by XQuery WG at 2003-08-06 telcon.

563. static-error-evaluate-dynamically: Is dynamic evaluation performed if error in static analysis?

Locus: xquery Cluster: errors Priority: 1 Status: decided
Originator: Michael Rys

Description

Is the dynamic evaluation phase performed only after successful completion of the static analysis phase or whether it can continue even after a static type error.

Proposed Resolution

Proposed Resolution: allowing to continue after static type error can be considered a dynamic typing implementation with a static typing compiler flag (like C's lint). Reason: You would still need to perform dynamic typing. Such an implementation should be possible but not required or even described by the spec.

Proposed Resolution

Proposed resolution:

In 2.2.3.2 Dynamic Evaluation Phase, change current text:

<current_text> The dynamic evaluation phase is performed only after successful completion of the static analysis phase. </current_text>

to:

<new_text> The dynamic evaluation phase occurs after the static analysis phase only if the static analysis phase does not raise any non-type static errors. <xquery_only> If the Static Typing Feature is in effect, dynamic evaluation occurs only if the static analysis phase does not raise any static (non-type and type) errors. </new_text>

Rationale: In the absence of static typing, all type errors must be detected dynamically. Thus, even if a type error is detected statically, it should not prevent dynamic evaluation. However, when static typing is in effect, *all* type errors are static errors, thus any static error should prevent dynamic evaluation.

This resolution requires that static typing behave as it does in other high-level languages. If an implementor wants to provide a "lint-like" feature, they can do so by optionally reporting type errors during static analysis.

Actual Resolution

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)

Mary's text adopted.

564. schema-import-multiple-times: Loading same schema-component twice

Locus: xquery Cluster: schema-import Priority: 1 Status: decided
Originator: Michael Rys

Description

We currently allow a schema component to be only loaded once into the in-scope schema definitions. If a type, element or attribute having an expanded name as an already loaded type, element or attribute respectively, we have to error regardless of the actual type definition.

Since we now require explicit schema import of the XSD schema but already have predefined the XSD types, we introduced a special case for having to avoid the error. However, this still does not solve the following two problems:

1. Schema import transitively import other imported schemata. Thus if a transitively imported schema is imported more than once, we would have to raise an error

2. In order to provide interoperable queries, one should be able to explicitly import schemata that may be implicitly imported by the XQuery implementation. Again, today that would lead to an error.

Proposed Resolution

If a type, element or attribute has already been loaded, then loading a type, element or attribute respectively with the same expanded name does not lead to an error if it can be determined that they are describing the same type, element or attribute. Note that the inscope schema definition will only contain one entry...

Actual Resolution

Decision by: xquery on 2003-09-03 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Sep/0092.html)

Decided, but pending some editorial work.

565. default-attribute-decl-in-context: XQuery context: default attribute declarations?

Locus: xquery Cluster: context Priority: 1 Status: resolved
Originator: Jerome Simeon

Description

What should be the attribute declaration(s) available by default in the XQuery context?

Actual Resolution

Decision by: xquery on 2003-07-15 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)

Decided to keep status quo and not "pre-declare" attributes (including xml:lang, and xml:space).

566. treat-as-up-down-type-hierarchy: "treat" should work up and down type hierarchy

Locus: xpath Cluster: types Priority: 1 Status: decided
Originator: Michael Rys

Description

Section 3.13.6 Treat

Current wording: "The semantics of treat as type1 (expr2) are as follows:

During static analysis (if the Static Typing Feature is implemented):

type1 must be derived by restriction from the static type of expr2--otherwise, a type error is raised. The static type of the treat expression is type1. This enables the expression to be used as an argument of a function that requires a parameter of type1."

We propose to allow treat to work up and down the type hierarchy.

Reason: Since a supertype always can substitute for a subtype, you get implicit "treat as" from sub to supertypes. Instead of forcing people to write let $x as supertype := subtypevalue, we should also statically allow treat as supertype (subtypevalue).

Actual Resolution

Decision by: xquery on 2003-07-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decision by: xsl on 2003-07-16 (http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Jul/0122.html)Joint meeting.

Decided that the user can tell you exactly what the target type is. If the user is wrong there will be a dynamic error. Thus no (static) restrictions on "treat as" (as you can do everything in two steps anyway...).