Last Call Comments for xquery.

Section 3.1.5 Function Calls
Editorial
Please reword: " parameteror " with " parameter or "

            
DECISION: To leave to the editor
RESOLVED: qt-2004Jan0029-01 closed, fixed editorially
         

Section 2.1.1 Static Context
Editorial
"environmentor" => "environment or"

            
DECISION: To leave to the editor
RESOLVED: qt-2004Jan0152-01 closed, fixed editorially
         

Consider the following schema document and instance:
<xs:schema xmlns:xs="https://www.w3.org/2001/XMLSchema">
 <xs:element name="root">
  <xs:simpleType>
   <xs:restriction base="xs:decimal">
    <xs:annotation>
     <xs:documentation>Always two signif. digits</xs:documentation>
    </xs:annotation>
    <xs:pattern value=".*\..."/>
   </xs:restriction>
  </xs:simpleType>
 </xs:element>
</xs:schema>
<root>3.00</root>
The instance is valid per the schema corresponding to the schema document.
A query which attempted to construct an element including this one
would however fail, as I read the spec., because the serialization
would include <root>3.0</root>, which is invalid per the type.
ht
--
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: https://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

            
Moved to the Data Model cluster.
         

            
Norm: the only resolution I can propose is, sometimes you lose.  Use
format-number if you care about precision.  Section 3.4.1.1 ends with
a paragraph mentioning that pattern facets are not respected during
serialization (last paragraph in the section).
PC: how do we respond to the Schema WG comment?
Norm: we don't know how to address this.  If you do this, your
documents may not be valid after you manipulate the DM instance.
MRys: it's provable that you can't reverse the patterns.
RESOLVED: closed, Norm to reply with the "you lose" paraphrase.
         

The Web Serice Description Language (WSDL) [1] provides a facility for
describing Web services - a WSDL document could be thought of as an
XML description of a set of function signatures.
Some XML Query implementations will very likely support the idea
of calling such functions in XPath expressions.
Would it increase interoperability of such implementations if
one could explicitly associate a namespace prefix with a WSDL
document in the XML Query Prolog?
For example,
    import service cvt at "https://example.org/wsdl/cvt.wsdl";
and then, in the body of the query, one might be able to use
    cvt:convert("F", "C", 23.6)
to convert between temperatures.
An alternative to extending the prolog might be to extend access
to an implementation's underlying URI resolver, so that users
could implement WSDL support in XQuery directly.
However, interoperability and integration between specifications
is important to the W3C.
Liam
[1] Web Services Description Language,
    https://www.w3.org/TR/2003/WD-wsdl20-20031110/
--
Liam Quin, W3C XML Activity Lead, https://www.w3.org/People/Quin/
https://www.holoweb.net/~liam/

            
Status from meeting 201: PENDING. For looking up status of this, note
mispelling.
Paul suggested doing it using an external module which represents
the web service via the module import feature.
RESOLUTION: No changes to the document. Respond to the comment that --it can be done with import module or externally defined functions
plus a layer of software which we do not need to define. Nothing is
needed in the XQuery specification.
Mike presented some issues illustrating that it can not be done
efficiently which he will take to email.
         

This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission, which discharges the promise made in [2].
Regards,
Henry S. Thompson (on behalf of the XML Schema WG)
-------------------------
There is what appears to us an inconsistency between section 3.13
Validate Expressions [1] (repeated in 3.7.1.5 Type of a Constructed
Element) in XQuery itself and section 3.3 Construction from a PSVI [2]
in the Data Model, based on the interpretation placed on the
*validation mode*.
The latter says:
  "The data model supports incompletely validated documents. Elements
  and attributes that are not valid are treated as having unknown
  types."
The former says:
  "If the [validity] property of the topmost element information item
  in this PSVI is not valid, a type error is raised."
In concrete terms this means that starting from e.g. a document +
schema where the document element is not declared, but one or more of
whose descendants are declared, not only can a data model be
constructed, but also it will have useful type information for those
elements, since they will be [validity]='valid' and
   "If the [validity] property exists and is "valid", the type of an
   element or attribute information item is represented by an
   expanded-QName . . ."
In contrast having constructed such a document node in a query
context, the result of validating it will either be a type error (if
*validation mode* is 'strict' or 'lax') or a tree with uniformly
untyped data (if *validation mode* is 'skip').  This change in the
interpretation of 'lax' from the one it is defined to have in XML
Schema not only will confuse users, it is inconsistent with the way
Data Model instances are constructed from PSVIs, and also means that
undeclared elements are treated differently if they are at the
validation root ('lax' has the new meaning) or internal to it ('lax'
means what XML Schema says it means).
We would very much hope that the power and flexibilty reflected in the
detailed reporting of schema validity assessment outcome be available
no only at Data Model construction time, but also via the 'validate'
expression, by bringing the treatment of 'lax' as a *validation mode*
in to line with XML Schema and Data Model construction.
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
[2] https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/1162.html
--
 Henry S. Thompson, HCRC Language Technology Group, University of Edinburgh
                     Half-time member of W3C Team
    2 Buccleuch Place, Edinburgh EH8 9LW, SCOTLAND -- (44) 131 650-4440
            Fax: (44) 131 650-4587, e-mail: ht@inf.ed.ac.uk
                   URL: https://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]

The November draft of the XQuery specification (4.7 Module Import)
says that "Two modules may import each other."  However, the
formal semantics assumes this is not the case, starting with:
5.2 Module Declaration
"We assume that the static-context processing and dynamic-context
processing described in [5 Modules and Prologs] are applied to all
library modules before the normalization, static context processing,
and dynamic context processing of the main module. That is, at the
time an "import module" declaration is processed, we assume that the
static and dynamic context of the imported module is already
available."
So you say "let's fix the formal semantics".  Doable, probably,
but not trivially.  The processing of the module prologue
is done in "declaration order", and cyclic module imports
disallows that.
A module cycle has to be compiled as a unit; you can't separately
compile them.  So they're little more than syntactic sugar.  I think
you could define module cycles by defining module import as
"semi-textually" merging in declarations from the imported module,
renaming the namespace prefixes.  I don't understand schema imports
well enough to know if they would cause complications.  Other
declarations such as base-uri, validation declaration, and default
collation declations probably cause minor complications.  Variables
declarations are the biggest obvious complication.
Note that if a VarDecl omits the TypeDeclaration, the value of
the VarRef is that of its definining expression.  This doesn't
work if there is a cycle between variables, so we'd need to
add rules to disallows such a cycle.  Note that XQuery static
typing is strictly bottom-up; there is no ML-style type unification.
A related issue is that the the formal semantics "looks up" variables
and functions in imported modules by lookup up their namespace
uri in the "module_dynEnv".  Note this doesn't work if there are
multiple modules in the same namespace.  Both formal and informal
semantics are very unclear about the difference between a library
module as a syntactic unit, its namespace, and the result of
elaborating one or more libray module syntax forms with the same uri.
If there may be multiple modules for the same uri, how do you tell
when there is a cycle?  What if there is no location hint in the
module import, or the location hint is an alias (e.g. a symbolic link)
for a previously-imported module?
Separate compilation becomes a lot more complicated, both
definition and implementation, when modules may recursively
import each other.  Find a pre-compiled module is difficult
unless there is a one-to-one mapping between modules and URIs.
Location hints don't help much unless their meaning is standardized,
at least in a non-normative manner.
If two queries are executed, and both import the same library module,
must/should the implementation evaluate the library module's variable
initializations twice, or can it re-use the values from the first query?
It is tempting to think of module-leval variables similar to
C/C++/Java static variables that are initialized when their module is
first loaded, but that may not be the desired semantics.  Consider:
   declare variable $var { fn:current-time() };
I'm sure these issuees can be solved, but it will take time;
better to leave them for version 2.0.
Recommendation for XQuery 1.0:
* Modules may not import each other, directly  or indirectly.
* Only allow a single library module for a given namespace.
* Consider a non-normative recommendation that location specifiers
in import statements be URIs (where relative URIs are resolved
against the importing module's base uri, while defaults to its
"source file name").
* Possibly: Remove the requirement that the fn:current-date,
fn:current-time, and fn:current-dateTime functions if "invoked
multiple times during the execution of a query or transformation,
these functions always return the same result", since that would
preclude an implementation from running library initializers
only once.
Alternative, recommended to be deferred to 2.0:
* Allow modules to import each other, but prohibit static cycles in
definition of variables.  I.e. a variable's defining expression may
not depend on variables or functions that in turn depend on it.  This
restriction should be statically checkable; this avoids the need
for a dynamic check, and it solves the problem of determining the type
of a variable without a type specifier.  Note that a dynamic check for
a cyclic dependency isn't enough if you're doing static typing.
(I suggest allowing implementations without the static typing feature
to defer the cycle check until runtime.)
* We have to define both informally and formally the semantics
of a cycle of module imports.  This is difficult.
* We have to be able to detect a module cycle.  This means we
have to have a concept of "module identity" or "module name".
This is difficult if multiple modules may have the same namespace.
* Remove the restriction that a variable must be defined
before its use, as that is redundant, and the restriction is
meaningless if you have modules that import from each other.
--
	--Per Bothner
per@bothner.com   https://per.bothner.com/

            
++ Jerome: Cyclic imports are hard to specify formally, and we should
drop them in V1.
++ Jonathan: Agrees with Jerome.
++ DC: How exactly is cyclic import defined?
++ Jerome: The graph of modules importing other modules must not contain
any closed cycles. We should not allow Module A to import Module B and
Module B to import Module A.
++ Mike Carey: What is the problem with this?
++ Jerome: Interferes with separate compilation. We don't know where to
start
the compilation process.
++ Liam: Does anyone object to ruling out cyclic import in Version 1?
++ Mike Carey: Yes, I'm concerned that if we rule this out for V1, we may
somehow preclude introducing it in a later version.
++ Jonathan: But if cyclic import is an error in V1, relaxing this error
in a later version would be a compatible change.
++ RESOLUTION:
++ Liam: I hear no objections other than from Mike Carey. I rule that
Per Bothner's issue 2004Mar0013-01 is closed by accepting a restriction
against cyclic modules in V1. Jerome will provide a proposed wording and
Don will include it in the language document with editorial discretion.
Jerome will reflect this decision in the Formal Semantics document.
Mike Carey is encouraged to raise a separate issue if he
discovers some way in which we are placing a limitation on Vnext.
Closing this issue completes Action A-STATA-18.
         

In XPath/XQuery Section 3.1.5, Function Calls, under "Function Conversion
Rules", after atomization, we find the following rule: "Each item in the
atomic sequence that is of type xdt:untypedAtomic is cast to the expected
atomic type." This is not completely specified for certain built-in
functions such as fn:abs() in which the expected parameter type is
"numeric", which includes integer, decimal, float, and double. To complete
the specification, we should insert the following sentence after the rule
cited above: "For parameters of built-in functions where the expected type
is specified as numeric, arguments of type xdt:untypedAtomic are cast to
xs:double."
--Don Chamberlin

            
DECISION: qt-2004Feb1207-01 has been accepted by a previous
decision and already implemented in the July 2004 draft.
         

Dear Colleagues,
This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission.
Regards,
David Ezell (on behalf of the XML Schema WG)
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
XSCH-QL-018 Section 3.13 Validate Expressions
Validate expressions are defined in terms of serialization [3.13].
There are problems with interposing serialization between the data model and
validation, however, and we suggest you return to using a mapping from the data
model to the infoset and defining validation on that instead.
Section [2.2.4] apparently relieves implementations of the necessity of
supporting a serialization interface, but [3.13] requires it through the back
door, and through a mechanism that does not provide the means to provide the
serialization process with the normal serialization parameters.
Serialization depends on casting to xs:string which in turn is defined in terms
of the various type annotations on the data model. There is a certain apparent
circularity here that is confusing, if nothing else.
Interposing a serialization step means that validating a data model that
already has type annotations may cause the validation outcome to be different,
because the serialization rules are different, and some types are not
necessarily serializable. In particular, serialization will fail for QName
nodes with no bound prefix [https://www.w3.org/TR/xslt-xquery-serialization/
section 2]. There may also be edge cases involving simple derived types (in the
schema being used for validation) with pattern restrictions that rule out
certain of the serializations used for data already annotated with a certain
types that would also lead to problems that would not have otherwise arisen.
We suggest decoupling validate from serialization, and instead providing a
mapping from the data model to the infoset and using that as the basis of
validation.  Providing such a mapping will help those who will inevitably
have to create their own mappings, and to some extent mitigate the introduction
of yet another data model.

            
Moved to the Data Model cluster.
         

Dear Colleagues,
This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission.
Regards,
David Ezell (on behalf of the XML Schema WG)
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
XSCH-QL-016 Section 4.8 Variable Declaration
The notion 'circular definitions' or 'circularity' is not well
defined in the spec. The following wording provides a kind of definition:
    If an initializing expression cannot be evaluated
    because of a circularity (for example, it depends on a function
    that in turn depends on the value of the variable that is being
    initialized), a dynamic error is raised.[err:XQ0054]"
It's not quite clear how circularity between modules is determined.
For example, will the variable initialization be successful in case of such
modules:
  module namespace math = "https://example.org/math-functions";
  import module namespace math2 = "https://example.org/math2-functions";
  declare variable $x as xs:integer {$math2:z};
  module namespace math2 = "https://example.org/math2-functions";
  import module namespace math = "https://example.org/math-functions";
  declare variable $y as xs:integer {$math:x};
  declare variable $z as xs:integer {1};

            
Jonathan will reply to Schema.
Related issue: 2004Feb0791-01
This was closed at the MIT face to face.
         

Dear Colleagues,
This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission.
Regards,
David Ezell (on behalf of the XML Schema WG)
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
XSCH-QL-015 Section 3.12.3 Cast
Needs to define a rule for determining static type of a cast expression.
The type specified after the "as" word is expected to be the static type
similar to the definition in "3.12.6 Treat" but the 3.12.3 section lacks
such definition.

            
RESOLVED: reject this comment.
Jerome to reply that we will not make this change because the static
type of an expression is defined in the Formal Semantics docuement, and
cast is based on the dynamic type.
         

Dear Colleagues,
This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission.
Regards,
David Ezell (on behalf of the XML Schema WG)
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
XSCH-QL-014 Section 3.12.2 Typeswitch
    A case or default clause may optionally specify a variable name. Within
    the return expression of the case or default clause, this variable name
    is bound to the value of the operand expression, and its static type is
    considered to be the SequenceType named in the case or default clause.
There are no SequenceType components in the default clause according to the
Grammar, so perhaps static type for variable should be defined in another way.

            
Don: A typeswitch is equivalent to a stack of if-then-elses with treat
in the then clauses. I think the commenter is correct that the case
clauses have sequencetype, and the default clause does not. We should
fix this.
Jerome:
The static type of the variable in the default clause is the same as the
static type of the expression.
Don suggests that we add that sentence to our document.
RESOLVED: accept this comment, adding the sentence "The static type of
the variable in the default clause is the same as the static type of the
expression."
Don to respond accordingly.
         

Dear Colleagues,
This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].
Please accept our sincere apologies on being past-due with this
submission.
Regards,
David Ezell (on behalf of the XML Schema WG)
[1] https://www.w3.org/TR/2003/WD-xquery-20031112/
XSCH-QL-002 Section 3.4 Arithmetic expressions
The unary arithmetic operations are defined as:
  [65] UnaryExpr ::= ("-" | "+")* UnionExpr
Allowing multiple unary operations to be concatenated together is
different than normal practice in most other languages.  A rationale
or clarification would be welcomed here.

            
See [432]
         

            

            
[---+-+1, multiple unary operators before an expression, there for
            
backward compatibility, group previously didn't want to change it]
            
ACTION A-SJ04-27: Don will add a note to the XPath document to explain the rationale
         

Range expressions (op:to) should treat empty sequence arguments in same way as other binary operators:
if one of argument is empty sequence, result is empty sequence.
I don't see reason for making exception for range expressions.
Best Regards,
Noe Michejda
7th Portal S.C.

            
+ DC: The current rule is consistent with the function conversion rules
for integer. This is nice and simple.
++ M.Rys: Allowing empty sequences as operands of "to" would avoid
static errors in some cases.
++ M.Kay: TO is unlike other binary operators because it takes singleton
inputs and returns a sequence output.
++ Andrew: Advocates accepting the empty sequence in order to avoid
error cases.
++ DECISION: Accepted last call comment qt-2004Feb/1141, subject to
approval by XSL WG since it affects XPath. "TO" operator will accept
empty sequences.
++Note from Chair: This decision was subsequently confirmed by the XSL
WG. See:
https://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Sep/0012.html
++ DC: Accepting this comment requires:
In section 3.3.1, under "range expression": Change the "expected
parameter type" from "xs:integer" to "xs:integer?". Delete the following
sentence. In the next sentence, insert "or if either operand is an
empty sequence". No change is needed to operator mapping table or F&O.
         

Current syntax of SequenceType gives user no control over allowing substitutions of element or not.
User can't test for local element name if there is global declaration with same name
without allowing of elements from substitution group of global element.
Or element will be matched agains unanticipated type from global declaration,
where user wanted only name test. And there will be no warning from processor.
If schema is authored by another person than stylesheet or query this can lead
to disaster if at some point declaration will be added without knowledge of stylesheet author.
Using of declarations and substitution groups should be explicit.
I propose following changes in syntax of elementTest to something like this:
 element()  : matches any element
 element(*,type) : matches type if element type is 'type' or is derived from it
 element(qname ["decl" | "subst"] [,type] ["nillable"])
    if "decl" is present, element is matched to global element declaration
    if "subst" is present, element is matched to global element declaration allowing substitutions
    if neither "decl" or "subst" is present element name is matched to 'qname'
    additionally if 'type' is present, element type must be derived from 'type'
 element(SchemaContextPath qname)
  element is matched to local element declaration
same applies to attribute() [without 'subst']
This will remove synonyms:
element() = element(*) = element(*,*)
attribute() = attribute(*) = attribute(*,*)
Another (maybe better to read) notation:
element(decl(qname),type)
element(subst(qname),type)
 or
element(substitutions(qname),type)
element(substitution(qname),type)
attribute(decl(qname))
etc.
Best Regards,
Noe Michejda
7th Portal S.C.

            
RESOLVED by current SequenceType syntax (reflected in July WD)
ACTION: Jonathan to respond.
         

SECTION 2.6: Optional Features
  Today XQuery requires node identities to be preserved in the language quite strongly. All nodes that are from an external source or created in the language require node identities to be preserved. This is a strict requirement that is not necessary for a large number of applications that need to deal only with the values contained in the nodes rather than the nodes' identity.
 This is also a great burden for implementations that can otherwise use streaming mechanisms for XML processing.
 This is also a problem for implementations that choose to push down the query to be evaluated in native systems like relational databases or other non-XML value based systems.
Suggestion:
 Include a static context flag that specifies whether node identities need to be preserved. If the option is true, then no node based operations such as "is", "<<" , ">>" etc.. should be allowed. Further this could also restrict non-forward axes like parent(), sibling(), root(), etc..
- Steve B.

            
MR sees proposal as requesting a single option in language that makes
any expression that returns node, preserving node identity etc, would
return copy of that node, with only subtree starting at that node,
so every step in XPath expression would return new node rather than
original. If duplicate elimination happens after that, nothing will
ever get eliminated. See the use cases for this, but very reluctant to
add it at this point. Think current proposal mixes ability to copy with
ability to cut off the parent axis. Would prefer to handle that at the
conformance level rather than munging data model.
JR don't think it makes any sense to consider just what we are looking
at on its own. If Oracle wants to present a complete proposal on what to
change, we could consider it, but this isn't baked enough.
SB: There is a more detailed proposal in the works. Would WG be interested
in looking at it?
Chair asks for sense of whether WG would be interested in a detailed
proposal.
Several members express unwillingness to consider such a magnitude
change at this point.
JM: Do we think this is something a vendor could add as a vendor extension
and we could retrofit in a v-next?
A: Sure.
JM: We accept the WG's unwillingness but expect others will see this need
and invite them to work with us on this, perhaps as a prelude v-next.
RESOLVED: closed ORA-XQ-408-B with no action
Dissent: Oracle
         

SECTION 4.3: Base URI
Does specifying the baseuri in a module only take effect for lexically defined URIs or does it also apply to any URI values present in the system?
In particular does the xml:base property affect resolution of URLs inside a document?
* When we convert an anyURI value from an element or an attribute to a string using the resolve-uri() function, does it take into account the xml:base property?
e.g. consider a purchaseorder document with an xml:base property defined as "https://www.po.com" and has an "attachment" element that is of the anyURI type.
 Now given a query like,
 declare base-uri="https://www.some.com";
 for $i in doc("po.xml")
   return doc($i/PurchaseOrder/attachment);
 does the URI for the second doc() get resolved with the https://www.some.com prefix or the xml:base property https://www.po.com?
* When we have doc() or other URI resolutions inside direct element constructors which have an xml:base defined - does it affect the resolution?
For instance,
declare base-uri="https://www.moo.com";
<A xml:base="https://www.foo.com">
  {doc("boo")}
</A>
Does the URL "boo" inside doc() resolve as https://www.foo.com/boo or https://www.moo.com/boo ?
- Steve B.

            
Don identified text in the XQuery language spec, section 4.5.  Andrew
pointed us to section 15.5.4, fn:doc(), in the F&O spec.  Between the
two, the meeting concluded that the base URI declared in the module
prolog is used to resolve relative URIs and that the resolution is not
affected by the xml:base attributes of instance documents accessed by
the query or by an xml:base attribute in an element being constructed.
The specific answers to the two questions in the comment are,
respectively, "yes" and "moo".
RESOLUTION: Comment qt-2004Feb1110-01/ORA-XQ-011 is resolved with no
changes to the document.
Note to F&O editors: In F&O, section 15.5.4, fn:doc(), the Note
terminates with the phrase "to this function", which could better be
phrased "to the fn:doc function" to avoid confusion.
         

SECTION 3.8: FLWR Expressions
Currently, the tuple is defined for the FLWR and order by clauses as containing a set of bound variables. It might help to formalize the tuple notion so that a lot of trivial operations that are possible in languages like SQL (and quite cumbersome to do in XQuery) can be made easy.
Example:
i) If we map any external related set of values (example an SQL row or an XML file in a file system along with some metadata like author etc..) into XQuery, since there is no notion of a tuple, we have to wrap the XML values in another XML element. This causes issues, since node identities, document boundaries etc.. are lost.
ii) When returning values as well, without the notion of tuples, related values either have to be enclosed in an XML element or streamed as siblings in the sequence. This also leads to the same problems as (i).
Example - I want to return a Resume XML document and a computed score for the resume. Either we have to return a sequence that has the resume document followed by it's score or create a new XML element and stuff the two in there - the latter will lose the resume document's node identity and typing.
ii) Performing duplicate elimination is quite a challenge without tuples. (See G.5)
iii) Performing grouping operations is also hard.
Suggestion:
 Formalize the tuple as something in between an item and a sequence - A sequence consists of tuples which consists of items. Or maybe introduce a notion of a tuple-sequence as different from a regular sequence.
- Steve B.

            
Is this related to sequences of sequences issue discussed at last f2f?
A: Yes.
RESOLVED: closed ORA-XQ-408-B with no action
Dissent: Oracle
         

SECTION C.1: Static Context Components
The dynamic context today includes the context item. However, the static context does not include a static type for the context item. This must be included for doing reasonable static type checking.
The table in C.1 - Static Context components could include the following item -
 Component: Context item -
 Predefined value: none
 Overwritable by implementation: Overwritable and Augmentable
 Overwritable by query: -- ??
 Scope - Global
 Consistency rules - Only one context item from the outside environment
- Steve B.

            
Minutes log just says "This issue is closed"
            
(joint issue)
         

            
[[accepted]]
         

SECTION G.5: Selecting distinct combinations
Today, the distinct-values takes a single sequence as input and returns a sequence of distinct values. This makes it quite cumbersome to perform distinct values across a tuple.
 It is trivial in SQL for example to perform a distinct across values -
select DISTINCT price, orderno, date
from table;
 With XQuery, one has to get distinct prices, ordernos and dates and then somehow combine them back with the original node. This is both cumbersome and harder to optimize in a general query.
Suggestions:
i) If we have a sequence of tuples or sequence of sequences, then distinct values can take in a sequence of tuples/sequence of sequences and return a sequence containing distinct values.
ii) Or - Add a DISTINCT clause that prunes out nodes that have the same value.
Example - the query in G.5 with a distinct clause -
  for $p in .
  distinct-values on $p//product, $p//size, $p//color
  return
      <option>
        <product>{$p//product}</product>
        <size>{$s//size}</size>
        <color>{$c//color}</color>
      </option>
 The clause can remove nodes that have the same value for product, size and color and return some $p that has a distinct set of values.
- Steve B.

            
RESOLVED: closed ORA-XQ-407-B with no action
Rationale: no new features and this will be subsumed by group-by which we
have already agreed to take up in the future
         

Dear XQuery Formal semantic editor:
	I have some question about  XQuery/Xpath core grammar in "XQuery 1.0 and XPath 2.0 Formal Semantics" (2003-11-12).
	1)Some Non-Terminal only occur in the left side of core grammar production,but no Non-Terminal can yield it.
	  For example:
      	PrimaryExpr
	  	OrderByClause
      	QuantifiedExpr
      could you explain it in detail?
    2)In Formal semantic,OrderByClause can be normalized to nested let and for expressions,but why it still
       remain in the core grammar?
    3) In XQuery standard grammar:
		ExprSingle    ::=     FLWORExpr
							| QuantifiedExpr
							| TypeswitchExpr
							| IfExpr
							| OrExpr
        In XQuery Core grammar:
         ExprSingle    ::=    FLWORExpr
							| TypeswitchExpr
							| IfExpr
							| OrExpr
		QuantifiedExpr has been removed ,why?
		best regards
						liao wei

            
This should probably be moved to Formal Semantics
      comments.  Looks like some bugs.
         

This is a follow-on to the thread "recursive imporged [sic]
variable declarations":
https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0186.html
https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0075.html
 From that I gather that the WG is in favor of dynamic/lazy
initialization of variable declarations, allowing code like:
M1:
define variable $x external;
define variable $y { if ($x) then $M2:z else 0 };
M2:
define variable $z { $M1:y };
That implies that variable initialization is executed in an order
as needed dynamically.  The natural implementation model is to lazily
initialize each variable on its first reference.  E.g. $y translates
to (using Java syntax):
private int initialized$y = UNINITIALIZED;
private Object value$y;
public Object get$x()
{
   if (initialized$y == INITIALIZING)
     throw new Error("cycle initializing $y");
   if (initialized$y == UNINITIALIZED) {
     initialized$y = INITIALIZING;
     value$y = get$x() ? M2.get$z() : 0;
     initialized$y = INITIALIZED;
   }
   return value$y;
}
However, 4.8 Variable Declaration in the November XQuery draft says:
"Initializing expressions are evaluated at the beginning of the dynamic
evaluation phase."  This means the initialization has to be done
"semi-eagery":  all the initializing expressions have to be evaluated
before the query expression is evaluated.   But which declarations in
which modules.  There are the options I see:
(1) All declarations in all modules that the implementation knows
about are initialized before evaluating the query body.  This is of
course ridiculous.
(2) All declarations in the main module are initialized eagerly (before
evaluating the query body); other declarations are initialized on
first reference.
(3) All declarations in the transitive closure of the main module and
imported library modules are initialized eagerly in some unspecified
order.
(4) All declarations are initialized lazily on first reference;
no declarations are initialized before evaluating the query body.
I think (4) makes most sense, because
(a) it is simplest, assuming we're going to require at-need
initialization to handle cycles;
(b) both (2) and (3) have an arbitrary feel to them;
(c) there may be usecases where it may be useful to not initialize
a variable if it is not needed.  I can't provide examples, but Michael
Key says that requiring dynamic resolution of initialization "might not
disallow some useful constructs that appear to have a cycle, but are
unproblematic if handled dynamically."  His statement was in reference
to initialzaing ordering, which isn't quite the same as whether a
variable must be initialized at all.  However, intuitively it seems
to me that the latter is tied to the former.
--
	--Per Bothner
per@bothner.com   https://per.bothner.com/

            
Public response needed:
we're proposing to change this text to make it clear that Per's
option (4) is permitted.
New text proposed by Don:
    The initializing expression for a given variable must be evaluated
    before the evaluation of any expression that references the variable.
ACTION: A-STATA-19: Liam will respond.
(done)
         

Section 2.4.4.3 Matching an ElementTest and an Element Node
Technical
The current semantics of element(Name, *) is that it matches any element
of any type (the same as element(Name, xs:anyType). We think that this
semantics is problematic when implementing a statically typed system for
the use case where you want to only operate on untyped data. It seems
counter-intuitive that if I do not care about types, that I actually
have to write the function signature element(Name, xdt:untyped) to
preserve the static untypedness inside a function. It would seem better,
if we can define element(Name, *) to either refer to the untyped case or
make it something that will provide late static type binding by
preserving the inferred type of the expression passed. Note that the
later obviously complicates separate compilation of the function since
you need to know the static type of what is being passed...
Here is an example:
define function addWATax($e as element(invoice,*)) as xs:double
{ $e/cost[1] * 1.088 }
With the current semantics of element(invoice, *), $e/cost[1] would
infer the static type element(cost, xs:anyType)? which currently cannot
be atomized because it may have an non-atomizable element at runtime and
would raise a static type error. By changing the semantics to mean
element(invoice, xdt:untyped) the inference for  $e/cost[1] would be
element(cost, xdt:untyped)? that can be atomized to xdt:untypedAtomic?
which in turn will be promoted to xs:double and the function results in
the expected result.
Note that this issue is preserved even if we change the meaning of
element(name) to mean element(name,*) (see
https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jan/0068.html and
MS-XQ-LC1-041).

            
RESOLVED by July WD changes.
[130]    	TypeName 	   ::=    	QName
This does not allow wildcards.
         

SECTION 2.2: Processing Model
Figure 1 'Processing Model Overview' makes no mention of modules. They are presumably part of the "XQuery" box (as opposed to inputs to the query processing system). Can this be clarified in the picture?
- Steve B.

            
editorial.
Michael Rys will alter the diagram, following suggestions JM will supply.
         

SECTION 2.1.2: Dynamic context
It says that the type of the implicit timezone in the dynamic
context is xdt:dayTimeDuration.  However, appendix C.2 says that
this component is merely "overwriteable" as opposed to the current
date and time, which are "must be initialized by implementation".
F&O section 16.7 "fn:implicit-timezone" says that fn:implicit-timezone() returns type "xdt:dayTimeDuration?", which appears to be the correct
type of the implicit timezone (ie, with a "?" quantifier).
- Steve B.

            
++ RESOLUTION: The language document now states, in Appendix C, that
implicit timezone must be initialized by the implementation. This
comment is closed (overtaken by events).
++ Steve Buxton is asked to send a message to the joint list
pointing out that in F&O, fn:current-dateTime() cannot return an
empty sequence but fn:implicit-timezone() can return an empty sequence.
The return types of these functions are inconsistent. XQuery says that
the implementation MUST initialize these context items, but XPath does
not state this requirement. Should XPath require the current dateTime
and implicit timezone to be initialized?
         

SECTION A.2.2: lexical rules
The action pushState is used inconsistently in the transitions,
sometimes with an argument and sometimes without.  The only
guidance to the reader is the sentence "In some cases, a
transition will 'push' the current state or a specific state
onto an abstract stack...".  The reader is left to surmise
that pushState() means "push the current state" whereas
pushState with an argument means "push the argument state".
But if we look at the table for OPERATOR state, first row,
we see the pair of actions:
  DEFAULT
  pushState(DEFAULT)
This seems to mean: first, change the current state to DEFAULT,
and then push the state DEFAULT on the stack.  In that case,
couldn't you just write the second action as pushState()?
If we look at the next to the last line in the same table,
we see
  EXT_KEY
  pushState()
which seemingly means, change the current state to EXT_KEY, and
then push that state.  This leaves this reader confused, why
in one case you chose to push the state explicitly, and in the
other case you did not?  I toyed with the possibility that the
latter example is to be interpreted "change the current state to
EXT_KEY, but push the former state on the stack."  But if that
is your intention, wouldn't it be better to write it
  pushState()
  EXT_KEY
? (Actually, there is considerable evidence in other rules
that this is indeed your meaning; I am filing a separate comment
asking you to please list the actions in the order of execution
instead of this confusing reverse order of execution.)
The best solution in my opinion is simply to get rid of the
argumentless pushState -- always write out explicitly what
state you want to push.  That also eliminates the issue of order
of execution.
- Steve B.

Proposal accepted.

According to table C2, the context item, context position, and context
size are all overwriteable by the implementation.  The context position
"Must be consistent with context item and context size", and the context
size "Must be consistent with context item".
I think we should clearly say that if there is no context item, the
context position and context size are undefined. It is not reasonable to
have no context item but set the context position to 42 and the context
size to 43.
I think we should clearly say that if there is a context item, the
context position and context size are 1. It is not meaningful to say
that the single context item is in position 42 of some sequence to which
the query has no access. (Obviously, the context item might have a
position in a child sequence to which the query has access).
Jonathan

			
            
Andrew: from an XSLT point of view, if I'm iterating through nodes, XSLT
will make some item the current item, do I have access to the position
and size?
Jonathan: I think that's a different issue; the table C2 is different
between XSLT and XQuery, but XSL felt this was XQuery-only
Jerome: if you're binding from an API you might get your context item
coming from a collection from a previous query, e.g. fom XQJ
Jonathan's comment: "I think we should clearly say that if there is no
context item, the context position and context size are undefined."
RESOLVED: agreed to state this in the document.
The comment continues: "I think we should clearly say that if there is a
context item, the context position and context size are 1"
Jerome was unhappy with this, in case the implementation wants to make
them something other than position and size 1.
Example, your Java program calls an XQuery implementation and gets some
results, and then wants to do more processing on each of those results.
Insights: Jonathan was thinking that the root level context item
constrained the entire query, so you could never go above it, but in
Jerome's scenario one indeed might do so.
Andrew: if the context item is provided then a position and size must be
provided where position > 0 and <= size and the size must be greater
than zero.
Paul: this replaces the text The context position "Must be consistent
with context item and context size", and the context size "Must be
consistent with context item".  Andrew's definition replaces these,
along with the above resolution for if there is no initial context item.
RESOLVED: adopted, Don to make these clarifications
Jonathan: this should be clarified further to mention it's about the
initial context item, size and position.  Only the initial values are
overwriteable, so C2 should indicate this.
RESOLVED: agreed.
RESOLVED: qt-2004Feb0166-01 closed
		
         

Query Lang [4.12] local:
   "The declared function name in a function declaration must be a QName with a
   non-empty namespace prefix. If the namespace prefix of a declared function
   name is empty, a static error is raised.[err:XQ0045]"
and
   "It is a static error if the declared name in a function declaration uses
   one of the predefined namespace prefixes other than local.[err:XQ0045]"
What is the rationale for this restriction on the function _prefix_? Is there a
defined mapping from the prefix "local" in the QName "local:myFcn" to a URI?
If so, what is it? If there is no such mapping, this seems at odds with
recommendations of the web architecture [1]. A constraint on the specific
prefix seems very unsound architecturally.
Why not permit functions in the main module to have no namespace? Why not
permit functions in the main module to use the default function namespace (and
its associated prefix)?
Suggest:
* Strike the second constraint entirely, and remove the special-casing for
  the prefix 'local'.
* Either:
     Strike the first constraint entirely.
  or
     Recast in terms of namespaces (rather than namespace prefixes) and
     permit function declarations to assume the default function namespace.
[1] https://www.w3.org/TR/2003/WD-webarch-20031209/

            
Mary: the text no longer talks in terms of prefixes, so I'm happy
to consider 836-01 closed.
         

Query Lang [4.12] Function Declaration prefix vs. namespace.
   "The declared function name in a function declaration must be a QName with a
   non-empty namespace prefix. If the namespace prefix of a declared function
   name is empty, a static error is raised.[err:XQ0045]"
This restriction as stated should be that the _namespace_ be non-empty. If a
default function namespace is in effect in the module, it seems that the
logical thing to do would be to apply it equally to function definitions.

            
subsumed by qt-2004Jan0083-01 (already closed)
         

            
Don: Q7a (qt-2004Feb0834-01) has been fixed
So: qt-2004Feb0834-01 accepted and processed: so RESOLVED and
CLOSED by editorial tweak made by Don
         

Query Lang [4.8] Schema Import
It does not appear to be possible to import a schema with no target namespace.
The syntax rules require a namespace to be present.
Suggest either (1) making the second StringLiteral in the production for
SchemaImport optional or (2) adding alternatives that use an explicit
"nonamespace" token, e.g.
(1) import schema at "nonamespace.xsd";
       or, with no location hint:
    import schema;
(2) import schema nonamespace at "nonamespace.xsd";
       or, with no location hint:
    import schema nonamespace;
Alternative (2) is more in line with XML Schema's explicit marking on
non-namespaced schemas; alternative (1) is simpler.

            
RESOLUTION: This issue is closed without change to documents.
It has been overtaken by events.
         

Query Lang [4.9] Module Import
"It is a static error if the target namespace of the module to be imported is
 the same as the target namespace of the importing module. [err:XQ0056]"
Request that this sentence be struck. It introduces no useful constraint that
is not already covered by existing rules, but introduces a constraint that is
highly detrimental to application development.
The analogy to imagine here is that a module namespace is a Java package name,
and the individual module instances are individual Java classes. This rule is
equivalent to saying that each Java class can only import classes in other
packages. It can import multiple classes from other packages, but not any from
its own package.
Consider a complex XQuery application, where the code is partitioned across
multiple developers.  There are a number of cases where module namespaces do
not provide the level of granularity for managing complex code bodies. In these
cases, providing the means to partition the namespace across multiple sources,
and use the module locations in the intuitive fashion (i.e. a file location
locates a file which is syntactically a complete module) provides great benefit.
To get the full benefit of this ability to partition an application namespace
across multiple sources, the decision to forbid importation of modules from the
same namespace should have been reconsidered in the context of the decision to
allow imports of the same module namespace from multiple locations.
Case 1:
   Two independent developers, working on different functions.
   Developer A: selection-lib.xqy
      module "https://example.org/application"
   Developer B: display-lib.xqy
      module "https://example.org/application"
   Syntactically each of selection-lib.xqy and display-lib.xqy is a module,
   and scopes its contents as normal.
   Application: application.xqy
       declare default function namespace "https://example.org/application"
       import module "https://example.org/application" at "selection-lib.xqy"
       import module "https://example.org/application" at "display-lib.xqy"
   The application will see the function declarations and variable names
   declared in either selection-lib.xqy or display-lib.xqy. Any name conflicts
   will be handled in the usual fashion, raising a static error [err:XQ0037].
   We allow this, provided that application.xqy is not itself a module.
Case 1b:
   As above, but there are some shared constants that A and B both require.
   Developer A: selection-lib.xqy
      module "https://example.org/application"
      import module "https://example.org/application" at "constants.xqy"
   Developer B: display-lib.xqy
      module "https://example.org/application"
      import module "https://example.org/application" at "constants.xqy"
   Application: application.xqy as before
   This is forbidden by the offending sentence. Both selection-lib.xqy and
   display-lib.xqy will therefore need to repeat the shared declarations, but
   this will create a name conflict in application.xqy and raise an error.
Case 2:
   Use module to scope function definitions, without introducing need for
   separate namespace.
   Support library (protected): application-lib.xqy
      module "https://example.org/application"
   API: application-api.xqy
      module "https://example.org/application"
      import module "https://example.org/application" at "application-lib.xqy"
   Application:
      import module "https://example.org/application" at "application-api.xqy"
   The application only sees the interface defined in application-api.xqy, and
   not (using normal module scoping rules) the non-API functions in
   application-lib.xqy.  Again, this is ruled out by the offending sentence.

            
JR: Mary H is saying, why can't you import a module with the same NS as
the current module.
Example from the issue description:
module "https://example.org/application"
import module "https://example.org/application" at "constants.xqy"
straw poll
    delete sentence: 1
    no change: 4
    abstain 5
The chair declared the status quo prevailed
Closed, rejected, but logical/physical text adopted,
with the following two changes:
    impl'n dependent -> impl'n defined
    logical module, physical module:
    module = logical module
    module resource for physical module
The confusion between schema components and module components was a
source of concern expressed by Liam, later also by MichaelR and others.
This means that the scope table will change from "global" to
https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jun/0147.html
   The string literals that follow the at keyword are optional location
   hints, and can be interpreted or disregarded in an
   implementation-DEFINED way. Each physical resource corresponds to a
   module resource.  A logical module is defined by its namespace URI,
   and may be defined by a combination of more than one physical
   module, which must each be a syntactically valid instance of the
   module production. [err:XQ0060]
The editor (Don) will need to check the documents for the term module
and change to module resource everywhere.
         

Query Lang [2.5.2] Cannot catch errors
Dynamic errors can be raised, for example through fn:error(), but there is no
means to catch them. This is a serious deficiency for writing robust
applications, as one must take immense pains to ensure that no expression can
ever, given any set of data, raise a dynamic error if one wants to produce an
application level error result instead of an implementation level one.
Suggest: add try $expression catch $variable $expression
where the variable binds to the error and is an item
This expression will return the value of the try clause unless a dynamic error
was raised, in which case it will return the value of the catch clause.
Example: A function with a parameter that you want to validate using
"validate". If it's not valid, the query blows up and cannot recover, for
example, by fixing up the bad data. The query should be able to do some
internal recovery.
Example: A query performs a division somewhere resulting in an xs:decimal, and
it happens to result in an overflow, from which the application could benignly
recover. The application should be given that chance.

            
MK: Notes that XSL WG is looking at concrete proposal at the moment,
something very similar to this, simple proposal. Expect resolution to
consider at F2F. Proposal is to put it in XPath and we technically
prefer it there, but we could put it in XSLT, or XQuery could decide not
to include that part of XPath.
MR: Have just negated a couple of features under no new features.
JR: What new information?
A: A whole lot of field experience. Information that XSL WG is
considering it.
JR: If we do do this, would like to go back to the larger proposal from
a year ago. Want to be done. Don't drastically change scope of project
this late in the game.
JS: This is a very important feature. Would want to spend time considering
it carefully.
RESOLVED: Closed with no action
Support: 5
Abstain: 5
Dissent: Mark Logic, Michael Kay (a procedural objection)
         

[General] Input sources
There should be a standard mechanism to obtain a vendor-specified "input
sequence".  For document-oriented repositories this would be something like a
list of all documents in the database so input()//foo[bar="x"] would apply the
XPath to every document in the database.  It could be a specially named
variable instead, but since doc() and collection() are functions, it'd be more
consistent to use input().  Using a standard mechanism helps query
portability.

            
we CLOSED this at yesterday's
distributed meeting, by adopting a zero-argument collection function
         

See related comment CER-01
Query Lang [3.1.6, Appendix A] Line-oriented comment syntax
Assume the expression: "This is fun :)". How do you comment it out?  It is an
area loaded with problems, and nesting of comments should be removed . If the
goal of nesting comments is to allow the commenting out of large code blocks,
it is possible to add back in the # line-oriented commenting mechanism.
Modern text editors make it easy to #-mark many lines in a row.

            
Rejected: Although I like line-oriented comments, XQuery and XPath are nowhere else line ending sensitive.  I suggest we close this with no action.
         

            
What's a line?
MH: This is really about having two comment syntaxes.
Proposal: close without change.
         

Query Lang [2.6.6, 3.1.6, Appendix A] Comments and pragmas
The overlap in syntax of pragmas and comments, as well as the nesting of
comments creates difficulties and questions about corner cases that are not
clear from the text:
(1) (: is this a comment? ::)
(2) (: can I comment out a (:: pragma ::) like this? :)
(3) (: is this a comment? ::) or an error? :)
(4) (: what about a partial (:: pragma? :)
(5) (:: pragma with a comment (: is this ok? :) or not ::)
(6) (:: pragma with a comment (: is this a comment? ::) or an error? :) ::)
(7) (:: pragma with a comment (: what about a partial (:: pragma? :) ::)
(8) (: commenting out a (: comment :) is confusing :)
(9) let $string := "this is just a string :)"
(10) (: let $string := "this is just a string :)" :)
(11) let $another := "this is another string (:"
(12) (: let $another := "this is another string (:" :)
Suggest (a) making clear that comments are not allowed inside pragmas and (b)
removing nesting of comments.

            
Technically answered as resolution from some other LCCs.  But I
suggest we use many of Mary's examples directly in the text as
illustrations as to the behavior.  On the other hand, the group can
always reconsider the decision.
            (1) (: is this a comment? ::)
Answer: yes.
(2) (: can I comment out a (:: pragma ::) like this? :)
Answer: yes.  The inner pragma is seen a a comment in this case.
(3) (: is this a comment? ::) or an error? :)
Answer: error.  ANY unbalanced nesting of "(:"/":)" will result in an error.
(4) (: what about a partial (:: pragma? :)
Answer: ANY unbalanced nesting of "(:"/":)" will result in an error.
(5) (:: pragma with a comment (: is this ok? :) or not ::)
Answer: it's fine, but inner content is not a comment.
(6) (:: pragma with a comment (: is this a comment? ::) or an error? :) ::)
Answer: error, "::)" patterns are not allowed in pragma's and extensions.
(7) (:: pragma with a comment (: what about a partial (:: pragma? :) ::)
Answer: this is fine.
(8) (: commenting out a (: comment :) is confusing :)
Answer: OK.  Trying to comment out a large block with a bunch of other comments in them is even more confusing.
(9) let $string := "this is just a string :)"
Answer: No error.
(10) (: let $string := "this is just a string :)" :)
Answer:  Error.  Yes, this is a limitation of nested comments.
(11) let $another := "this is another string (:"
Answer: No error.
(12) (: let $another := "this is another string (:" :)
Answer:  Error.  Yes, this is a limitation of nested comments.
         

            
NW: You could use numeric character references. Maybe.
Proposal: close without change except that these examples should be in
the document.
ACTION A-172-02: Scott to make sure these examples occur in the
document.
Accepted.
         

Appendix A.1 EBNF
Technical
It looks like that we cannot parse an expression of the form:
"1" cast as xs:integer = "1.0" cast as xs:integer.
Which is semantically the same as xs:integer("1") = xs:integer("1.0").
Based on the precedence table, I would assume that cast as binds
stronger than =, and from a composability point of view, I would also
expect to be able to write the above. However, when following the
grammar, it looks like the grammar pops out without consuming the =.
Here is the parse process:
"1" is consumed by
Expr->SingleExpr->OrExpr->AndExpr->InstanceOfExpr->TreatExpr->CastableEx
pr->CastExpr->ComparisonExpr->RangeExpr->AdditiveExpr->MiltiplicativeExp
r->UnaryExpr->UnionExpr->IntersectExpr->ValueExpr->PathExpr->RelativePat
hExpr->StepExpr->FilterStep->PrimaryExpr->Literal->StringLiteral
Which then pops back to CastExpr that consumes "cast as xs:integer"
Then we pop back to the top and realize that we have left overs and
raise a parse error.
This is also a problem for the related treat as, castable as etc.

Hi Michael.  Paul wanted me to give high priority to answering this
particular issue (original mail at [1]).
Since the November document, the WG has agreed to change the precedence of
instance-of, treat, castable, and case (in response to a previous issue
raised [2] by you).  The precedence table is now looking more like:
1       (comma)
2       FLWORExpr, some, every, TypeswitchExpr, IfExpr
3       or
4       and
5       eq, ne, lt, le, gt, ge, =, !=, <, <=, >, >=, is, <<, >>
6       to
7       +, -
8       *, div, idiv, mod
9       unary -, unary +
10      union, |
11      intersect, except
12      instance of
13      treat
14      castable
15      cast
16      ValidateExpr, /, //
17      [ ], ( )
so that these operators bind much more tightly.
In the most recent test parser, your expression parses fine:
Type Expression:
"1" cast as xs:integer = "1.0" cast as xs:integer
|QueryList
|   Module
|      MainModule
|         Prolog
|         QueryBody
|            Expr
|               ComparisonExpr =
|                  CastExpr
|                     PathExpr
|                        StringLiteral "1"
|                     CastAs cast as
|                     SingleType
|                        AtomicType
|                           QNameForAtomicType xs:integer
|                  CastExpr
|                     PathExpr
|                        StringLiteral "1.0"
|                     CastAs cast as
|                     SingleType
|                        AtomicType
|                           QNameForAtomicType xs:integer
Please let me know if this previously decided issue resolves MS-XQ-LC1-146
in your view.  Thanks!
-scott
[1] [XQuery] MS-XQ-LC1-146
 https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0801.html
[2] Grammar issue: cast as
 https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0063.html
			

Yes. This seems to resolve the issue.
Thanks
Mi
			

            
See [436]
         

Section 4.12 Function Declaration
Technical
Please remove the local namespace prefix and URI for functions. It is
only a small burden for the user to define his own prefix and it reduces
the implementation complexity by not having to special case this local
prefix and namespace.

            
(please remove the local namespace prefix and URI for functions)
Everyone can live with the status quo.
         

Section 4.12 Function Declaration
Technical
"An XQuery implementation may augment the type system of [XQuery 1.0 and
XPath 2.0 Data Model] with additional types that are designed to
facilitate exchange of data with host programming languages": Please
make sure that this type is available in the context of the general type
system. In particular, make sure that it is placed under either one of
xs:anyType, xs:anySimpleType or xdt:untypedAtomic and not under concrete
types.

            
Issue closed with xdt:AnyAtomicType as the type to be used.
            
(joint issue)
         

            
Issue closed with xdt:AnyAtomicType as the type to be used.
(joint issue)
         

Section 4.11 Default Collation Declaration
Technical
"If a Prolog specifies more than one default collation,": How can you
specify more than one. We should syntactically only allow one.

            
Issue closed - No changes to the documents at this time.
            
(xquery-only)
         

            
Issue closed - No changes to the documents at this time.
(xquery-only)
         

Section 4.11 Default Collation Declaration
Technical
"The default collation applies to all functions that require a
collation, except the following functions: fn:contains, fn:starts-with,
fn:ends-with, fn:substring-before, and fn:substring-after. If one of
these functions is called without an explicit collation parameter, it
uses the Unicode codepoint collation rather than the default
collation.": Why are these functions treated differently. We think that
this is more confusing than helpful and request to not special-case them
and have them take the default collation as well.

            
because of resolution in https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Aug/0165.html
         

Section 4.8 Variable Declaration
Technical
"If the value provided by the external environment is not compatible
with the declared type of the variable, a type error is
raised.[err:XP0006]": A static typing implementation cannot do this
check at runtime. Therefore, an implementation will need to guarantee
that this is an axiomatic constraint. Therefore, we request that this is
formulated as a constraint.

            
Jonathan is not aware of such a constraint already existing. So we'd
be asking the editors to add one.
Don: Constraints don't have errors, so I'll have to take this error away.
MR: agreed.
Accepted. Don will add the constraint.
         

Section 4.8	Variable Declaration
Technical
"If an initializing expression cannot be evaluated because of a
circularity (for example, it depends on a function that in turn depends
on the value of the variable that is being initialized), a dynamic error
is raised": This error should be determined and raised statically.

            
https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jun/0147.html
gives examples (under 5.E).
Agreed that this should be a static error, if it's an error.
         

Sections 4.8/3.8.1
Technical
"the static type of the expression must be compatible with the declared
static type; otherwise a type error is raised.[err:XP0004]": As in
function parameter passing, we should allow the general type promotion
and atomization rules to take place for variable assignments.

            
straw poll:
    for: 2
    against: 2
    abstain: 6
rejected, not enough support
         

Section 4.7	Module Import
Technical
We believe that the module import feature is problematic in that is
seems not well-enough understood to make it a normative part of the spec
even as an optional feature. Can we introduce a category of exploratory
features that may change in the next version and does not guarantee
backward-compatibility on the recommendation level?

            
straw poll: do we leave modules in our WDs?
leave in: 7
remove: 3
Chair rules that the status quo prevails, and modules remain.
         

Section 4.4	Namespace Declaration
Technical
"However, a declaration of a namespace in the Prolog can override a
prefix that has been predeclared in the static context." Please move the
exception with the prefix xml up here.

            
ACTION A-216-10 Jonathan to respond to qt-2004Feb0784-01
         

Section 4.4	Namespace Declaration
Technical
"unless it is overridden by a namespace declaration attribute in an
element constructor.": See our comment MS-XQ-LC1-084.

            
RESOLVED: qt-2004Feb0783-01 is rejected, consistent with our decision
on qt-2004Feb0492-01.
         

(IBM-XQ-024) Section 3.7.3.5, Computed PI Constructors: The name
expression of a Computed PI constructor should undergo atomization, and
should accept values of type xdt:untypedAtomic, in order to be consistent
with the name expression of a Computed Attribute Constructor.
--Don Chamberlin

(IBM-XQ-025) Section 3.9.3, Order By and Return Clauses: The first
bulleted list says that each orderspec in an Order By clause must "return
values of the same type for all tuples." We should use a different term:
"comparable types" rather than "same type", and we should define the term.
For the purposes of this rule, all numeric types should be "comparable".
The types xs:string and xdt:untypedAtomic should be "comparable". Any
atomic type should be "comparable" with its derived types, and two atomic
types that are derived from the same base type (or that are both derived
from numeric types) should be "comparable".
--Don Chamberlin

            
DECISION: qt-2004Feb0775-01 has been accepted by a previous
decision and already implemented in the July 2004 draft.
         

(IBM-XQ-023) Section 3.7.3.2, Computed Attribute Constructors: The last
paragraph of this section, which says that a computed attribute
constructor must not be a namespace declaration attribute, should be
deleted. This case is covered by Name Expression Rule 3. However, this
rule should be extended to raise an error if the resulting QName has no
namespace URI and its local name is xmlns.
--Don Chamberlin

(IBM-XQ-021) Section 3.7.4, Namespace Nodes on Constructed Elements: In
the Note in this section, the second paragraph says that an implementation
can choose to assign the default namespace (by generating a namespace
declaration with a null prefix) when constructing an element. This is a
dangerous thing to do. The string content of the element may contain some
names that are intended to be in no namespace. Unexpectedly reassigning
the default namespace would cause these names in element content to be
interpreted incorrectly. I suggest deleting this paragraph.
--Don Chamberlin

            
WG Resolution: delete the 2nd paragraph feb 774
         

            
WG Resolution: delete the 2nd paragraph feb 774
         

(IBM-XQ-022) The following parts of the XQuery document depend on the
ability to cast any atomic value into a string:
(a) Section 3.7.1.1, Direct Element Constructors--Attributes, Rule 3b.
(b) Section 3.7.1.3, Direct Element Constructors--Content, Rule 1d.
(c) Section 3.7.3.1, Computed Element Constructors, Content Expression
Rule 1.
At present, the Functions and Operators document does not permit a QName
to be cast into a string. It is clearly not acceptable to be unable to
construct any element or attribute that contains a QName. This
inconsistency between the XQuery and Functions and Operators documents
needs to be corrected.
Note that casting a QName into a string is also required by the
Serialization document, as noted in comment IBM-SE-015.
--Don Chamberlin

            
RESOLVED: CLOSED by adoption of the triple proposal
         

(IBM-XQ-020) Section 3.7.3.5, Computed Processing Instruction
Constructors: If the content expression of such a constructor (after
atomization) contains the string "?>", a dynamic error should be raised (a
processing instruction cannot contain its own delimiter).
--Don Chamberlin

(IBM-XQ-019) Section 3.7.1.5, Type of a Constructed Element: This section
says that a direct element constructor adds the name of the constructed
element to the validation context for nested expressions. Does this rule
still apply if the direct element constructor has an xsi:type attribute?
How can validation context (a static property) be affected by the value of
an xsi:type attribute (which can be dynamic)?
Similarly, in Section 3.7.3.1, Computed Element Constructors: If the name
of the constructed element is computed by an expression (which, after all,
is the reason for having a computed element constructor), the validation
context for nested expressions is set to "global". This seems likely to
cause problems. Suppose that I use a computed element constructor to
construct an element named Address, with a nested element named Zipcode.
If Address is a computed name, the validation context for the Zipcode
element will be "global". But it's likely that the Zipcode element is not
defined globally, but only within an Address.
Because of examples like this, I am increasingly skeptical of the concept
of "validation context". I do not believe that it is well understood. I
think we would be well advised to stop trying to validate things that do
not have top-level schema definitions, at least in XQuery Version 1.
Deferring this complex and poorly understood feature until after XQuery
Version 1 would provide us with practical experience that might lead to a
more robust design if this feature is found to be needed in a later
version. It would also allow us to focus our efforts on more important
issues such as defining an update language.
My specific proposal is as follows:
(a) Eliminate "validation context" from the Static Context.
(b) Eliminate ValidationContext (formerly called SchemaContext) from the
grammar.
(c) Replace Section 3.7.1.5, Type of a Constructed Element, with a new
section based closely on
https://www.w3.org/TR/xslt20/#validating-constructed-nodes as suggested by
Michael Kay. This will bring XQuery into alignment with XSLT 2.0. It will
also resolve all the questions raised in this comment, including how to
deal with xsi:type attributes. The text suggested by Mike is Section
19.2.1 of the XSLT 2.0 document, entitled "Validating Constructed Elements
and Attributes". It can be inserted into the XQuery document with minor
editing, such as replacing "validation attribute" with "validation mode",
replacing "synthetic schema document" with "in-scope schema definitions",
and deleting XSLT-specific references such as "xsl:copy-of".
(d) Replace Section 3.14, Validate Expressions, with a new section based
closely on Sections 19.2.1 and 19.2.2 of the XSLT 2.0 document, which
define validation for element and document nodes, respectively.
The result of this proposal will be to simplify XQuery, bring it into
alignment with XSLT 2.0, resolve the questions raised in this comment, and
dispose of Action Item XQUERY-162-03.
A related action, which I do not believe to be required by this proposal
but which would certainly be consistent with it, would be to eliminate
SchemaContextPath from the SequenceType syntax, cleaning up another
complex and poorly understood part of the language.
--Don Chamberlin

            
ACCEPTED and CLOSED as we abolished
validation context; did this in query teleconf 190, June 3rd.
[Liam note: missed because of a typo in the issue number]
         

(IBM-XQ-018) Section 3.7.1.3, Direct Element Constructors--Content: This
section says that element nodes that are copied by an element constructor
retain their namespace nodes. This seems to imply that the copied nodes do
not also inherit namespace nodes from their new parent. Is this correct?
If so, the copied node may have fewer namespace nodes than its parent. How
can such a node be serialized? Does this introduce a dependency on
"undeclaration" of namespaces, supported only by Namespaces 1.1?
Similarly, in Section 3.7.4, Namespace Nodes on Constructed Elements:
Suppose that the namespace prefix "a" is defined in the Static Context.
Suppose that a constructed parent element has an attribute named "a:b" but
its constructed child element does not use the prefix "a" in any name.
According to the rules in this section, the parent element will get a
namespace node for "a" but the child will not. Again, how can these
elements be serialized? Is this another dependency on Namespaces 1.1?
--Don Chamberlin

            
RESOLVED and CLOSED: This has been
resolved by inventing yet another prolog declaration that tells
constructors whether to copy or not: resolved and decided on the xquery
telcon 197 on Jul 28 (cf. also w3c-xsl-query/2004Jul/0028, which was the
base from which we made this decision): Don was there (telcon 197, July
28) given an action item A197-01, and it got finally approved on the query
meeting n.199
         

(IBM-XQ-017) Section 3.1.5, Function Calls: Error XP0018, referenced in
this section, is just a special case of Error XP0002, which is used in
several other places for the same condition. Since Error XP0002 is more
general-purpose, we should eliminate XP0018 and change all its references
to XP0002. (If retained, XP0018 should be made dynamic rather than
static.)
--Don Chamberlin

            
RESOLVED and CLOSED (by myraculous agreement between
Don and MRys): delete the last sentence of section 3.1.5 (number 4 in the
23 Jul 2004 version)
         

            
[XQuery] IBM-XQ-017: Delete error XP0018
The above reference seems spurious. This comment was accepted and the
change has already been implemented.
         

(IBM-XQ-016) Section 2.1.1, Static Context: Static type analysis of an
expression that contains a "dot" (such as ". + 1" or "substr(., 1)")
depends on the static type of the context item. But there is no component
in the static context for the static type of the context item. Should we
add such a component and allow implementations to initialize it (since
they are allowed to initialize the context item)?
--Don Chamberlin

            
Minutes log just says "This issue is closed"
            
(joint issue)
         

            
[[accepted]]
         

SECTION 4.12: Function Declaration
The section talks about being able to write a function in a host programming language and then declare the function in XQuery as external. However, it is not clear whether the function declaration is required for all external functions or if we are saying its optional. According to appendix C.1, the in-scope functions is augmentable by an implementation which suggests that an implementation may choose to not require a function declaration for each external function. If this is the case, it would be helpful to clearly mention in this section that the function declaration may be optional for external functions.
- Steve B.

            
DC (and others) believe it is already clear that the implementation can
add functions to the static context on initialization, therefore by
definition it is not required to declare all extension functions. (Indeed,
if the vendor has automatically added a function to the context, it is an
error to add the same function explicitly.)
RESOLVED: to close the issue with no action, on the grounds that the
spec already says what the comment is asking for.
         

SECTION 2.1.1 : Static contextt
The static context has no type information for the context item,
consequently it is impossible to do static analysis of expressions
that use the context item.
- Steve B.

            
Item closed pending further discussion on the default type
            
(item?) as proposed by Andrew.
            
Michael Rys to start on e-mail on the default type proposal.
         

            
Item closed pending further discussion on the default type
(item?) as proposed by Andrew.
Michael Rys to start on e-mail on the default type proposal.
         

            
Discussion on whether item()? makes sense? Can the expression "."
ever return the empty sequence? MKay believes not.
MRys thinks a static type of "none" would be more appropriate
since this will lead to a static error for the query ".".
Jerome suggests another formulation: by default "it's not in the
context".
Andrew thinks this is equivalent to "none".
RESOLUTION to qt-2004Feb0700-01: Accepted the proposal in
https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Jun/0074.html
with "item()?" changed to "none". Issue ORA-XQ-374-B is closed.
(Note this is an XQuery comment).
This is no change to the document, since Don anticipated the WG
decision.
Don pointed out that in other entries in the table, "none" means there
is no default. Here it means that the default is "none". Don will sort
this out editorially.
         

SECTION A.2.2: Lexical rules
Today's lexical analyser is a 'two-stage' analyzer.  The bottom
stage, not explicitly mentioned in the Appendix, I will call the
raw tokenizer.  This stage is responsible for detecting things
like NCName and NumericLiteral.  The stage above it is responsible
for discerning when an NCName is a keyword, and for handling
comments, pragmas and must-understand extensions.
The design goals that make lexical analysis for XQuery difficult
are: no reserved words; nested comments; and the context-sensitivity
inherent in supporting direct constructors as a sublanguage with
different whitespace and comment rules from the containing language.
In a lexical analyzer with reserved words, the keywords can be
detected in the raw tokenizer stage. Frequently the raw tokenizer
stage also detects and ignores comments.  For such a language,
a single stage, the raw tokenizer, is sufficient.
In languages that only support unnested comments, it is possible
to recognize comments as regular expressions.  The usual way to
recognize regular expressions is with a finite state automaton.
XQuery has opted to support nested comments, which means that
comments are not a regular expression; instead they constitute
a 'context-free' language.  The usual way to recognize a context-free
language is by adding a stack to a finite state automaton.
The current design of the lexical analyzer is with a raw tokenizer
that recognizes tokens defined as regular expressions.  Since
the raw tokenizer is not powerful enough to handle nested comments,
comment handling has been pushed into a stage above the raw
tokenizer, where there is a stack.  This stage has also been given
the responsibility for deciding when an NCName is a keyword.
However, these two responsibilities are not easily merged in a
single stage.  The solution propounded so far has been to prohibit
comments in those contexts which are necessary to recognize certain
keywords.  However, prohibiting comments between
certain pairs of keywords is a major usability disservice.
I think the solution is that the keyword recognizer needs to be
at a higher stage than the comment recognizer.  There are two
ways to do this:
1. Abandon nested comment support.  Most high level languages
do not support nested comments, so there is ample precedent.
Users are accustomed to this restriction.  In addition, if it
came to a choice between nested comments, and the freedom to
put comments anywhere between keywords, I would gladly
sacrifice the nested comments, and I think most users would too.
Making this decision
would mean that comments would be regular expressions, and could
be recognized and removed in the first stage, the raw tokenizer.
This decision would also simplify the syntax and analysis of
comment-like things (pragmas and must-understand extensions).
Overall, the decision would be that there is no nesting of
comments, pragmas or must-understand extensions in one another.
2. If you really have to have nested comments, then you should go
to a three-stage lexical analyzer.  The bottom stage would be a
raw tokenizer, which would detect (: (:: :) and ::) as tokens.
The second stage above would run the stack to determine the boundaries of
comments, pragmas and must-understand extensions.  Finally, the
top stage would recognize keywords.
- Steve B.

            
Had phone call with commenter.  I think we should reject the suggestions.
         

            
ScB: Two suggestions: abandon nested comment support or go to a
three-stage analyzer.
ScB: I don't think we should abandon nested comment support and the
     three-stage analyzer is an implementation issue.
Proposal: close with no action.
Accepted.
         

SECTION 3.7.3.1: Computed element constructors
Under "content expression" it says that "a new deep copy of each
node is constructed...".  "Deep copy" is not defined and there
is no hot link to it.  The word "copy" does not appear in the
data model specification, and in the formal semantics the word
is only used regarding environments, not nodes.
- Steve B.

SECTION 3.2: Path expressions
It says in the third paragraph after rule [70] that
"Each operation E1/E2 is evaluated as follows:
expression E1 is evaluated... The sequence of nodes resulting from
all evaluations of E2 are combined, eliminating duplicate nodes
based on node identity and sorting the result in document order".
Later, in section 3.2.1 "Steps", in the last paragraph prior to the
final note, it says "If the axis is a reverse axis, context positions
are assigned in reverse document order."  These two sentences
appear to be in contradiction.  Either reverse axes result in
a sequence that is in forward document order, or the general
statement in 3.2 should say that the result is in either forward
or reverse document order.
- Steve B.

            
Sorting applied at the end of the step.  Text is correct.
RESOLVED:  No change required.  Close issue.
         

SECTION 3.5.1: Value Comparisons
Bullet 1 says "Atomization is applied to each operand. If the result, called an atomized operand, does not contain exactly one atomic value, a type error is raised.[err:XP0004][err:XP0006]".
The definition of atomization (2.3.2) implies that atomization is done during evaluation phase. The words used here "atomic value" also implies that.
However, [err:XP0004] is a static type error.
Similar statements appear in 3.7.3.1, 3.7.3.2, 3.8.3, and 3.12.3.
- Steve B.

            
++ M.Rys: In certain cases, this error can be detected statically.
++ DECISION: Issue comments/2004Feb/0694 is closed without change to
document. Oracle accepts this decision
         

SECTION 3.7.1.1 : Attributes
In 3.7.1.1, it states that namespace declaration attributes
do not create attribute nodes, and so does 3.7.1.2.
However, it is not clear what node namespace declaration attribute
creates until 3.7.4 section which
states that "A namespace node is created corresponding to
each namespace declared in a namespace declaraction attribute...".
So a namespace declaraction attribute indeed creates a namespace
node. So it would be better if we stated that a namespace
declaration attribute creates a namespace node in 3.7.1.1 and
3.7.1.2 or make a cross reference to 3.7.4 .
- Steve B.

            
WG Resolution: this has been overtaken by events, as we no longer
            
talk about namespace nodes.
         

SECTION 3.7.3.1: Computed Element Constructors
In 3.7.3.1, the content expression of a computed element constructor:
the element nodes are given type annotation xs:anyType and
attribute nodes are given type annotation xs:anySimpleType.
It would be more precise to give type xdt:untypedAtomic to
attribute nodes and give type xdt:untypedAny to element node.
See previous comments on 3.7.1.3 content for direct element constructor.
- Steve B.

            
Changes earlier resolution
         

SECTION 3.7.1.3: Content
In 3.7.1.3 Content, 1.d. section, it states that
element nodes are given the type annotation xs:anyType and attribute
nodes are given the type annotation xs:anySimpleType.
It would be more accurate to state that the element nodes are given the type annotation xdt:untypedAny and attribute nodes are given the
type annotation xdt:untypedAtomic. ( Please refer to Figure 2: Summary of XQuery Type Hierarchy.)
This is because in '3.13 Validate expression' and '3.7.1.5 Type of
a constructed element' section, if validate mode = skip, the spec
states that element node is given type of 'xdt:untypedAny' and
attribute node is given type of 'xdt:untypedAtomic', which appears
to be more accurate based on 'Figure 2:Summary of XQuery Type Hierarchy'.
So it is better if we make them consistent.
However, it seems 1.d. is irrelevant since step 6 performs the
same operation.
- Steve B.

            
Changes earlier resolution
         

SECTION 3.12.2: Typeswitch
Should un-reachable case statements lead to a warning? E.g. case as super-type will make the subsequent case as sub-type unreachable.
- Steve B.

            
KK: explains the proposal, it's a request that we should permit a warning
if there is dead code. DC: we currently leave warnings entirely up to
the implementation. JM: therefore the spec already permits a warning
here but does not require it. MK: and I think that's a satisfactory
state of affairs.
RESOLVED: to close with no action, on the grounds that an implementation
is already allowed to raise warnings on this condition.
         

SECTION 3.1.1:
How can user defined entities (e.g. those defined in a DTD) be represented in a constructed element?
Perhaps a prolog for entity definition?
- Steve B.

            
RESOLUTION: Closed with no changes to the document. It should be raised
again for V.NEXT.
         

SECTION 3.8.3: Order by and Return Clauses
In 3.8.3,  the Xquery spec says "The return clause of a
FLWOR expression is evaluated once for each tuple in the
tuple stream, and the results of these evaluations are
concatenated to form the result of the FLWOR expression".
The usage of the word 'concatenated' is vague here. Since the XQuery
result does not support nested sequences, if a tuple contains
a sequence, all the items of the sequence become the items of the
sequence for the return clause of the FLWOR expression. So in this
sense, the 'concatenation' here really means "Constructing Sequences"
as defined in "3.3.1".  We should define this concatenation process  to be the same as the construction of Sequences specified in 3.3.1.
This also implies that the empty sequence in the tuple is dropped as defined in constuction of Sequences. 'concatenation' does not clarify whether the empty sequence is dropped.
- Steve B.

            
JR: is saying that "concatenation" is only unclear if nested sequences
exist. JM: doesn't read it that way. AE: was taking this as an editorial
comment, that the description of the operation was not clear enough. Asks
Don if he's sympathetic. JM: has no objection to it being declared
editorial.
RESOLVED: to make this an editorial item, Don will consider how to
improve the wording. The comment is resolved.
         

SECTION 2.6.6.1: XQuery flagger
To assist the programmer developing a portable application,
the flagger should provide a warning of all dependencies on objects that are not fully specified by W3C specifications.
Examples of such dependencies are:
- invocation of functions not defined in the fn: namespace
- invocation of functions defined in the fn: namespace that
  have implementation-defined properties (for example,
  fn:collection and fn:doc)
- reference to anything added to the static context as an
  implementation-defined option.  See the table in appendix
  C.1  that documents implementation-defined extensions to
  the static context.
- Steve B.

			
            
no more flagger.
		
         

SECTION 2.6.6.1: XQuery flagger
It should be possible to have a reference implementation
of a downloadable application that people could use to
check whether a particular XQuery expression is fully
portable.  Such an application would take as input a
character string or file, and return a yes or no verdict
about the contents of the character string.  The application
would not execute the query, merely syntax check it.
- Steve B.

			
            
flaggers deleted.
		
         

SECTION 3.2: Path Expressions
In 3.2 explanation of initial / and //, it states that if the
context item is not a node, a type error is raised. It should
also state that if the context item is undefined, then a
dynamic error is raised (unless this is stated in a general way elsewhere in the document).
- Steve B.

            
Section 3.1.4 - "Context item expression" -  addresses this issue.
            
Issue closed with no change to documents
            
(joint issue)
         

SECTION 3.1.2: Variable References
At the end of 3.1.2, it says variable binding is defined on
top of a concept "scope". However, there does not seem to be a central place to define the concept of scope in XQuery spec. Instead, its defintion is scattered in each expression which can
create variable binding scope.
3.8, 3.11 and 3.12.2 define the scope of a variable explicitly
for FLWOR, Quantified Expr and TypeSwitch respectively, however,
the scope of a variable is not defined for function call.
It would be better if the scope of a variable binding for all kinds of expressions were listed here and made cross references to each
kind expression and give some examples too.
- Steve B.

			
            
RESOLVED: decided to take no action. There was a conscious decision to
distribute the definition of variable scope, and people feel it works
better that way.
A detail, the comment says scope is not defined for function
parameters, but it is.
		
         

SECTION 3.12.2: Typeswitch
fourth para after the BNF begins: "A case or default clause may
optionally specify a variable name. Within the return expression of the case or default clause, this variable name is bound to the
value of the operand expression, and its static type is considered
to be the SequenceType named in the case or default clause."
I can see the SequenceType specified in CaseClause, but the
default clause has no syntax to specify a sequence type (and probably
should not). My guess is that the type is the most general (item()*).
This needs to be clarified.
- Steve B.

            
Various people recalled discussing this. DC: it's a duplicate of a
comment from David Ezell 2004Feb1157-01 which we accepted. We have
responded to this and implemented it. The resolution was that the static
type of the variable in the default clause is that of the expression.
RESOLVED: to close this as a duplicat
         

SECTION 2.6.6.1: XQuery Flagger
If the XQuery flagger is enabled, then a static error is raised if the query contains a must-understand extension.
A warning would be more appropriate/useful.
SQL has the (FIPS) flagger which raises only warnings for vendor specific SQL extensions.
- Steve B.

			
            
no flaggers, no must-understands
		
         

SECTION D.2: normative references
There are normative references for both XML 1.0 and XML 1.1,
but when it comes to names, only "Namespaces in XML" is
referenced.  The latter is a companion to XML 1.0.
The correct companion for XML 1.1 is "Namespaces in XML 1.1".
- Steve B.

            
The references are all there now.
         

SECTION A.2.2: lexical rules
KINDTEST, KINDTESTFORPI, CLOSEKINDTEST, OCCURRENCEINDICATOR and
SCHEMACONTEXT states do not allow comments, pragmas or must-know
extensions.  This seems unnecessarily limiting to forbid these
within kind tests.
- Steve B.

            
Fix will be fallout from qt-2004Feb0658-01 resolution.
         

            
| Proposed, recommended, or existing response:
|   Fix will be fallout from qt-2004Feb0658-01 resolution.
Accepted: no specific change here,
falls out of resolution for qt-2004Feb0658-01.
         

SECTION A.2.2: lexical rules
DEFAULT state table, fifth row, recognizes
<"declare" "variable" "$">, changes state to VARNAME and
pushes DEFAULT state on the stack.  In state VARNAME,
after passing over comments, pragmas and must-knows, it
transitions to OPERATOR state.  The OPERATOR state table
only does a popState() for input "}".  There are many
instances in which a variable name will not be followed by "}".
It is not evident that the DEFAULT state pushed on the stack will ever be popped.
Stack overflow appears to be a real danger.
- Steve B.

            
See [431].  Fixed, as per some other LCCs.
         

            

            
Fixed, as per some other LCCs.
         

            
[[accepted]]
         

SECTION A.2.2: lexical rules
It is not clear how these rules enforce the whitespace rules
/* ws:explicit */ and /* ws:significant */.  For example,
a direct element constructor has /* ws:explicit */ and begins
with "<" QName.  In the DEFAULT table, this is found in the
row for "<" which performs a transition into state START_TAG
while pushing state OPERATOR.  It is a requirement not to permit
whitespace between "<" and the QName.  However, the lexical
state tables for the most part assume that whitespace is permitted
between two successive tokens.  How can the lexical state tables
work if some of the transitions permit whitespace between tokens
and other transitions do not, and there is no indication in the
tables as to which is which?  You can't take refuge in the
/* ws:explicit */ note attached to the EBNF, because
the lexical rules must be executed before the EBNF.
- Steve B.

            
Resolution: this issue is closed, with no further changes, and
SteveB/Oracle will double check that this is ok.
         

			
            
Resolution: this issue is closed, with no further changes, and
SteveB/Oracle will double check that this is ok."
Scott Boag noted that (as the agenda shows) this is closed.
Steve Buxton confirmed that he has double checked and wants this
closed.
[Liam notes this was closed at the MIT face-to-face,
https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jul/0086.html
]
		
         

SECTION A.2.2: lexical rules
DEFAULT state, on input "(:", has transition to
EXPR_COMMENT followed by pushState().  I interpret this to mean
the current state is changed from DEFAULT to EXPR-COMMENT,
and then the current state (now EXPR_COMMENT) is pushed on
top of the stack. We continue executing in EXPR_COMMENT state.
On input ":)",
the transition is popState(), which seemingly means that the
EXPR_COMMENT state that is on the stack is popped and becomes the
current state.  This looks wrong.  Don't we want to go to
whatever state we were in before the comment?  In that case,
shouldn't the transition in DEFAULT state on input "(:"
be pushState(DEFAULT) followed by entering EXPR_COMMENT state?
Based on this example, I question whether any of the transitions
should have pushState() as the second step.  It makes more sense
to do pushState() before changing the current state rather than
after.  This whole question of order of actions can be avoided
by always pushing an explicit state.  Each table knows what
state is the current state, so you can just push that state
explicitly when you want to push the pre-existing current state.
- Steve B.

            
Duplicate of 2004Feb0853.
         

SECTION A.2.1: white space rules
If an EBNF rule is marked as /* ws:significant */, it seems that
it must apply to all the 'child' EBNF productions.  For example,
rule [109] ElementContent is marked as /* ws:significant */,
which means that all whitespace is significant in ElementContent,
and that must mean that all whitespace is significant in
anything on the right hand side of rule [109].  But what about
EnclosedExpr?  Once you go into an enclosed expression, I think
that whitespace should be insignificant again.  If you say that
/* ws:significant */ only pertains to the production on which it
appears, and not to any nonterminals found on the right hand side,
then I have two questions: 1) How do I know which whitespace is
governed by the note, since S almost never appears on the right
hand side of these rules; and 2) why is rule [109] labeled this way,
since the right hand side consists only of a list of alternative
terminals and non-terminals?  Similar remarks apply to rule
[112] QuotAttrValueContent and rule [113] aposAttrValueContent.
- Steve B.

Accepted.

            
[[accepted]]
         

SECTION A.2: lexical structure
Some of the rules called "Named Terminals" should have a
/* ws:explicit */ comment attached to indicate that ignorable
whitespace may not be interspersed, namely
Digits, ExcapeQuot, HexDigits, and probably the ones
that are copied in from other recommendations (S, NCName, QName,
Char).  Note that the quantifiers + and *, as in
rule [16] Digits ::= [0-9]+, normally imply the ability to insert
whitespace between the repeated items.  Compare with
rule [42] FLWORExpr ::= (ForClause | LetClause)+ ...
which certainly permits whitespace between consecutive for and
let clauses.
This is almost every rule under "Named Terminals", which made
me wonder whether you intended all of these rules to have
an implicit /* ws:explicit */ comment.  However, that principle
would break down in a couple places: Pragma, MUExtension, and
SchemaGlobalTypeName.
Perhaps the solution is to move Pragma, MUExtension and
SchemaGlobalTypeName into the list of "Non-Terminals".
I think you are trying to list under "Named Terminals"
the kinds of tokens that would be recognized by a lexical
analyzer, and these three things seem more complex than usually
delegated to a lexer.
If you adopt this solution, you can simply state that the
entire category has a /* ws:explicit */ comment.  However,
this would still leave the problem of the duplicates of
these rules in the main body of the text, where they will probably
need to be individually flagged with /* ws:explicit */
- Steve B.

Accepted.

SECTION A.1: EBNF
It seems that whitespace is permitted between a dollar sign and
a QName, for example "for $ (: hello world :) prefix:localname"
seemingly is permitted, since rule [43] ForClause is not
tagged with /* ws: explicit */.  However, I have not observed a
single instance in the examples of whitespace between a dollar
sign and a variable name.  Regarding the dollar sign as an
operator rather than the first character of a variable name
seems to fly in the face of the inevitable user perception that
$i is a variable name (rather than $ is an operator and i is the
variable name).  It might be more intuitive to change rule [20]
to
  Varname ::= '$' QName /* ws: explicit */
and eliminate all the places where '$' appears as an operator
sign.
- Steve B.

Accepted (Scott's rejection of the comment).
Jim objects to allowing a variable reference such as "$ x"

SECTION A.1: EBNF
Rule [21] QName is a reference to another recommendation,
"Namespaces in XML", which does not have a notion
of "ignorable whitespace".  Instead, all permissible whitespace
is explicitly specified using the S non-terminal.  This means
that the EBNF conventions in "Namespaces in XML" is subtly
different from the EBNF conventions in the present document.
An EBNF in XQuery means that whitespace, comments, pragmas and
must-understand extensions are permitted between successive
items on the right hand side, whereas an EBNF in "Namespaces
in XML" does not have that convention.  It would be a mistake
for a reader of XQuery to follow the link to "Namespaces in XML"
and try to apply XQuery's whitespace rules to the rule found
at the end of the link.
I believe the intention is that XQuery's ignorable whitespace
is not permitted on either side of the colon in a QName.
Thus "prefix : localname" is not a valid QName for purposes
of XQuery, just as it is not permitted in a textual XML document.
Also, comments are not permissible on either side of the colon.
Perhaps the way to clarify this is to add a /* ws:explicit */
comment to this rule.  There may be other rules imported from
other recommendations that need attention on this issue as well.
- Steve B.

            
See [446].  Excerpt:
            
RESOLUTION: Scott to write a proposal This is the first of a series of
           whitespace  problems  that  Scott will work on. ACTION: Scott to write
           proposal  to  make note about using XQ rules for whitespace when
           other specs are referenced
         

Proposal accepted.

            
[[accepted]]
         

SECTION 4.12: function declaration
Rule [120] is marked with /* gn:parens */.  Actually, that
grammar note does not apply when declaring a function.
Following the keywords "declare" "function" there is no doubt
that the next QName must be the name of a function.  This
grammar note applies to function invocations, not declarations.
- Steve B.

Proposal accepted.

            
[[accepted]]
         

SECTION 4.10: xmlspace declaration
The keyword "xmlspace" suggests a connection with the xml:space
attribute.  The user might get the idea that "declare xmlspace
preserve" causes an explicit or implicit xml:space='preserve'
attribute in every element constructor, and "declare xmlspace
strip" causes an explicit or implicit xml:space='default'
attribute in every element constructor.  I don't think this is
your intention; I think you intend that the user must explicitly
generate any xml:space attributes, just as the user must
explicitly generate any other attributes. Some keyword other than
xmlspace would be preferable, perhaps "boundaryspace" or
"boundary space".
- Steve B.

			
            
DECIDED qt-2004Feb0642-01 resolved, closed,
by renaming xmlspace to boundaryspace.
		
         

SECTION 3.8: FLWOR expressions
Rule [46] WhereClause uses Expr on the right hand side and
not ExprSingle.  I haven't come up with any examples to show
that this is an outright bug, but it looks dangerous to allow
a comma operator not surrounded by parentheses in this context.
Also, a WhereClause such as "where expr1, expr2" is not intuitive
or easy to understand. It is not equivalent to
"where expr1 and expr2" and it is not equivalent to
"where expr1 or expr2".  This is seen from "where 0, 0".  The
effective boolean value of (0, 0) is true (any sequence of
length greater than 1 is true), whereas the effective boolean
value of both "0 and 0" and "0 or 0" is false.
Note that every other clause of the FLWOR expression is
built on ExprSingle.
- Steve B.

			
            
DECIDED: to change the parameter for WhereClause to Expr from
ExprSingle
[Liam note: this resolution may have been incorrectly recorded
in the minutes; the joint WGs comfirmed at a later meeting
that the document is now correct, however]
		
         

SECTION 3.7.3.1: computed element constructors
Under "content expression", step 4 says that it is an error
for two or more attribute nodes to have the same name.
Shouldn't there be a similar check in step 3 to insure that
there are no duplicate or conflicting namespace nodes?
- Steve B.

            
Already fixed.
         

SECTION 3.7.2: other direct constructors
Rule [18] PITarget is different from XML 1.0 rule [17],
which excludes "xml" in any combination of upper and lower
case characters.  It would be better to simply point to the
XML 1.0 definition of this non-terminal.
- Steve B.

            
See [445].  RESOLUTION: accepted, refer to production in XML
         

            

            
RESOLUTION: accepted, refer to production in XML
         

            
[[accepted]]
         

SECTION 3.7.2: other direct constructors
The XQuery Data Model, section 6.6.3 "Comment information items",
says that "Although the data model is able to represent comments,
it may be unnecessary or even onerous for some applications to do
so.  Applications should construct nodes in the data model to
represent comments. The decision whether or not to represent
comments is considered outside the scope of the data model,
consequently the data model makes no attempt to control or
identify if any or all comments are ignored."
Does this mean that support for direct and computed comment
constructors is optional for an XQuery implementation?
- Steve B.

SECTION 3.7.2: other direct constructors
It says "Each of the above constructors is terminated by the
first occurrence of its ending delimiter."  Okay, fine.
Then: "...the content of an XML comment may not contain
the string '-->'".  Actually, the restriction in XML 1.0,
section 2.5 "Comments", rule [15], is
that a comment may not contain "--", and this restriction is
reiterated in the XQuery Data Model, section 6.6.1 "overview"
(of comment nodes), item 2.  Thus "<-- -- -->"
is an illegal comment in XML 1.0.  This should be forbidden
here as well, since the result cannot be well-formed XML.
- Steve B.

            
See [444].  RESOLUTION:  partly  accepted  already,  resolving jan0093, but
           should also be excluded from the BNF
         

            

            
Don and Michael R thought this was already done
            
RESOLUTION: partly accepted already, resolving jan0093, but should
            
also be excluded from the BNF
         

            
[[accepted]]
         

SECTION 3.7.1.3: content
Rule 1)d) says that the type annotation of a copied
element node is set to xs:anyType.  You don't say what
happens to the other PSVI contribution to the element's
data model, the nilled property.  Is it preserved or
set to some fixed value?
- Steve B.

SECTION 3.7.1.3: content
Rule 1)d) third sentence says "Copied element nodes are given
the type annotation xs:anyType and copied attribute nodes are
given the type annotation xs:anySimpleType."  Since you are
discarding the type information, don't you also have to
regenerate the string value of the node, if it has not been
preserved?
- Steve B.

SECTION 3.7.1.3: content
Regarding step 3) in 3.7.1.3 on attribute nodes: at this point in section
3.7.3.1 "Computed element constructors", it talks about the
possibility of having namespace nodes at the beginning of the
content sequence, whereas this section is simply silent about them.
Taken literally, that seems to mean that any namespace nodes
left in the content sequence are still present at step 5) and
consequently become either "children" or "attributes" of the
element.  It seems highly likely that you either mean to treat
namespace nodes as an error, or else handle them the same as
in section 3.7.3.1.
- Steve B.

SECTION 3.7.1.3: content
Step 2), which raises an error when a document node is
found in an enclosed expression in element content, is not
user-friendly.  The friendly thing to do would be to strip
off the document node and treat it as a sequence of its top-level
children.
- Steve B.

            

            
DUPLICATE - closed in today's telcon under +qt-2004Feb0495-01.
         

SECTION 3.7.1.3: content
Rules 1)a) and b) appear to be in the wrong order.  If character
references are expanded prior to looking for boundary whitespace,
then character references for whitespace, such as  ,
are likely to be treated as boundary whitespace and deleted,
contrary to the explicit statement in 3.7.1.4 "Whitespace in
element content".  Implementing this as written will require
keeping track of the origin of every whitespace character coming
out of step a.
- Steve B.

            

            
Rejected, since if rules A and B were reversed, we would be
            
constructing a text node, then looking for entity references, we
            
might create a new entity reference at run-time. We have the right
            
rule in the spec - "whitespace characters generated by character
            
references such as   or by CDATA sections are not considered
            
to be boundary whitespace". We accept that the rules, as given,
            
describe the result of the implementation, and not the algorithm.
         

            
Rejected, since if rules A and B were reversed, we would be
constructing a text node, then looking for entity references, we
might create a new entity reference at run-time. We have the right
rule in the spec - "whitespace characters generated by character
references such as   or by CDATA sections are not considered
to be boundary whitespace". We accept that the rules, as given,
describe the result of the implementation, and not the algorithm.
         

SECTION 3.7.1: direct element constructors
Consider the following example:
<a>{attribute b {1}}</a>
Question: is this acceptable syntax, or is it an error because
the }} is interpreted as a literal for right curly brace?
If it is not acceptable, then it would be helpful to say that
if the user has an expression requiring two successive }s, then the
user should put whitespace between them.  If it is acceptable,
then you should qualify that }} is interpreted as a literal for
a right curly brace unless used in a context where two successive
right curly braces would be acceptable.
According to the tables in A.2.2, }} is only recognized in state
ELEMENT_CONTENT.  I simuled the rules in these tables on the
example above and found that it is in state OPERATOR when the }}
is encountered.  The OPERATOR state recognizes } but not }}.
My tentative conclusion is that the example is valid and }} can be used to close two expressions, and not always as a literal for right curly brace.
This appears to be the user-friendly answer, but I worry that
users will find it hard to know when }} is a literal for a
right curly brace and when it is two closing curly braces.
One solution would be to do away with }} as a literal for
curly brace.  Instead, you might define a character reference.
- Steve B.

            
See [443]. RESOLUTION: no action, oracle accepted it's not needed.
         

            

            
RESOLUTION: no action, oracle accepted it's not needed.
         

            
[[rejected]]
         

SECTION 3.5.3: node comparisons
Regarding << and >>, I think that these should return true or
false only when the comparands are nodes of some common supernode.
If x and y are in completely unrelated documents, how can you
decide whether x << y or x >> y?  I know that The Data Model
section 2.4 "Document order" says that there is an
implementation-dependent total ordering of all documents which is
stable during the execution of an expression evaluation.
An implementation-dependent order does not do the user any good,
and making it stable can not add value in the user's eyes
to a feature with no value anyway.  This merely
burdens implementations with a useless requirement.
I think it would be preferable to say that << and >> are
partial orders, returning an empty sequence if two nodes have no
common supernode.
- Steve B.

            

            
Rejected because (1) path expressions that span documents are not
            
well-defined in the absence of document order, and (2) adopting
            
this proposal would frequenty require implementations to determine
            
whether two nodes are in the same document, imposing unnecessary
            
overhead.
         

            
Rejected because (1) path expressions that span documents are not
well-defined in the absence of document order, and (2) adopting
this proposal would frequenty require implementations to determine
whether two nodes are in the same document, imposing unnecessary
overhead.
         

SECTION 3.5.2: general comparisons
>From the examples, second bullet illustrates that = is not
transitive.  I think it would also be useful to point out that
= and != are not logical negations of each other.  For
example, (1, 2) = (1, 3) is true (because 1=1), and
(1, 2) != (1, 3) is also true (because 2 != 3).  In fact,
almost all of our accustomed rules about these comparison
operators do not hold.  Thus
(1, 2) > (1, 3) because 2 > 1; (1, 2) < (1, 3) because 1 < 3.
In fact, all six relationships are true between (1, 2) and (1, 3).
- Steve B.

            

            
Classified as editorial, and left to editor's discretion.
         

SECTION 3.1.1 : literals
There is no description, here or in Appendix A.1,
of what is or is not a valid CharRef,
merely that it is "an XML-style reference to a Unicode character,
identified by its decimal or hexadecimal code point."
The use of "XML-style" is unnecessarily vague.  The answer is
that it depends on whether the implementation is using XML 1.0
or XML 1.1 lexical rules.  In either case, it is given by
the Well-formedness Constraint: Legal Character" in section
4.1 of either [XML 1.0] or [XML 1.1].  This rule should be
cited here.  Otherwise it would appear that �
conforms to the EBNF for CharRef, and it should not.
- Steve B.

            
See [442].  RESOLUTION:   Agreed,  link  directly  to  the  XML  Specification,
           a reference with the discliamer that it could be either 1.0 or 1.1
         

            

            
Closed with editorial change by Don.
         

            
[[accepted]]
         

SECTION 3.1.1: literals
May an implementation define additional PredefinedEntityRefs?
For example, could an implementation define € as € ?
- Steve B.

			
            
This was decided to be conformance at meeting 180
https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Apr/0156.html
Andrew: the document already answers this, the answer to
"May an implementation define additional PredefinedEntityRefs?"
is
yes with a must-understand extension to XQuery.
Oracle accepted this.
RESOLVED: qt-2004Feb0606-01 closed, no change to the document.
		
         

SECTION 2.6.6.1: XQuery flagger
To assure portability, the flagger must adhere to the XML 1.0 lexical rules, since it is impossible to know whether
the platform to be ported to will use XML 1.0 or XML 1.1.
Note that Section A.2 "Lexical structure"
says that implementations can use either XML 1.0 or XML 1.1
conventions.
- Steve B.

			
            
no more flagger.
		
         

SECTION 2.6.6.1: XQuery flagger
Besides flagging must-understand extensions, the flagger should
call out any vendor extensions that are not must-understand
extensions.  Such extensions are probably inevitable (my
prediction is that vendors will find the must-understand
extension syntax too lengthy for their favorite extensions).
In addition, you have not specified "no supersetting" as was
done for Ada.  The first sentence of section 2.6.6 "Must-understand
extensions" says "an implementation may extend XQuery functionality
by supporting must understand extensions."  This does
not say "an implementation may not extend except through
must-understand extensions".  Even if you had such a sentence,
vendors will still be tempted to add extensions, and you lack
the buying power of DoD to enforce a "no supersetting" rule.
- Steve B.

			
            
no more flagger
		
         

SECTION 2.6.6: must-know extensions
Definition, last sentence: A must-understand extension may be
used anywhere that ignorable whitespace is allowed."
The term "ignorable whitespace" is not defined.  Section 2.6.5
"Pragmas" has a similar sentence, but at least it is followed
immediately by the statement "See A.2 Lexical structure for the
exact lexical states where pragmas are recognized" which effectively
defines the term for that context, but that sentence limits itself
to pragmas and does not apply to must-know extensions.  There is
a similar sentence in 3.1.6 "Xquery comments", which again is
self-limited to just ExprComments.
- Steve B.

Accepted.

SECTION 2.6.6.1: XQuery flagger
Judging from the tables in A.2 "Lexical rules", it is a syntax
error to place a comment, pragma or must-understand extension
between "for" and "$" when a ForClause is intended.  Implementations
will want to relax this to be more user-friendly in the case of
comments, and they may also wish to define pragmas and
must-understand extensions in this position.  There are many
similar restrictions on the placement of comments, pragmas and
must-understand extensions in A.2 which implementations will
want to relax.  Any user application that avails itself of
such a relaxation becomes non-portable.  This section already
requires the XQuery Flagger to identify the must-understand
extensions.  The flagger should also point out any violations
of the lexical rules of A.2.2, such as more freedom to place
comments and pragmas in various places, since such violations
will be non-portable.
- Steve B.

            
Accepted: no specific change here,
			falls out of resolution for
			qt-2004Feb0658-01.
         

            

            
Already Done.  Issue closed.
         

            
StB: This comment goes back to where a comment is allowed. Is a comment
allowed between a "for" and the "$" of the variable. I think we decided
the answer is yes.
So this is a non-issue.
Accepted: no specific change here, falls out of resolution for qt-2004Feb0658-01.
         

SECTION 2.6.6.1: XQuery flagger
First para, last sentence: "If the XQuery Flagger is enabled,
a static error .. is raised if the query contains a must-understand
extension."
Assuming that a pragma can contain a must-know extension
(a possibility raised in another comment),
what are the consequences for flagging?  Normally an implementation
is free to ignore a pragma if it does not support it, so
an XQuery expression that contains a pragma that contains a
must-understand extension should run on any implementation, and
there is no reason to flag it.  But this sentence says that it
should be flagged.
- Steve B.

            
Dependent on qt-2004Feb0598-01,
			which I trust will be resolved in the
			negative. Short answer: no
         

            

            
Already Done.  Issue closed.
         

            
ScB: Since we don't have nesting, the short answer is no.
StB: So a pragma can contain an must-understand extension?
ScB: No. A pragma can't contain extensions.
StB: But it'll just look like a nested comment, right?
ScB: Yes, but this has to do with a pragma containing an extension. In
the
     case of pragmas in extensions, they're not even comments, they're
just
     characters. Basically, this can't happen.
Proposal: no.
Accepted.
         

SECTION 2.6.6: must-understand extensions
Making the pragma lexically an overloading of a comment
is a good idea, because an implementation that has no pragmas
can simplify their grammar to treat pragmas the same as comments
(ie, don't distinguish them as separate lexical categories).  The
same does not apply to must-understand extensions.  An
implementation that has no must-understand extensions must still
be on the look-out for them, because encountering a must-understand
extension when you have none is a syntax error.  For that reason,
it seems like a bad idea to make the syntax for a must-understand
extension be an overloading of the comment syntax.  This means that
a simple implementation with neither pragmas nor must-understand
extensions can not treat anything beginning with (: as a comment.
Instead it is still burdened with the need to detect "(:: extension"
because that is not a comment, it is a must-understand extension
(and, for that implementation, a syntax error).  Some other way of
denoting a must-understand extension would be preferable.
Some ideas are
MUExtensions ::= "{:" QName ExtensionContents* ":}"
MUExtensions ::= "ext" "{" QName ExtensionContents* "}"
- Steve B.

            
Proposal: No Change.  DC will clarify this as part of his editorial changes.
         

            

            
Already Done.  Issue closed.
         

            
StB: Just generally saying that (: and (:: are bound to cause confusion.
MH: I think there are items further down that identify a bunch of
    issues related to this confusion.
AE: I don't recall exactly how we came to this syntax.
PC: It's a special kind of comment. If you don't understand the
    pragma, it's just ignored.
JR: I think letting them nest and contain comments would make sense.
ScB: I think we turn this over to StB/MH, to see if they can get a
     proposal going in email.
MH: It's the nesting that gets confusing.
DC: Within a comment, the content is treated just like content. If you
    put a pragma inside a comment, it wouldn't be recognized as a pragma
    and ::) would terminate the comment and the rest would be a syntax
error.
ScB: No, we allow nested comments so it would parse correctly.
Two proposals: 1. no nesting comments in pragmas or pragmas in comments.
               2. symmetric nesting of comments and pragmas
PC: Are both alternatives feasible?
ScB: Yes.
ScB: We've agreed to not allow extensions in extensions, so I think what
we've got now works. Mary's happy, right?
MH: Yes, mostly.
Propose: resolve without change.
Accepted. DC will clarify this as part of his editorial changes.
         

SECTION 2.6.5: pragmas
Can a pragma include a must-understand extension?  For example,
(:: pragma my:pragma (:: extensions my:ext ::) ::)
In this example, is "(:: extension my:ext ::)" to be interpreted as a must-understand extension sitting in a place where ignorable whitespace can go, or is it the value of PragmaContents?
What are the semantics of this ?
- Steve B.

            
Proposal: No.
         

            

            
Already Done.  Issue closed.
         

            
ScB: No, the form of a must-understand extension would terminate the
pragma.
Accepted.
         

SECTION 2.6.5: pragmas
Can a Comment be nested in a Pragma?  Section 3.1.6
"Xquery comments" says that "Comments may be used anywhere
ignorable whitespace is allowed."  In the following example:
(:: (: comment 1 :)
pragma (: comment 2 :)
prefix (: comment 3 :)
: (: comment 4 :)
localname (: comment 5 :)
contents (: comment 6 :)
more contents (: comment 7 :) ::)
which of the comments are acceptable?
- Steve B.

            
The answer should no.  Neither should comment nesting rules apply.
         

            

            
Already Done.  Issue closed.
         

            
ScB: Proposal: no a pragma can't include a comment.
Accepted.
         

SECTION 2.6.5: pragmas
Rules [1] "Pragma" and [5] "PragmaContents" are ambiguous
because they do not exclude the possibility of "::)"
being among the PragmaContents* .  See the way XML 1.0
rule [15] defines "Comment".  Actually, that rule
prohibits "--" from being in the body of a Comment,
and not merely "-->", perhaps so that you only need one
character lookahead to decide if the comment is coming to
an end.  You may want to have a similar rule excluding
"::" from the body of a Pragma (or excluding "::)" if
you are willing to tolerate two-character look-ahead).
Similar remarks apply
to rule [2], "MUExtension".  As for Rules [3] "ExprComment"
and [4] "ExprCommentContent", you want to exclude
":)" from ExprCommentContent.
- Steve B.

Make it explicit that "(::" etc. have no meaning within pragma's and extensions.  "::)" should not be allowed as pragma or extension content.

Don objects to this grammar notation on grounds of
                   readability. Applies to many productions including
                   Pragma, MUExtension, Comment, CDataSection, etc.
                   Scott proposes to break each unreadable production
                   into two parts. For example, the Pragma production
                   will include PragmaContent on the RHS, and
                   PragmaContent will be defined separately using
                   a BNF "subtraction" operator with an explanatory
note.
                   Issue remains open pending review of a new draft
                   to be prepared by Scott.

            

            
Already Done.  Issue closed.
         

            
ScB: Proposal: comments and "(::" should have no meaning in the
     extension or pragma context. You cannot have a comment within a
pragma
     or a pragma within a comment. (A pragma within a comment is just
content.)
StB: It is legal, but it's just part of the comment? And they have to
nest properly.
MH: So you can't have a comment within a pragma?
ScB: A comment in a pragma is just part of the pragma.
Accepted.
         

SECTION 2.6.2: static typing feature
Section 3.7.3.1 "Computed element constructors" gives an
interesting example of a way to construct an element with the
same name as a given element, but with a different content.
The note following the example says that the example is not
portable because it will not work under the Static Typing
Feature.  To me, this example calls into question the utility
of the feature.  The note gives a workaround, using the function
fn:exactly-one, and the F&O has additional functions which will
overcome certain other static typing issues.  The conclusion I
draw is that anyone interested in portable programming will
be required to use these functions as guards to explicitly
disable the static typing feature, in case the application is
ported to such an implementation.  The purpose of the guard
functions is to give the application precisely the behavior it
would have had if the static typing feature were not supported.
I am wondering if the problem is in an overly fastidious
notion of what static typing should do for the user.
To me, a function invocation fct(arg) whose sole parameter is
declared to be item() or item()+ with an argument arg whose static
type is item()? or item()* does not look like a static type error,
because it is possible that the command will succeed at run-time.
I suggest that the static typing feature should raise type
errors when the static type of an actual argument or operand
has empty intersection with the required type in that position.
In such a case it is a certainty that there would be a run-time
error, and therefore a user benefit to provide early detection of
such errors.  I can see this as a user benefit even if the
code is unreachable, because it probably reveals a logic error on
the user's part.  But to raise static errors for situations
that might run successfully on certain inputs seems like a
disservice to the user.
- Steve B.

            49. +qt-2004Feb0593-01 ORA-XQ-092-B: definition of static typing is too
rigorous to be useful
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0593.html
    Andrew/Dana  If static type is off then there is no way to tell the
    level of conformance.
    Jonathan  Need more user experience. Hesitant to close issue.
    Comment is too general to be useful.
    Michael R.  No reason to change rigorosity.
    (Dana and Andrew agreed)
    Dana  Better to raise a Formal Semantic issue instead.
Issue closed with no further action.
         

            

            
Andrew/Dana  If static type is off then there is no way to tell the
            
level of conformance.
            
Jonathan  Need more user experience. Hesitant to close issue.
            
Comment is too general to be useful.
            
Michael R.  No reason to change rigorosity.
            
(Dana and Andrew agreed)
            
Dana  Better to raise a Formal Semantic issue instead.
            
Issue closed with no further action.
         

SECTION 2.5.2: Handling dynamic errors
Third para, second sentence: "For example, an error value might
be an integer, a string, a QName, or an element."  In Functions
and Operators section 3 "The error function" second para third
sentence, it says "Each error defined in this document [ie,
F&O] is identified by an xs:QName that is in the namespace
associated with the xdt: prefix."  This seems like a good
convention, that all dynamic errors specified by the W3C
specification are QNames in a single namespace.  It would be
good if the rest of the specifications in the XQuery suite
adhered to the same convention.  This may well be your intent
already, in which case the sentence I started with, "For
example, an error value might be an integer..." should be
construed as referring to values permitted to a user invocation
of fn:error.  However, in the context in which it appears, it
seems to be referring to dynamic errors specified by the
XQuery language specification.
- Steve B.

            

            
Closed because the issue is addressed by Andrew's error proposal,
            
which was adopted 4 May.
         

SECTION 2.6.1: Schema import feature
It says: "If more than one schema is imported, the definitions
contained in these schemas are collected into a single pool of
definitions. This pool of definitions must satisfy the conditions
for schema validity set out in Sections 3 and 5 of [XML Schema]
Part 1. In brief, the definitions must be valid, they must be
complete, and they must be unique, that is, the pool of definitions
must not contain two or more schema components with the same name
and target namespace. If any of these conditions is violated, a
static error is raised.[err:XQ0012]".  This seems to contradict
the assertion in Section 2.2.5 "consistency constraints", where
it says that "enforcement of these consistency constraints is
beyond the scope of this specification".  I think that you have
it right here in section 2.6.1 and wrong in section 2.2.5.
- Steve B.

            47. +qt-2004Feb0591-01 ORA-XQ-088-C: enforcement of imported schema
consistency
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0591.html
    Don - Imported schemas must be consistent otherwise error is raised.
    Michael K - Not required to be detected by Query.
    Jonathan -  Raised error if schemas are inconsistent.
    Liam two issues as he sees it:
     Buxton comment correct?
     Changed how schema import works  Maybe taking to mailing list?
Issue closed with no further action.
There is no contradiction as suggested by the comment, because
these are two different kind of constraints.
         

            

            
Don - Imported schemas must be consistent otherwise error is raised.
            
Michael K - Not required to be detected by Query.
            
Jonathan -  Raised error if schemas are inconsistent.
            
Liam two issues as he sees it:
            
Buxton comment correct?
            
Changed how schema import works  Maybe taking to mailing list?
            
Issue closed with no further action.
            
There is no contradiction as suggested by the comment, because
            
these are two different kind of constraints.
         

SECTION 2.2.5 : Consistency constraints
First para, last sentence: "Enforcement of these consistency
constraints is beyond the scope of this specification."
I can think of three ways a violation could occur:
a) The XQuery language specification itself specifies a violation
of one of these constraints.  Of course, we are fallible and
mistakes happen, but presumably the working group will endeavor
to fix any such inconsistencies when they are reported.
b) The initialization of the static and dynamic context provides an
inconsistent 'start state' for XQuery expression evaluation.
This can be handled in either of two ways:
  i) by specifying that the XQuery implementation shall begin
     by checking its static and dynamic context for violations
     and report any violations as exceptions.
  ii) that might be regarded as too much overhead, so you
     might prefer to specify 'lazy' constraint checking, only
     checking a value when the value is referenced, or some
     aspect of a value is referenced.
c) The violation occurs dynamically during expression evaluation.
This can be handled by specifying that the constraints shall
be checked whenever a value is constructed.
- Steve B.

            46. +qt-2004Feb0587-01 ORA-XQ-080-C: Enforcement of consistency constraints
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0587.html
    Andrew  It may be a duplicate from another comment (????).  Don had an
    item regarding solution.  Add sentence on top of consistency constraints
    paragraph.
This issue is closed as resolved by ORA-XQ-217-C  No further action required
         

            

            
Andrew  It may be a duplicate from another comment (????).  Don had an
            
item regarding solution.  Add sentence on top of consistency constraints
            
paragraph.
            
This issue is closed as resolved by ORA-XQ-217-C  No further action required
         

SECTION 2.2.3.2: dynamic evaluation phase
Second para, last sentence: "If the Static Typing Feature
is not in effect, an implementation is allowed to raise type-related
warnings during the static analysis phase, but it must proceed with
the dynamic evaluation phase despite these warnings. In this case,
type errors must be detected and raised during the dynamic
evaluation phase." This sentence makes the Static Typing Feature
all-or-nothing, precluding what I will call a
partial implementation of the Static Typing Feature, in which
an implementation detects and raises some, but not all, type errors,
and does not progress to the dynamic evaluation phase if it finds
a type error.  This does not appear to do the user any good.
It means that if the implementation does not do a total job of
type error checking, then effectively it has not done any at all
(except to raise warnings).  I think it would be better to say
"if the Static Typing Feature is not in effect, then it is
implementation-defined what type errors are detected and raised
during the static analysis phase, aborting the dynamic evaluation
phase."
- Steve B.

            45. +qt-2004Feb0585-01 ORA-XQ-078-B: XQuery should permit partial
static typing
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0585.html
    Jim Melton - yes If implementation does not support static typing it can
    detect whichever errors it can.
    Don -  Wording was already changed as per Oracle's suggestion.
    Dana  If static typing not supported, then type errors must be
    raised during dynamic evaluation
    Don  Yes they may be.
Issue closed with no further action.
         

            

            
Jim Melton - yes If implementation does not support static typing it can
            
detect whichever errors it can.
            
Don -  Wording was already changed as per Oracle's suggestion.
            
Dana  If static typing not supported, then type errors must be
            
raised during dynamic evaluation
            
Don  Yes they may.be
            
Issue closed with no further action.
         

SECTION 2.2.3.1 : Static analysis phase
sixth para: "if the Static Typing Feature is in effect and the
static type assigned to an expression other than () is empty,
a static error is raised."  Does this mean that "let $i = ()"
is a static type error?
- Steve B.

            44. +qt-2004Feb0583-01 ORA-XQ-076-C: Is "let $i = ()" permitted?
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0583.html
    There are two issues issues here as viewed by Liam
       is not a static type error as suggested by Steven Buxton
       Is the behavior the desired one.
    Andrew - This Rule may expressed too widely
    Liam  Proposed closed this issue.
    It is not a static error, but if "return $i" is added, it
    becomes one.
    Andrew to follow up with a question to see is group ok with the current
    Behavior.
    Mary: Keeping it open it's a bad idea.
Issue closed with no further action.
         

            

            
There are two issues issues here as viewed by Liam
            
is not a static type error as suggested by Steven Buxton
            
Is the behavior the desired one.
            
Andrew - This Rule may expressed too widely
            
Liam  Proposed closed this issue.
            
It is not a static error, but if "return $i" is added, it
            
becomes one.
            
Andrew to follow up with a question to see is group ok with the current
            
Behavior.
            
Mary: Keeping it open it's a bad idea.
            
Issue closed with no further action.
         

SECTION 2.1.2: dynamic context
Available documents: it says "the set of available documents is
not constrained by the set of statically-known documents."
Constrained in what direction?  Do you mean "a document may be
available even though it is not statically known"?  Do you
mean "a document may be unavailable even though it is statically
known"?  Do you mean both of these?
- Steve B.

            43. +qt-2004Feb0576-01 ORA-XQ-073-C: "available documents is not
constrained by ... statically known documents"
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0576.html
 This issue was partly solved under section 2.1.1.
   Jim Melton - will like a more specific note regarding weather
      statically  known Documents are available,
   Don -  This is already specific enough.
   Andrew  Question is already answered.
   Jim -  Said he can live with current wording.
Issue closed with no further action.
         

            

            
This issue was partly solved under section 2.1.1.
            
Jim Melton - will like a more specific note regarding weather
            
statically  known Documents are available,
            
Don -  This is already specific enough.
            
Andrew  Question is already answered.
            
Jim -  Said he can live with current wording.
            
Issue closed with no further action.
         

SECTION 2.1.1: Static context
Statically known collections: it says that the default type of
a collection is node()?.  But in 2.3.4 "Input sources" it says
that the result of invoking fn:collection can be "any sequence
of nodes", that is, node()*.
- Steve B.

            42. +qt-2004Feb0565-01 ORA-XQ-069-E: what is the default type of a
collection?
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0565.html
Issue closed with no further action.
Default type of a collection should node()*.
         

            

            
Issue closed with no further action.
            
Default type of a collection should node()*.
         

SECTION 2.1.1: Static context
In-scope collations: it says that a collation "may be regarded
as an object that supports two functions...".  In F&O section 7.5
"Functions based on substring matching" fourth paragraph, it
says "For other functions, such as fn:contains(), the collation
needs to support an additional property: it must be able to
decompose the string into a sequence of collation units...".
This "additional property" appears to be the same as the second of the two functions in a collation object.  The choice of the words
"it must be able to..." in F&O suggests that F&O regards the
presence of this second function as optional.  Also, in F&O 7.5.1
"fn:contains", second para, last sentence, it says "If the
specified collation is unsuitable ... an error may be raised."
What would make a collation unsuitable?  The reader is left
with the impression that one thing that might make a collation
unsuitable is if the collation does not support the second
function.  (Some other possibilities are mentioned in
F&O 7.31 "Collations", including issues with normalization.)
Summary: please clarify
whether the second function is a mandatory or an optional
part of a collation object.  I am entering separate comments
asking to clarify some of these points in F&O as well.
- Steve B.

            
There was a feeling we had already dealt with this issue or others
like it. KK pointed to 2004Feb0990-01, an F+O issue, "Please define
collations", which was accepted and closed in August.
https://lists.w3.org/Archives/Public/public-qt-comments/2004Aug/0123.html
JM: Please tell the meeting that it is my opinion that the changes we
accepted for "minimal matching" should resolve this question for the
purposes of F&O at least, and I think we've otherwise satisfactorally
defined collations. KK: would it be good for the language book to contain
a reference to the F+O definition.
RESOLVED: no action required, DC to consider making a cross-reference
to the F+O definition.
         

SECTION 2.1.1: static context
Regarding in-scope namespaces, an implementation should be allowed
to predefine some namespaces for the convenience of the intended
user community.  Such namespaces might be used to reference
types and functions that are supplied with the product, for example.
Naturally, these should be implementation-defined namespaces
(ie, documented to the end user).  It would be helpful to say
explicitly that there may be implementation-defined namespaces
among the predefined namespaces.
- Steve B.

            

            
AE: Points out that this is given in normative appendix C.1.
            
RESOLVED WITH NO CHANGE.
         

SECTION 2.1.1: static context
Regarding in-scope namespaces, it says "some namespaces are
predefined...".  Of course the namespace with prefix xml: is
always defined; are there any others?  I think you intend the
list just before section 2.1, defining the prefixes xs, xsi,
fn, xdt and local.  However, that list is described as
"This document uses the following predefined namespace prefixes..."
which can be interpreted to mean that you are merely defining
your metalanguage for the remainder of the specification.
Indeed, the statement following the list that "where the meaning
is clear... built in XML SChema typenames such as integer and
string are used without a namespace prefix" is clearly refering
only to your metalanguage (the user could never get away with
referencing these in the default namespace if they are actually
in the xs: namespace).  Please clarify what namespaces are
predefined in the in-scope namespaces.
- Steve B.

            

            
AE: Points out that this is given in normative appendix C.1.
            
RESOLVED WITH NO CHANGE.
         

            
See 4.11 Namespace Declaration, which lists them.  Also C.1
         

SECTION 2: Basics
First sentence: "... the expression, which is a sequence of Unicode
characters."  Certainly in order to support XML, an implementation
will need to support Unicode in its data values, but is this
necessary in a source language expression?  SQL (ISO/IEC 9075)
distinguishes what it calls "the source language character set",
which is not necessarily the same as any character set in the
data.  Of course, XQuery expressions can include literals for
Unicode strings, and XQueryX, being expressed in XML, is
necessarily expressed in Unicode as well.  But wouldn't it be
sufficient for XQuery to allow the source language character set
to be any implementation-defined character set, provided there
was an implementation-defined mapping to convert the source
language into Unicode?  For example, if a user is working in an
environment with EBCDIC or Shift-JIS editors, the user will
probably want to compose his XQuery expressions in those character
sets.
- Steve B.

            
See [441]. RESOLUTION: we've been here before, closed with no further action
         

            

            
ADOPTED RESOLUTION:
            
ACTION-ITEM-177-02: Jim Melton to provide proposed wording.
            
DONE. See:
            
https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Apr/0056.html
            
Add a sentence (actually, an Informative Note) following the first
            
sentence of the first paragraph in Section 2, "Basics".  That new
            
sentence/note should read "Note: This specification makes no
            
assumptions or requirements regarding the character set encoding of
            
strings of Unicode characters."
         

SECTION 2.2.3.1: Static Analysis Phase
    "The operation tree is then normalized by making explicit the implicit operations such as atomization, type promotion and extraction of Effective Boolean Values (step SQ5)."
In step SQ6, there is a static type checking phase.
In SQ5, if the type checking (step SQ6)has not occurred,
how can it do 'type promotion' which requires type information
on the operation tree?
Does this mean SQ5 and SQ6 are not sequentially done in order ?
Probably need to iterate between 5 and 6 ?
- Steve B.

            

            
MR and JS explain the way it is done by normalization. It can be done
            
sequentially or not. The formal semantics does it sequentially.
            
MR: Have the pointer to formal semantics, but do not change current
            
wording.
            
DC: pointer is already there.
            
RESOLVED WITH NO CHANGE.
         

SECTION 2.2.5: Consistency Constraints
There should be something here to say when these consistency constraints need to hold. For example, "All variables defined in in-scope variables must be defined in dynamic variables" won't be true until execution after all external variables have been bound.
- Steve B.

            

            
DC: Constraints define the circumstances under which XQuery is
            
well-defined. So there is no way to define errors or detect it.
            
This seems true for all except for the one referred to in
            
+qt-2004Feb0548-01 which is only in this category for XPath.
            
PC: Proposal: Make variable one XPath only. Add sentence to explain
            
axiomatic nature.
            
JM: proposed wording :
            
"This specification does not define the results of an XQuery[/XPath]
            
expression under any condition where one or more of these constraints
            
are not satisfied."
            
MR: Just need to make sure that the variable alignment is not removed
            
from XQuery.
            
AE: This is still guaranteed by section on dynamic context.
            
ADOPTED RESOLUTION:
            
Deleting bulleted item in Oracle comment for both.
            
Adding Jim's proposed wording for both.
         

Section 3.13 Validate Expressions
Technical
The definition of lax validation is not aligned with the XML Schema
definition of lax validation that checks for presence in the ISSD on a
level-by-level basis. This should be fixed.

            

            
DC: Corrected in current editor WD.
            
FIXED.
         

Section 3.13 Validate Expressions
Technical
We consider the validate expression (and the implicit validation on
element construction) to be too complex and potentially confusing to
users for the following reasons:
- Validate will validate against all ISSD. Most usecases we come across,
users want to validate against a specific output schema. Since that can
be done outside of the XQuery statement, the validate expression becomes
less useful.
- The schema context part of validate is pretty complex and most users
will not understand it at the beginning. This looks like a good vNext or
optional feature.
Thus we would like to propose:
1. Make default validation mode to be skip
2. Remove Schema context from the spec
3. Make support for validation modes lax and strict and the validate
keyword an optional feature.
(See also MS-XQ-LC1-089).

            
Resolved by the following:
1. Make default validation mode to be skip
2. Remove Schema context from the spec
3. Make support for validation modes lax and strict and the validate
keyword an optional feature
Action on Jonathan to move #3 as an issue in the conformance cluster.
         

Section 3.10 Conditional Expressions
Technical
As others, we would like to recommend making the else clause optional
(defaulted to else ()) and add a ending token (e.g. end, endif) to have
a disambiguation for the dangling else clause.

            
Same as qt-2004Jan0378-01
            
PaulC: so, new evidence to make this decision?
anybody that can't live with changes?
            
Yes: at least Don, Robie.
            
So, resolved: rejected.
         

            

            
DC: else is still required.
            
Was done at Mandelieu F2F and REJECTED.
         

            
[[rejected]]
         

Section 3.8.3 Order By and Return Clauses
Technical
Provide an XQuery prolog statement affecting the static context to
define empty sort default.

            
Michael R asks for an XQuery prolog statement affecting the static
context to define empty sort default.
Proposal: declare default order empty [choices: least greatest]
Jim asked that the scope be made clear. Left to the editors.
Don asked for approval of the following values and got it:
schema component name: default empty ordering for empty sequence
default predefined value: none
can it be overwritten by an implementation : yes
can it be overwritten by query: yes, by a prolog or orderby clause
scope: module resource
consistency rules: only one declaration per prolog
RESOLUTION: Resolved by the adoption of the proposal:
declare default order empty [choices: least greatest]
         

Section 3.7.3.7 Computed Namespace Constructor
Technical
How can I declare a default namespace? I always have to provide the
NCName. Can we make the NCName optional and then make it define the
default namespace?

            
this has been subsumed by a response to an earlier comment
         

3.7.3.5 Computed Processing Instructor Constructor
Technical
Why is the rule based on using Qname values instead of NCName values? We
would prefer if we can raise a type error when a Qname is provided.

            

            
Some discussion to investigate impact of proposed change. Since
            
xs:NCName is a subtype of xs:string we can just drop xs:QName.
            
ADOPTED.
         

            
Some discussion to investigate impact of proposed change. Since
xs:NCName is a subtype of xs:string we can just drop xs:QName.
ADOPTED.
         

Section 3.7.3.5 Computed Processing Instructor Constructor
Technical
Also allow an instance of xdt:untypedAtomic as a name value.

            

            
ADOPTED.
         

            
ADOPTED.
         

Section 3.7.3.1 Computed Element Constructor
Technical
"A computed element constructor automatically validates the constructed
node, using the validation mode and validation context from its static
context, as described in 3.7.1.5 Type of a Constructed Element. If the
name of the constructed element is specified by a constant QName, this
QName is added to the validation context for nested expressions. On the
other hand, if the name of the constructed element is specified by a
name expression, the validation context for nested expressions is set to
global.":
The fact that the validation context stays global inside a constructor
that has a name expression will be confusing and hard to explain. Users
will expect that the validation is done at runtime, so the validation
context in this case should be a runtime context. We can solve this by
either not doing implicit validation on element construction (regardless
if literal or computed element constructor), or by saying that the
context will not be known until runtime in this case.

Section 3.7.1.5 Type of a Constructed Element
Technical
"constructed element has an attribute that causes it to be validated as
an integer:": This is only true if validation mode is lax or strict and
no conflict exists. If a conflict exists, then an error is raised and if
validation mode is skip the value is still untyped.

            

            
DC: This sentence has been removed by an action item from Mandelieu to
            
reword this section.
            
Comment has been RESOLVED, please check new section.
         

Section 3.7.1.5 Type of a Constructed Element
Technical
We believe that implicit validation on element construction (and
validation in general) adds considerable complexity to XQuery. However,
there is still value in having input data typed.
Therefore we propose to decouple validation from the schema import and
either remove validation from XQuery or make it a separate optional
validation feature (that then may also add the validation mode
preserve).
Thus, an implementation would only have to support the semantics of
validation mode = skip in the base conformance.

			
            
RESOLUTION. Closed. No action required. Overtaken by events.
		
         

Sections 3.7.1.3/3.7.3.3
Technical
"If the content sequence contains a document node, a type error is
raised.[err:XQ0023]": There are several use cases where people want to
put a wrapper around a document (see SQL-2003 SQL/XML and others) and
just want to write <a>{fn:doc(...)}</a>. We thus propose, that we allow
this scenario by automatically dropping the document node and inserting
copies of all the nodes under the document node into the new element.

            
Accepted and closed by adopting the following proposal:
            
Content of element constructors, computed element constructors, and
            
document node constructors no longer raise errors for document
            
nodes - instead, the contents of the document node are copied into
            
the content of the constructed element or document.
         

            
Accepted and closed by adopting the following proposal:
Content of element constructors, computed element constructors, and
document node constructors no longer raise errors for document
nodes - instead, the contents of the document node are copied into
the content of the constructed element or document.
         

Sections 3.7.1.3/3.7.3.1/3.7.3.3
Technical
"Copied element nodes are given the type annotation xs:anyType, and
copied attribute nodes are given the type annotation xs:anySimpleType.
": assuming no validation is done, the type annotations should be
xdt:untyped and xdt:untypedAtomic respectively.

            
Changes earlier resolution
         

            
MRys:  If no validation we get xdt:untyped and xdt:untypedAtomic.
AE:  In the latest wording this change may have been made.
Editors to check wording in 3.7.1.3, 3.7.3.1, 3.7.3.3 and fix.
Seems like it is already done.  Andrew confirmed.
         

Section 3.7.1.3 Content
Technical
"Predefined entity references and character references are expanded into
their referenced strings, as described in 3.1.1 Literals.
Each consecutive sequence of literal characters evaluates to a single
text node containing the characters. However, if the sequence consists
entirely of boundary whitespace as defined in 3.7.1.4 Whitespace in
Element Content and the Prolog does not specify xmlspace = preserve,
then no text node is generated.": As in comment MS-XQ-LC1-082, we should
not expand whitespace entities before we apply whitespace
handling/normalization rules. Also, some of the XML element content
whitespace normalization rules are missing.

Section 3.7.1.2 Namespace Declaration Attributes
Technical
Namespace declaration attributes should not affect the in-scope
namespace static context for expressions. We think that only the ones in
the prolog should affect the namespace prefixes inside expressions.
We find the following semantics to be confusing:
declare namespace b="uri1"; <a xmlns:b="uri2">{/b:c}</a> will look for
{uri2}:c and not {uri1:c}. "uri2" should only affect the construction
part.
The same should then also hold for the computed constructors.
Thus, we would like to have the following behaviour:
Namespace declaration in prolog: Provides static namespace prefix
bindings for both constructors and expressions
Namespace declaration on construction: Provides static namespace prefix
bindings for constructors only, not for embedded expressions.

            
AE:   Let's not make things more complex.
MRys:  Dana said notion of scope is underspecified.
PC:  This is technical change and there has been some pushback.
PC:  There is not support for the MS position but better text and
example would be good.
RESOLVED:  Add examples but no change to be behaviour.
         

Section 3.7.1.1 Attributes
Technical
Replace "The value of the size attribute is "7"" with "The value of the
size attribute is xdt:untypedAtomic("7")". In both examples, assuming no
validation.

            

            
>
            
> Status: See Don's request for review:
            
> https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Apr/0018.html
            
DC: Made fix to talk about string value and requests that this fix is
            
accepted instead of resolution of MS-XQ-LC1-083 in meeting 175.
            
MR: Can live with this.
            
Don's request is ACCEPTED.
         

            
>
> Status: See Don's request for review:
> https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Apr/0018.html
DC: Made fix to talk about string value and requests that this fix is
accepted instead of resolution of MS-XQ-LC1-083 in meeting 175.
MR: Can live with this.
Don's request is ACCEPTED.
         

            
MRys:  Editorial assuming no validation during attribute construction.
RESOLVED:  Fix as suggested.
         

Section 3.7.1.1 Attributes
Technical
"Predefined entity references and character references in the attribute
content are expanded into their referenced strings, as described in
3.1.1 Literals.
Each consecutive sequence of literal characters in the attribute content
is treated as a string containing those characters. Whitespace in
attribute content is normalized according to the rules for ""Attribute
Value Normalization"" in [XML 1.0] (each whitespace character is
replaced by a space (#x20) character.)": Often whitespace in attribute
values is entitized to avoid the attribute value normalization. By doing
expansion first, we loose this capability and lose the ability to
preserve certain whitespace characters. This should be fixed.

            
This has been already REJECTED and publicly announced in
            
https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0234.html
            
WG Resolution: Jonathan to update issues list
         

            
MRys: By expanding entities early we lose ability to maintain some
whitespace characters.
PC:  Need exact text.
MRys:  Follow XML 1.0 text or do whitespace normalization first and then
expand entity references.
AE:  In section 3.7.1.1 interchange rules 1 and 2.
RESOLVED:  Implement AE suggestion above.  Attn:  Don C.
         

Section 3.2.1.2 Node Tests
Editorial
Remove reference to namespace node (there is no way to perform a node
test on it in XQuery)

            
JR:  This has been done.
         

            
The offending text no longer occurs
         

XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003
3.1.6 XQuery Comments
"Comments may be used anywhere ignorable whitespace is allowed. See
A.2 Lexical structure for the exact lexical states where comments are
recognized."
In the following queries, a comment is placed where ignorable
whitespace would appear to be allowed, but where the A.2.2 machine
has no transition on "(:".  So which is correct? Does the comment
cause a syntax error or not?
    node( (:test:) )
    processing-instruction( xml-stylesheet (:test:) )
    element( person (:test:) )
    element( hospital / (:test:) staff / person )
    <shoe (:test:) size="7"/>
    <fact>I saw 8 cats.</fact (:test:) >
    9 cast (:test:) as hatsize
-Michael Dyck

Proposal accepted.

            
[[accepted]]
         

XQuery: specification unclear
Section: 3.7.1.2 paragraph two says:
"A namespace declaration attribute is used inside a direct element
constructor, and serves to add a namespace to the in-scope namespaces
for the constructed element, or to specify the default element/type
namespace within the scope of the constructed element."
What does it mean "within the scope of the constructed element"? Does
the scope refer to the
XML forest rooted at the given element constructor or the XQuery
expressions that are lexically placed
within the "{" and the "}" ? Or both ?
This a very important point and the notion of "scope" is too fuzzy.

            
Status: Related to several other comments on namespaces: FEB0210,
FEB0211, FEB0207 and Microsoft LC-128.
AE:  Section 3.7.1.2 explains this better now.
PC:  Thus, Dana's problem has been fixed by this new text.  No further
action required.
         

XQuery:  syntax simplification request
Why is the Expr optional on the production [105] ?
If the expression is not present the entire text constructor
returns the empty sequence, so why support this syntax ?

            
Adapt the proposal
         

            
Dana: why does the comp text constructor have an optional expr as
opposed to comment constructor etc. where expr is mandatory.
ADOPTED.
         

XQuery: incomplete specification
Section 3.7.1 and 3.7.3 discuss the base-uri property of the new nodes
but does not say what should happen when
the static context has no base uri defined.

            
Don showed that the question asked in this comment is addressed in the
XQuery spec, section 3.7.1.3, Content, rule 5.b, and section 3.7.3.1,
Computed Element Constructors, rule 4.b, answers this question.  The
comment was probably valid in the Last Call Working Draft, but it has
been resolved in the current Working Draft.
RESOLUTION: Comment qt-2004Feb0453-01/BEA_028 is resolved with no
changes to the document.
         

XQuery: (potentially) editorial
Section 3.1.5 (Function calls) when it describes the
function conversion rules, it says that in case of
a function invocation from a different module the
type test has to be true in both modules.
This  is surprising. Does this mean that we are allowed
to write in a library module:
define function f($x as ns:shoeSize?)
(: ns:shoeSize derives from xs:integer here :)
{()}
while the importing module contains:
declare external variable $y as ns:shoeSize?;
(: ns:shoeSize derives from String here :)
f($y)
and have the call f($y) succeed  if $y is bound to the
empty sequence ?
This is surprising. Did I misunderstand something?
Is this is not allowed, where is the text that forbids this case?(maybe)

            
See https://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jun/0147.html
Add the constraint:
    For every definition found in the in-scope schema definitions (ISSD)
    of a module resource, if it is found in another module resource
    used in the same query, then its definition must be the same as its
    definition in the other module resource.
Scribe note:
    The mail says "module" but the term was changed to
    "module resource" by another decision made at this meeting.
The Editor can reword this.
         

XQuery: incomplete specification, request for clarification
The XQuery specification does not seem to require that all the in-scope
schema definitions that are referred in a variable type declaration
or a function signature of an imported library module have to also
be in scope in the importing module.
Moreover, the XQuery specification does seem to impose any consistency
constraints
between in scope schema definitions in the static context of a main
module
that imports a library module and the in scope schema definitions with
the
same names in the library module.
Both should be required as consistency constraints, and stated in
section 2.2.5.

            
subsumed by qt-2004Feb0448-01
partly answered by an existing constraint, and also the new constraint
added for qt-2004Feb0448-01.
         

I don't see the need for this 'local' namespace. Why was it introduced?
Regards,    Martin.

            
It's to permit users wanting to define functions not to need to declare
a namespace.
ACTION A-CHINOOK-15: Jonathan Robie to reply.
         

Is using a document node constructor (3.7.3.3) the only way to
construct document? Or is it possible to automatically have an
element node convert into a document, or an external entity, if
it is at the top? The later is desirable, and XQuery should
clarify this. Also, why are the rules for XML documents not
enforced? What other purpose than this would a document constructor
have?
Regards,    Martin.

            
Agreed: A document node constructor is the only way to create a
document.
Agreed: Within XQuery, document nodes are not created
implicitly. Serialization does implicitly convert to a document.
Agreed: Our data model needs the flexibility to be able to create
documents with multiple root nodes.
ACTION A-173-07: Jonathan to respond to Martin.
Decided:
The issue is resolved.
         

Rule [17], EscapeQuot, should say /* ws: significant */, I guess.
Regards,   Martin.

Proposal accepted.

            
[[accepted]]
         

[1] As shown in the examples in 2.6.6 and 2.6.7, XQuery code can
exist in documents/files of its own. It is therefore crucial
that the XQuery version declaration (4.1) takes an additional
parameter, 'encoding', in the same way as an XML declaration
has an 'encoding' pseudo-attribute.
For its definition, most details can be taken from XML. However,
it would be great if the whitespace in the version declaration
were limited to exactly one space each, because the encoding
parameter has to be looked at before a full parser is available.

            
KK thinks we discussed this in Redmond and decided to do it (that is,
to add an encoding declaration to the version declaration).
See qt-2004Feb0415-16.
MH: that's different, that's about output encoding.
MR: In many cases the encoding will be defined by the processing environment.
AE: it was discussed as part of the discussion on MIME type. Reads the
discussion: we believe we have adopted this.
DC: yes we have, it's in the grammar, I think it's misguided, but we've done it.
RESOLVED: we have already made the change requested, as a result of a
different comment. See agenda item Q9A in the Redmond meeting. JM to send
the response to Martin.
         

[2] In connection with [1], XQuery also needs a mime type. Most probably
application/xquery.

            
We now have an appendix about application/xquery.
RESOLVED: qt-2004Feb0415-02 closed
ACTION A-216-09 Liam will reply to qt-2004Feb0415-02
[done]
         

[3] 3.1.1 Literals, entity/character references: After careful examination,
this works out. But it would be good to have a section explaining
how character escaping works in XQuery overall, including differences
and similarities to XML and XPath.

            
This comment asks for an overview, the comment is therefore editorial.
DC: we enumerate the different cases and give the syntax, it's hard to see
what else we should do.
RESOLVED: we feel the spec is unambiguous, we don't feel a need to add
further tutorial information at this stage. AE will respond to Martin.
Issue closed with no action.
         

[4] The special conventions for escaping quotes (production [17]),
apostrophes ([25]), and curly braces (should probably also be
a production of its own) may not be necessary. Character
references should be used, for convenience, named character
references for { and } could be defined.

            
R: Martin isn't claiming there's anything broken by the current mechanism,
but that we could just use character references
AE: we did have a reason for doing what we did: MKay had argued that XPath
expressions inside XSLT are going to be processed first in XML and then by
the XPath processor
JR: I can't see making a change like this at this point
JM: I'm hearing consensus to respond saying we did this for good reason and
see no good reason to change.
         

[5] 3.7.1 and other places: how can a base URI be preserved? How
can it be set in the output? Both have to be possible, otherwise,
XML Base is not really useful. Also, there should be a way to
take an IRI and make it absolute, using the relevant XML Base.

            
The text of the comment (in boldface), along with proposed responses,
is:
[5] 3.7.1 and other places: how can a base URI be preserved?
The answer is to find it using an Xpath expression such as
"(ancestor-or-self::*/@xml:base)[last()]" and using the answer in the
constructed output.
How can it be set in the output?
It can be set by constructing the attribute in the desired element or
elements.
Both have to be possible, otherwise, XML Base is not really useful.
(No response required)
Also, there should be a way to take an IRI and make it absolute, using
the relevant XML Base.
Because the IRI Internet-Draft is not yet final, the meeting determined
that it would be inappropriate for XQuery to make explicit reference
to it. However, because IRIs are being defined to behave "the same
as" URIs, we believe that XQuery's dependency on XML Schema, and XML
Schema's Part 2, section 3.2.17, permits the fn:resolve-URI() in F&O
section 8.1 to resolve this concern.
RESOLUTION: Comment qt-2004Feb0415-05 is resolved with no changes to the
document.
ACTION A199-03: Paul will communicate the preceding information about
handling base URI preservation and construction, and handling of IRIs,
to the I18n WG.
         

            
The text of the comment (in boldface), along with proposed responses,
is:
[5] 3.7.1 and other places: how can a base URI be preserved?
The answer is to find it using an Xpath expression such as
"(ancestor-or-self::*/@xml:base)[last()]" and using the answer in the
constructed output.
How can it be set in the output?
It can be set by constructing the attribute in the desired element or
elements.
Both have to be possible, otherwise, XML Base is not really useful.
(No response required)
Also, there should be a way to take an IRI and make it absolute, using
the relevant XML Base.
Because the IRI Internet-Draft is not yet final, the meeting determined
that it would be inappropriate for XQuery to make explicit reference
to it. However, because IRIs are being defined to behave "the same
as" URIs, we believe that XQuery's dependency on XML Schema, and XML
Schema's Part 2, section 3.2.17, permits the fn:resolve-URI() in F&O
section 8.1 to resolve this concern.
RESOLUTION: Comment qt-2004Feb0415-05 is resolved with no changes to the
document.
ACTION A199-03: Paul will communicate the preceding information about
handling base URI preservation and construction, and handling of IRIs,
to the I18n WG.
         

[6] How can xml:lang be extracted from data and preserved with a query?
How can this be done without littering all elements with unnecessary
xml:lang attributes? Other inherited attributes will have the same
problem; some better support for inherited attributes seems necessary.

			
            
> qt-2004Feb0415-06 [XQuery] I18N last call comments
This (qt-2004Feb0415-06) was RESOLVED at the redmond F2F and meeting 199.
		
         

[7] 3.7.1.1 Attributes: processing is described differently from what
happens in the case of XML. Whitespace normalization is done before
resolution of character references in XML; character references
can be used to protect various whitespace characters from attribute
normalization. This should be alligned with XML. (also, it should
be mentioned how this normalization is (or is not) dependent on
the type of the attribute)

            
DC: I believe we have already processed this issue, or something like
it. The current rules for whitespace in attribute constructors reflect the
intent of what is requested.
JR: appears to be a duplicate of Feb0490-01 (MRys comment).
RESOLVED. Duplicate of Feb0490-01, which we accepted. Jonathan will
respond to this effect.
         

[8] 3.7.1.3 Content (and other places): serializing atomic values
by inserting spaces may not be appropriate for Chinese, Japanese,
Thai,..., i.e. languages that don't use spaces between words.
This has to be checked very carefully.

            
JR had some email interchange with Martin Duerst, about spaces separating
tokens in programming languages not being the same as in natural languages.
The reason the white space is there for roundtripping sequences.
         

[9] There should be more non-US examples. For example, it is very
     difficult for somebody not from the US to understand why there
     are no Deep Sea Fishermen in Nebraska.

            
DECISION: To not ask the editors to make changes solely for the purposes of
this comment, but to do so on an opportunistic basis only.
We've asked the editors to consider rephrasing examples in non-US
terms when they have the opportunity, but there are no plans to make
revisions unless we learn of examples that are particularly unclear.
         

[10] 3.7.2: Not requiring CDATA constructs to be serialized as CDATA
sections is a good idea, because it helps dispell the idea
that CDATA sections are semantically significant.

            
overtaken by events, we no longer have CDATA sections in the data model.
         

[11] 3.7.3.1, example using 'lang' attribute: Please replace this
attribute with xml:lang, and its values with 'de' and 'it'.

            
JR: he's right in both cases, this example should be changed
DECISION: To adopt the change proposed in the comment.
ACTION A-216-03 Don to make the change and reply to qt-2004Feb0415-11
RESOLVED: qt-2004Feb0415-11 accepted
         

[12] 3.7.3.4: Why is there a need for a 'text' node constructor.
What's the difference between this and a string (there should
be none, or as few as possible).

            
> h) qt-2004Feb0415-12 [XQuery] I18N last call comments
JR: one thing that's very hard to do is to create an untyped string -
you have to know the name xdt:untypeAtomic, but this turns out to be
common.
We have constructors for all of our node types.
DECISION: That no change is required to the documents in response to this
comment.
RESOLVED: qt-2004Feb0415-12 closed with no change
ACTION A-216-04 JR to respond to qt-2004Feb0415-12
         

[13] For collations, namespaces, schemas, and so on, a "StringLiteral"
rule is used, and the definitions say 'URI'. This has to be changed
to IRI, and preferably a separate non-terminal should be used
to make this clear. There should also be a clear indication
how XML Base affects these.

			
            
[PC] Latest message is under:
https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Dec/0107.html
This proposes a new grammar for URILiteral.
[MichaelK] Is that needed in XPath?
[ScottB] I believe this is used in one place.
*** Proposal to add a URILiteral in the grammar is adopted.
https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Dec/0107.html
*** This resolves Issue qt-2004Feb0415-13. LIAM to respond to I18N working group.
		
         

[14] 3.8.3, last example: Instead of 'collation "eng-us"', something
that looks more like an URI should be used.

            
DECISION: To make a change based on the comment.
ACTION A-216-06 Don will fix, using
https://www.example.org/collations/fr-ca, and respond to the comment
RESOLVED: qt-2004Feb0415-14 accepted
         

[15] 3.12.2 Typeswitch: There should be an example that shows how to
deal with strings, complex types without any actual markup contained,
and complex types with markup (e.g. <ruby> or similar).

            
Don: we have one example in typeswitch, using the type of an address
element.
DECISION: No support for making a change -- the language book is not a
tutorial.
RESOLVED qt-2004Feb0415-15 rejected
         

[16] section 4: As shown in the examples in 2.6.6 and 2.6.7, XQuery can
directly produce XML output. For such cases, it is very important
to make sure that the relevant parameters for serialization
(in particular encoding, but also normalization) can be defined
in an XQuery prolog. There should also be clear requirements on
minimal support for encodings (e.g. UTF-8 and UTF-16) to guarantee
interoperability.

            
we won't put this in the prolog; in general, we won't put serialization
para's in the prolog (leave it implementation-defined/API-defined)
ACTION A-208-03: MRys will write a proposed reply for qt-2004Feb0415-16,
and then SteveB will review it and send it to Martin
         

[17] Note at the end of 4.6: re. DTD treatment, this should very clearly
say what happens (or doesn't happen) with entities, or point to the
place where this is defined (data model)?

			
            
The comment is:
    [17] Note at the end of 4.6: re. DTD treatment, this should very
    clearly say what happens (or doesn't happen) with entities, or point
    to the place where this is defined (data model)?
Andrew: this was at the end of the schema import section; the note at
the end of the section talked about DTD-validated documents, suggesting
converting DTDs to W3C XML Schemas.  In our latest document that note
no longer exists.
The XQuery language document no longer mentions DTD.
The data model 3.2 says,
"All general and external parsed entities must be fully expanded" which
answers this comment.
RESOLVED: qt-2004Feb0415-17 closed
Liam to reply (done).
		
         

[18] it would be very good if it were possible to declare default
collations for part of an XQuery.

            
MaryH: I don't see any good way to do this.
AE: we've chosen to provide prologue directives and not to provide
expresion-by-expression directives
Liam: this wouldhave implications on separate compilation of modules,
if you could say, with default collation foo cal function module:x
Maybe in a later version.
DECISION: No changes to the language (at least in V1.0) in response to this
comment
RESOLVED: qt-2004Feb0415-18 rejected
         

[19] There should be a way to character normalize nodes (not only strings).
This could easily be achieved by overloading fn:normalize-unicode.
This will help in cases where otherwise fn:normalize-unicode would
have to be used all over the place.

            
Serialization parameters are more appropriate for this.
JR will respond.
         

[20] The XML version for output seems to be fixed to 1.0. There needs
to be a way to output XML 1.1.

            
(how to output XML 1.1?)
JR: the supported version of XML is now implementation defined,
(decided on August 11th telecon)
JR will respond to Martin.
         

It is not too difficult to predict that typing will be a headache
for many people for XQuery and XSLT2. Please do anything and everything
that you can to reduce the problems.
The different concepts around types, the different types, the different
rules for conversion,... will make typing very difficult to use. It would
be very good to have some section (maybe an appendix) summarizing all
the rules, and giving people a chance to get an overall grasp. Giving
parallels e.g. to well-known programming languages (if and where they
exist) may also help.
Another issue is that it is not completely predictable, and not
completely interoperable, which XML Schemas will be taken into
account and which not. XQuery Schema Import does a lot to make this
more predictable, but this should be completely predictable.
'augmentable by implementation' does not lead to interoperability.
A typical example of this is the "implementation-dependent mechanism
for determining whether an unknown type is compatible..." in
2.4.4 of XPath.
Regards,    Martin.

            
Yes, typing is a headache. We are doing what we can to make it easier,
but it is hard to understand, and involves difficult concepts. We
expect books and articles to clarify this, our spec needs to be clear,
but it will not be a tutorial.
Implicit schema import is needed in some environments that need type
safety but do not support explicit schema import. It is always
possible to explicitly import schemas for interoperability.
Implementations that can access dynamic type information should be
allowed to use this information even though purely static
implementations can not. This is why we have chosen to allow an
implementation-defined mechanism that can utilize type hierarchies not
available in the static context.
         

For many applications, namespace node preservation is overweight. For
others, it is needed. The current definition of XQuery can easily
result in large numbers of superfluous namespace nodes, especially
when querying documents that use several namespaces.
Consider the following data, taken from the DOM Issues List:
<issues xmlns:xlink="https://www.w3.org/1999/xlink"
  xmlns:xi="https://www.w3.org/2001/XInclude"
  xmlns="https://www.w3.org/2003/10/issues"
  xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance">
  <header>
    <title>DOM Level 3 Core Issues List</title>
    <!-- SNIP -->
  </header>
</issues>
Now consider the following query, applied to this data:
<out>
{
 doc("dom-issues.xml")/issues/header/title
}
</out>
Here is the result, according to our current spec:
<out>
 <title xmlns:xlink="https://www.w3.org/1999/xlink"
  xmlns:xi="https://www.w3.org/2001/XInclude"
  xmlns="https://www.w3.org/2003/10/issues"
  xmlns:xsi="https://www.w3.org/2001/XMLSchema-instance"
  >DOM Level 3 Core Issues List</title>
</out>
Although none of these namespaces are actually used in the title
element that was retrieved, our current specification require that all
namespaces in scope in the original document must be in scope for the
copied element in the constructed element. Now suppose that we create
several namespace-decorated documents like this one, and perform an
XQuery that copies from each of these to create a new document with
even more namespaces...
Naturally, we do need to ensure that namespaces are preserved if they
are used in element names, attribute names, or QNames. Consider the
following query:
doc("dom-issues.xml")/issues//originator
The result must preserve the above-mentioned namespaces to allow
correct interpretation:
<originator xlink:type='simple'
xmlns:xlink="https://www.w3.org/1999/xlink"
xlink:id="2004Feb/mailto:caillon@netscape.com">Christopher Aillon</originator>
There are also XML vocabularies, such as XML Schema or XSLT, that use
QNames in content, and for these, all QNames really must be
preserved.
I think we should provide two modes of operation:
1. Namespace preserving copy keeps all namespace nodes
2. Normal copy keeps only namespace nodes used in element names,
   attribute names, or instances of xs:QName.
One possibility would be to declare this at a global level:
  declare namespace-preserving = "true";
Another possibility would be to declare namespace preservation for
specific namespaces:
  declare namespace-preserving = "https://www.w3.org/2001/XMLSchema",
     "https://www.w3.org/1999/XSL/Transform";
Either of these would reduce the overhead associated with copying
elements significantly in some implementation environments.
Jonathan

			
            
RESOLUTION: This resolves qt-2004Feb0285-01 [XQuery] 3.7.4 Namespace
nodes on constructed elements
The comment came from Jonathan, so no need to respond.
		
         

(IBM-XQ-015) XQuery currently defines three validation modes: strict, lax,
and skip, based on the three validation modes of XML Schema. In skip mode,
no validation is applied to a newly-constructed element. Instead, the new
element node (and each of its descendant elements) is given the annotation
xdt:untyped, and its attributes (and the attributes of its descendants)
are given the annotation xdt:untypedAtomic. If the content of the new
element is copied from existing nodes, the types of these existing nodes
are lost.
An XQuery implementation that does not support Schema Import will probably
run in skip-validation mode, since validation is meaningful only if a
schema is present. Nevertheless, such an implementation may wish to
preserve the type annotations on nodes in input documents, since these
type annotations may affect the processing of a query (for example, 17 > 5
is true for the xs:decimal type but not for the xdt:untypedAtomic type).
The loss of type information during skip validation causes a serious
problem for applications that need to "wrap" an element in a higher-level
"envelope" element. The wrapping is done by referencing the "content"
element inside a constructor for the "envelope" element, causing the
content element to be copied and validated. It is quite possible that the
"content" element may not be defined in the in-scope element declarations.
This may happen if the current application is a generic message-routing
application that does not find it practical to import the schemas for all
possible contents. It will also happen in systems that do not implement
the Schema Import feature. In these cases, skip-validation causes the loss
of the type information on the "content" element.
Here are some examples of this problem (assuming skip validation in each
case):
(a) Copy a set of "customer" elements into newly-constructed
"rated-customer" elements, pairing each customer with a rating. Now order
all the rated-customers by balance-due. Balance-due was originally
decimal, but now its type has been lost and 5 is sorted as greater than
17.
(b) Write an application to extract data from an XML document and wrap it
in <row> and <col> tags for interfacing to a relational database. By
wrapping the data in <row> and <col> tags, its original types are
destroyed and all the data appears to be text. Again, data that was
originally decimal will be sorted incorrectly.
(c) If a query-rewrite pushes a predicate inside a constructor, the effect
of the predicate is changed because the expression inside the constructor
is typed but outside the constructor it is not. This limits the ability of
the system to do query optimization and to merge queries with view
definitions.
The solution to these problems is to introduce a new validation mode
called "skip preserve", or simply "preserve". In this mode, no validation
is attempted, and the type annotation of the subject element remains
unchanged rather than being set to xdt:untyped. Adding this validation
mode would not affect the definitions of the existing three modes.
The following changes would be made to the XQuery specification by this
proposal:
(a) In Section 2.1.1, Static Context: In definition of Validation Mode,
add "preserve"  or "skip preserve" to the list of modes.
(b) In the grammar production for ValidationMode, add the a keyword for
the new option.
(c) In Section 3.7.1.3, Direct Element Constructors--Content: Rule (1d)
should be changed as follows: "If the validation mode is "preserve",
copied element and attribute nodes retain their original type annotations;
otherwise, copied element nodes are given the type annotation xdt:untyped,
and copied attribute nodes are given the type annotation
xdt:untypedAtomic."
(d) In Section 3.7.1.5, Direct Element Constructors--Type of a Constructed
Element: Add the following initial sentence:
"A direct element constructor assigns the initial type annotation
xdt:untyped to the newly constructed element node. It then validates the
new node, using the schema validation process defined in XML Schema."
Also in Section 3.7.1.5, change the first bullet as follows: "If
validation mode = skip or preserve, no validation is attempted. The
constructed element retains its type annotation of xdt:untyped, and its
attributes and descendants retain the type annotations assigned to them
during construction."
(e) In Section 3.14, Validate Expressions: Add the following bullet to the
three bullets that define strict, lax, and skip validation:
"preserve indicates that no validation is to be attempted, but that
element nodes and attribute nodes are to retain their original type
annotations."
(f) In Section 4.6, Validation Declaration: Add "preserve" to the list of
validation modes.
Note that these changes will align XQuery with XSLT 2.0, which has already
introduced the concept validation="preserve" as documented in
https://www.w3.org/TR/xslt20/#validating-constructed-nodes. The XSLT 2.0
definition of validation="preserve" is consistent with the definition
above, and these definitions should be kept consistent.
--Don Chamberlin

(IBM-XQ-011) Section 3.14 (Validate Expression) states that validating a
node destroys its identity. I believe that this issue needs more thought.
The reason for giving a new identity to a validated node is that some of
its contents may change (for example, default attributes may appear). But
consider the following:
(a) The validated note has the same parent as the original node, right?
Doesn't this mean that the content of the parent node has changed? If the
parent node can retain its identity, why can't the validated node retain
its identity?
(b) The working group expects to define update operators that can change
the state of a node while preserving its identity. But presumably the
updated node will need to be revalidated for type-safety. If validation
destroys node identity, how can updates preserve node identity? This seems
to violate our XQuery Requirement (3.2.5) that XQuery must be defined in a
way that does not preclude the later introduction of update operators.
(c) Requiring validation to generate new node identities also raises
questions about Requirement (3.4.13) that queries must be able to preserve
the identity of items in the Data Model.
(d) Requiring validation to generate new node identities also may place an
unnecessary burden on implementations that perform incremental validation
on the data model rather than serializing it and revalidating the whole
tree from scratch.
(e) Suppose $n is bound to an element node.
Is "$n is validate{$n}" true?
Is "$n/.. is validate{$n}/.." true?
If the answers are not the same, why not?
--Don Chamberlin

            
Dana: This would add side effects to the language. XQuery would no
longer be a functional language. None of the traditional optimizations
would hold.
Answers to Don's questions:
(a) The validated note has the same parent as the original node,
right?  Doesn't this mean that the content of the parent node has
changed? If the parent node can retain its identity, why can't the
validated node retain its identity?
Agreed: If a node is validated, it no longer has a parent.
(b) The working group expects to define update operators that can
change the state of a node while preserving its identity. But
presumably the updated node will need to be revalidated for
type-safety. If validation destroys node identity, how can updates
preserve node identity? This seems to violate our XQuery Requirement
(3.2.5) that XQuery must be defined in a way that does not preclude
the later introduction of update operators.
Agreed: In-place validation, which is needed for updates, is different
from the validation XQuery currently does.
(c) Requiring validation to generate new node identities also raises
questions about Requirement (3.4.13) that queries must be able to
preserve the identity of items in the Data Model.
Agreed: There is no requirement that every operation in XQuery
preserve identity, merely that it is possible for a query to return
nodes, preserving identity.
(d) Requiring validation to generate new node identities also may
place an unnecessary burden on implementations that perform
incremental validation on the data model rather than serializing it
and revalidating the whole tree from scratch.
Agreed: There are ways to do this under the covers.
(e) Suppose $n is bound to an element node.
Is "$n is validate{$n}" true?
Is "$n/.. is validate{$n}/.." true?
If the answers are not the same, why not?
Agreed: We can live with the status quo on this.
Some disagreement with what that answer is. Jonathan believes the
answers are "false" and "()", respectively.
         

(IBM-XQ-009) Section 3.7.1.5 (Type of a Constructed Element) uses the
following example:
<a xsi:type="xs:integer">47</a>
But Section 3.7.4 (Namespace Nodes on Constructed Elements) says that a
similar example is not valid:
<p xsi:type="xs:integer">3</p>
This illustrates an error that many users will make. The namespace "xs"
that contains all the built-in schema types is not in scope for a
constructed element unless it is explicitly declared.
We need to correct the inconsistency between the two sections noted above.
This can be done in either of the following ways:
(a) We can make a rule that the "xs" namespace, like the "xml" namespace,
is automatically in scope for all constructed elements. I recommend this
approach, because I believe that the justification for "xs" is at least as
good as for "xml". This will remove a common source of errors and
frustration.
(b) We can replace the example in Section 3.7.1.5 with the following ugly
but correct example:
<a xmlns:xs="https://www.w3.org/2001/XMLSchema" xsi:type="xs:integer>47</a>
(along with an embarrassing explanation about why it this is necessary and
an apology to users).
--Don Chamberlin

            
Rationale: you can declare the prefix/URI binding in the instance
         

            
Rationale: you can declare the prefix/URI binding in the instance
         

            
Option B is preferred.
Don will respond to himself.
         

(IBM-XQ-008) Section 3.5.1 (Value Comparisons): Value comparisons were
intended to be transitive, but there is a case in which they are not.
Suppose that A and C are values of type int (32 bits of precision) that
differ in their low-order bit. Suppose that B is the value of type float
(24 bits of precision) into which both A and C are converted by the rules
for casting int to float. Then "A eq B" is true and "B eq C" is true, but
"A eq C" is false.
The language documents should state that the value comparison operators
are transitive except in cases where precision is lost in type-casting of
operands.
--Don Chamberlin

            
Don: problem is. value comparisons are still not transitive due
to precision problems during conversion.
Michael R. has a counter proposal (to get rid of transitivity
altogether).
Don elaborates on the actual problem.
ADOPTED.
Don will respond by elaborating on the corner case.
         

(IBM-XQ-006) Section 3.1.5 (Function Calls): This section states that a
function does not inherit a focus (in other words, the context item,
context position, and context length are initially undefined inside the
body of a function). The section should also say something about the other
parts of the static and dynamic context. Are these inherited from the
module in which the function is defined (as opposed to the calling
module)? Are there any consistency rules between the contexts of the
defining and calling modules? For example, can they have different default
collations or default namespaces? Must their current date/time and
implicit timezones be consistent? Can a variable that is assigned a value
in the calling module be seen inside a function body? Can a document that
is in the available documents of the calling module be seen inside a
function body?
--Don Chamberlin

            
"My recommendation is that "global" should always mean "global to a
 module". This permits separate compilation of modules."
[discussion of physical vs logical modules]
[discussion of interdependency of compilation]
The table in C.2 (of the shared XPath/XQ editors' draft) is affected,
Dynamic Context Components, "must be initialized by implementation"
would be changed to add "consistently across all modules",
and "global" Scope changed to "module".
proposal is adopted as amended as of the Jun 0109 cited above
available documents and collections moved into category 3
[[
Discussion from meeting 168 on 2004-02-18:
Don: where does the context of a function call come from?
From the declaration context or from the calling context?
Dana: mentions that BA also has sent a couple of comments
on this issue.
Michael R.: suggest to remove this(?) (modules?) from the required
features.
Don doesnt think that modules aren't so badly broken that they
need to be given up. Suggests to put this issue on the F2F agenda.
]]
         

(IBM-XQ-005) Section 2.6.3 (Full Axis Feature): The phrase "raises a
static error" should be changed to "may raise a static error", to denote
that an implementation may selectively implement some of the reverse axes
of XPath even though it does not claim to support the Full Axis Feature.
--Don Chamberlin

            
Don: wishes to have a continuum between only downward axes and full
axes.
This could be resolved by changing a MAY to a MUST.
MRys: agrees, and wants to generalize it to all optional features.
Peter F is in favor, if unsupported axes still raise a static error.
Massimo
also wants to make sure that too.
ADOPTED.
Don C. will respond accordingly.
         

The XQuery document notes that the following element constructor fails
with a validation error:
    <p xsi:type="xs:integer">3</p>
This is an unpleasant surprise for users - and there is a simple
solution. The specification already requires implementations to create
a namespace node for each namespace used in an element or attribute
name:
   A namespace node is created corresponding to each namespace
   declared in a namespace declaration attribute of this (or any
   enclosing) direct element constructor, each computed namespace
   within this (or any enclosing) computed element constructor, and
   the xml namespace. These namespace nodes use the same prefixes and
   URIs as the namespace declarations from which they are derived (the
   prefix becomes the name of the namespace node, and the URI becomes
   the string value of the namespace node).
   A namespace node is created corresponding to any namespace used in
   the name of the element or in the names of its attributes. However,
   a namespace node need not be created if there is already a
   namespace node for a given namespace URI on a given element. The
   string value of the created namespace node is the namespace URI of
   the element or attribute name. The name of the namespace node
   (which represents the namespace prefix) is  implementation-dependent;
   it must not conflict with the name of any  other namespace node
   for the same element.
A similar rule should be added to create a namespace node
for each namespace used in an instance of the xs:QName type.
Jonathan

            
Rationale: you can declare the prefix/URI binding in the instance
         

            
Rationale: you can declare the prefix/URI binding in the instance
         

XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003
A.2.1 White Space Rules
You should probably define what you mean by "white space", since it
isn't defined in the EBNF.
"White space is tolerated before the first token and after the last
token."
    The word "tolerated" is odd here. Perhaps change to "allowed".
    At the end of the sentence, append "of a module".
"White space is optional between terminals, except a few cases where
white space is needed"
    You must specify which cases.
    Also, after "except", I think you need to insert "for" or "in".
"to disambiguate the token."
    This is a misuse of the term "disambiguate" in its technical sense.
    Ambiguity (or the lack thereof) is a property of a grammar.
    Change "token" to "grammar".
------------------------------------
"Special white space notation is specified with the EBNF productions,
when it is different from the default rules,"
    It's not clear what the default rules are. I think they started at
    "White space is optional". I believe it would increase clarity if
    you created a "Whitespace: default" subsection, and put the
    "default rules" under it.
"'ws: significant' means that white space is significant as value
content."
    As I understand it, this has nothing to do with specifying where
    white space is allowed: you could replace every "ws: significant"
    with "ws: explicit" and the set of legal queries would be the same.
    Specifying what is "significant as value content" is out of place
    here. (For instance, whether boundary whitespace is significant is
    controlled by the xmlspace declaration.)
I don't think the white space rules are precise enough to tell me
whether white space is allowed/disallowed/required between two terminals
that are derived from productions with different ws annotations (e.g.,
one "ws: explicit", one default).
------------------------------------
"For XQuery,"
    Delete.
"White space is not freely allowed in the non-computed Constructor
productions, but is specified explicitly in the grammar ..."
    Change "non-computed" to "direct".
    This sentence is unnecessary, since the corresponding productions
    have the appropriate "ws" annotations. (It's a holdover from the
    days before "ws" annotations.)
"The lexical states where white space must have explicit specification
are as follows: ..."
    If you're talking about the states that have an explicit transition
    on white space (or on a symbol that can derive a whitespace
    character), then:
    --- The use of "must" is inappropriate, since it's not the
        implementor's job to ensure that you specify these transitions.
    --- Why is PROCESSING_INSTRUCTION included in the list?
    --- Why is EXPR_COMMENT excluded?
    If you're talking about something else, does it affect the
    interpretation of A.2.2?
    In either case, the sentence should probably be moved to A.2.2, or
    else deleted.
------------------------------------
"For other usage of white space,"
    Other than what? Aren't all uses of white space covered by either
    "the default rules", "ws: explicit", or "ws: significant"?
"one or more white space characters are required to separate 'words'."
    What constitute "words"?
"Zero or more white space characters may optionally be used"
    Given "zero or more", "optionally" is redundant.
"around punctuation and non-word symbols."
    What constitues "punctuation"? or "non-word symbols"?
In sum, this paragraph is vague and unhelpful, and could probably be
construed to conflict with other requirements. Either delete it or make
it more precise and better related to the rest of the section.
------------------------------------
Presumably, white space is disallowed anywhere that this section doesn't
say it *is* allowed. (If that's the case, it would probably be good to
mention it.) In particular, it would appear that white space is
disallowed *within* terminals (or at least, those that are derived from
a production without a "ws" annotation). Normally, this is sensible, but
it has some odd (and probably unintended) consequences:
    --- Because SchemaGlobalTypeName is a terminal, constructs such as
            type( schedule )
        or
            type (schedule)
        are illegal.
    --- Because Pragma and MUExtension are terminals, the spaces that
        appear around "pragma" and "extension" in the spec's examples
        of these constructs are illegal.
    --- All four "ws: explicit" annotations in the "Named Terminals"
        section are redundant.
There are various ways to deal with these cases, but I think the root
of the problem is defining the allowed locations for white space in
terms of "terminals" (or "tokens"), which I think is unnecessary.
------------------------------------------------------------------------
The spec is inconsistent: "white space" or "whitespace"?
------------------------------------------------------------------------
Also, the following sections:
    2.6.5 Pragmas
    2.6.6 Must-Understand Extensions
    3.1.6 XQuery Comments
    A.1.1 Grammar Notes (grammar-note: comments)
    E Glossary (must understand)
all refer to "ignorable whitespace", but this term is never defined.
-Michael Dyck

Proposal accepted.

            
[[accepted]]
         

Does the default element/type namespace apply to instances of the XML
Schema QName type in elements or attributes? I do not believe our
documents currently answer this question. We believe a clear statement
needs to be made one way or the other.
Jonathan

            
JR: If I'm copying an attribute of type QName in preserve move into an
element, ,..
Don: data of type qname within an element or att is governed by the
in-scope namespaces of that element.
    declare default namespace "urixxx"
    <a xsi:type="xs:QName">foo</a>
The default namespace has no impact on "foo"
JR: clarification is no longer needed.
         

Does the default element/type namespace apply to instances
of the XML Schema QName type in elements or attributes? I do not
believe our documents currently answer this question. We believe a
clear statement needs to be made one way or the other.
Jonathan