Last Call Comments for xquery.

Last Call Comments

Editor:
Jonathan Robie
Liam Quin

Last call issues list for xquery (up to message 2004Mar/0246).

This document identifies the status of Last Call issues on XQuery 1.0: An XML Query Language as of April 4, 2005.

The XQuery 1.0 Language has been defined jointly by the XML Query Working Group and the XSL Working Group (both part of the XML Activity).

The April 4, 2005 working draft includes a number of changes made in response to comments both received during the Last Call period that ended on Feb. 15, 2004. The working group is continuing to process these comments, and additional changes are expected.

Public comments on this document and its open issues are invited. Comments should be sent to the W3C mailing list public-qt-comments@w3.org. (archived at http://lists.w3.org/Archives/Public/public-qt-comments/) with “[XQuery]” at the beginning of the subject field.

Most issues are classified as either “substantive”, meaning the editor believes technical changes to the document are required to address them, or “editorial”, meaning that the issue is one of specification clarity not technical correctness.

An issue transitions through several states. Issues tracking begins when an issue is “raised”. After discussion, the Working Group may have “decided” how to resolve the issue. This decision is “announced” and hopefully “acknowledged” by external commenters. For the most part, once an issue is decided, it is considered closed.

There are 415 issue(s).

0 raised (0 substantive), 0 proposed, 415 decided, 0 announced and 0 acknowledged.

Id Title Type State Doc. Resp.
+qt-2004Jan0029-01 [XQuery] MS-XQ-LC1-053 typo decided XQ Jonathan Robie
+qt-2004Jan0152-01 [XQuery] MS-XQ-LC1-007 typo decided XQ Jonathan Robie
+qt-2004Mar0085-01 Ref XSCH-QL-018: Example of pblm with serialization-based validation substantive decided XQ Jonathan Robie
+qt-2004Mar0059-01 [XQuery] LQ-XQ-02 - Calling a Web Serice substantive decided XQ Jonathan Robie
+qt-2004Mar0016-01 Further to Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-019 substantive decided XQ Jonathan Robie
+qt-2004Mar0013-01 defer cyclic module import until XQuery 1.0 substantive decided XQ Jonathan Robie
+qt-2004Feb1207-01 [XQuery] XQ-IBM-026 Function conversion rules substantive decided XQ Jonathan Robie
+qt-2004Feb1161-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-018 substantive decided XQ Jonathan Robie
+qt-2004Feb1159-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-016 substantive decided XQ Jonathan Robie
+qt-2004Feb1158-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-015 substantive decided XQ Jonathan Robie
+qt-2004Feb1157-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-014 substantive decided XQ Jonathan Robie
+qt-2004Feb1145-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-002 substantive decided XQ Scott Boag
+qt-2004Feb1141-01 NM-XQ-5: Range expressions and empty sequences substantive decided XQ Jonathan Robie
+qt-2004Feb1140-01 NM-XP-4: ElementTest and control of substitution substantive decided XQ Jonathan Robie
+qt-2004Feb1124-01 ORA-XQ-409-B: Introduce identity-less operations as a feature substantive decided XQ Jonathan Robie
+qt-2004Feb1110-01 ORA-XQ-411-C: base uri and xml:base interaction needs to be clarified. substantive decided XQ Jonathan Robie
+qt-2004Feb1108-01 ORA-XQ-408-B: formalize notion of tuples substantive decided XQ Jonathan Robie
+qt-2004Feb1107-01 ORA-XQ-406-B: Static type for the context item must be specified in the static context substantive decided XQ Jonathan Robie
+qt-2004Feb1106-01 ORA-XQ-407-B: distinct values of multiple sequences should be possible substantive decided XQ Jonathan Robie
+qt-2004Feb1092-01 [XQuery] questions about xquery/xpath core grammar substantive decided XQ Scott Boag
+qt-2004Feb1090-01 lazy or eager variable initialization? substantive decided XQ Jonathan Robie
+qt-2004Feb1005-01 [XQuery] MS-XQ-LC1-148 substantive decided XQ Jonathan Robie
+qt-2004Feb0865-01 ORA-XQ-385-C: Missing modules in the picture substantive decided XQ Jonathan Robie
+qt-2004Feb0863-01 ORA-XQ-375-B: Implicit timezone is optional substantive decided XQ Jonathan Robie
+qt-2004Feb0862-01 ORA-XQ-151-E: pushState() with no argument is confusing and unnecessary substantive decided XQ Scott Boag
+qt-2004Feb0166-01 Context item, context position, context size substantive decided XP Jonathan Robie
+qt-2004Feb0836-01 [QT] CER-14 local: substantive decided XQ Jonathan Robie
+qt-2004Feb0834-01 [QT] CER-13 prefix vs. namespace substantive decided XQ Jonathan Robie
+qt-2004Feb0833-01 [QT] CER-15 Schema import substantive decided XQ Jonathan Robie
+qt-2004Feb0824-01 [QT] CER-04 Module import substantive decided XQ Jonathan Robie
+qt-2004Feb0823-01 [QT] CER-05 Catching dynamic errors substantive decided XQ Jonathan Robie
+qt-2004Feb0821-01 [General] CER-03 Input sources substantive decided XQ Jonathan Robie
+qt-2004Feb0819-01 [QT] CER-02 Line-oriented comment syntax substantive decided XQ Scott Boag
+qt-2004Feb0817-01 [QT] CER-01 Comments and pragmas substantive decided XQ Scott Boag
+qt-2004Feb0801-01 [XQuery] MS-XQ-LC1-146 substantive decided XQ Scott Boag
+qt-2004Feb0799-01 [XQuery] MS-XQ-LC1-144 substantive decided XQ Jonathan Robie
+qt-2004Feb0798-01 [XQuery] MS-XQ-LC1-143 substantive decided XQ Jonathan Robie
+qt-2004Feb0796-01 [XQuery] MS-XQ-LC1-141 substantive decided XQ Jonathan Robie
+qt-2004Feb0794-01 [XQuery] MS-XQ-LC1-140 substantive decided XQ Jonathan Robie
+qt-2004Feb0792-01 [XQuery] MS-XQ-LC1-137 substantive decided XQ Jonathan Robie
+qt-2004Feb0791-01 [XQuery] MS-XQ-LC1-136 substantive decided XQ Jonathan Robie
+qt-2004Feb0790-01 [XQuery] MS-XQ-LC1-135 substantive decided XQ Jonathan Robie
+qt-2004Feb0789-01 [XQuery] MS-XQ-LC1-134 substantive decided XQ Jonathan Robie
+qt-2004Feb0784-01 [XQuery] MS-XQ-LC1-129 substantive decided XQ Jonathan Robie
+qt-2004Feb0783-01 [XQuery] MS-XQ-LC1-128 substantive decided XQ Jonathan Robie
+qt-2004Feb0776-01 [XQuery] IBM-XQ-024: Computed PI constructors substantive decided XQ Jonathan Robie
+qt-2004Feb0775-01 [XQuery] IBM-XQ-025: Comparable types in Order By clause substantive decided XQ Jonathan Robie
+qt-2004Feb0773-01 [XQuery] IBM-XQ-023: Computed attribute constructor vs. namespace declaration attribute substantive decided XQ Jonathan Robie
+qt-2004Feb0774-01 [XQuery] IBM-XQ-021: Automatic assignment of default namespace substantive decided XQ Jonathan Robie
+qt-2004Feb0772-01 [XQuery] IBM-XQ-022: Casting QName to string substantive decided XQ Jonathan Robie
+qt-2004Feb0771-01 [XQuery] IBM-XQ-020: Delimiters in computed comments substantive decided XQ Jonathan Robie
+qt-2004Feb0770-01 [XQuery] IBM-XQ-019: Validation context substantive decided XQ Jonathan Robie
+qt-2004Feb0769-01 [XQuery] IBM-XQ-018: Copying namespace nodes substantive decided XQ Jonathan Robie
+qt-2004Feb0768-01 [XQuery] IBM-XQ-017: Delete error XP0018 substantive decided XQ Jonathan Robie
+qt-2004Feb0767-01 [XQuery] IBM-XQ-016: Add context item to static context substantive decided XQ Jonathan Robie
+qt-2004Feb0742-01 ORA-XQ-386-C: do external functions require a function declaration? substantive decided XQ Jonathan Robie
+qt-2004Feb0700-01 ORA-XQ-374-B: There is no type information for the context item substantive decided XQ Jonathan Robie
+qt-2004Feb0698-01 ORA-XQ-285-B: Two ideas to deal with comments, etc. substantive decided XQ Scott Boag
+qt-2004Feb0697-01 ORA-XQ-283-B: "Deep copy" is not defined substantive decided XQ Jonathan Robie
+qt-2004Feb0696-01 ORA-XQ-282-B: sort order of results of a step expression substantive decided XQ Jonathan Robie
+qt-2004Feb0694-01 ORA-XQ-262-C: Atomization result raises static error? substantive decided XQ Jonathan Robie
+qt-2004Feb0688-01 ORA-XQ-242-C: namespace declaration attribute substantive decided XQ Jonathan Robie
+qt-2004Feb0687-01 ORA-XQ-240-C: Use xdt:untypedAtomic for attribute node and xdt:untypedAny for element node substantive decided XQ Jonathan Robie
+qt-2004Feb0686-01 ORA-XQ-239-C: xdt:untypedAny or xs:anyType for element node evaluted from the enclosed expression substantive decided XQ Jonathan Robie
+qt-2004Feb0683-01 ORA-XQ-235-C: warning on unreachable case in typeswitch substantive decided XQ Jonathan Robie
+qt-2004Feb0682-01 ORA-XQ-234-C: user defined entities substantive decided XQ Jonathan Robie
+qt-2004Feb0678-01 ORA-XQ-229-C: Using concatenation to define the result of the FLWOR expr is vague substantive decided XQ Jonathan Robie
+qt-2004Feb0676-01 ORA-XQ-224-B: other portability concerns besides extensions substantive decided XQ Jonathan Robie
+qt-2004Feb0675-01 ORA-XQ-223-C: There should be a reference implementation of an XQuery flagger substantive decided XQ Jonathan Robie
+qt-2004Feb0672-01 ORA-XQ-213-E: Path expressions on undefined context item substantive decided XQ Jonathan Robie
+qt-2004Feb0667-01 ORA-XQ-211-C: "scope of variables" is not defined substantive decided XQ Jonathan Robie
+qt-2004Feb0665-01 ORA-XQ-209-C: what is the type of a variable in a default clause? substantive decided XQ Jonathan Robie
+qt-2004Feb0664-01 ORA-XQ-207-B: Xquery flagger should give WARNING not ERROR on must-understand extensions substantive decided XQ Jonathan Robie
+qt-2004Feb0663-01 ORA-XQ-158-B: Possible missing reference: "Namespaces in XML 1.1". substantive decided XQ Jonathan Robie
+qt-2004Feb0660-01 ORA-XQ-155-B: comments not permitted in various lexical states substantive decided XQ Scott Boag
+qt-2004Feb0659-01 ORA-XQ-154-B: pushes that are never popped risk stack overflow substantive decided XQ Scott Boag
+qt-2004Feb0657-01 ORA-XQ-152-B: the lexical rules do not account for whitespace substantive decided XQ Scott Boag
+qt-2004Feb0655-01 ORA-XQ-150-B: pushState() after changing state does not do what you want it to substantive decided XQ Scott Boag
+qt-2004Feb0654-01 ORA-XQ-147-B: difficulty interpreting ws:significant substantive decided XQ Scott Boag
+qt-2004Feb0651-01 ORA-XQ-143-B: missing ws:explicit notes substantive decided XQ Scott Boag
+qt-2004Feb0646-01 ORA-XQ-136-C: No need to permit whitespace between "$" and variable name substantive decided XQ Scott Boag
+qt-2004Feb0645-01 ORA-XQ-134-B: inconsistent whitespace rules for rules borrowed from other recommendations substantive decided XQ Scott Boag
+qt-2004Feb0643-01 ORA-XQ-133-B: grammar note gn:parens does not apply to "declare function" substantive decided XQ Scott Boag
+qt-2004Feb0642-01 ORA-XQ-132-B: name "xmlspace" suggests an incorrect association with xml:space attribute substantive decided XQ Jonathan Robie
+qt-2004Feb0641-01 ORA-XQ-131-B: permitting Expr (instead of ExprSingle) in WhereClause looks dangerous substantive decided XQ Jonathan Robie
+qt-2004Feb0639-01 ORA-XQ-130-B: no check for duplicate namespace nodes substantive decided XQ Jonathan Robie
+qt-2004Feb0638-01 ORA-XQ-128-B: PITarget should exclude "xml" substantive decided XQ Scott Boag
+qt-2004Feb0637-01 ORA-XQ-127-C: is support for XML comment constructors optional? substantive decided XQ Jonathan Robie
+qt-2004Feb0636-01 ORA-XQ-126-B: XML comments may not contain "--" (two dashes) substantive decided XQ Scott Boag
+qt-2004Feb0635-01 ORA-XQ-124-Q: rule 1)d) does not specify what happens to nilled property substantive decided XQ Jonathan Robie
+qt-2004Feb0634-01 ORA-XQ-123-B: rule 1)d) is incomplete substantive decided XQ Jonathan Robie
+qt-2004Feb0633-01 ORA-XQ-121-B: 3.7.1.3 "content": discrepancy with 3.7.3.1 "computed element constructors" substantive decided XQ Jonathan Robie
+qt-2004Feb0631-01 ORA-XQ-120-B: treatment of doc nodes is not user-friendly substantive decided XQ Jonathan Robie
+qt-2004Feb0630-01 ORA-XQ-119-B: rules appear to be in wrong order substantive decided XQ Jonathan Robie
+qt-2004Feb0629-01 ORA-XQ-116-Q: when is }} a single token and when is it two tokens? substantive decided XQ Scott Boag
+qt-2004Feb0628-01 ORA-XQ-115-B: << and >> should be partial orders, only defined on trees, not between trees substantive decided XQ Jonathan Robie
+qt-2004Feb0616-01 ORA-XQ-114-C: Please point out none of our expectations about order hold substantive decided XQ Jonathan Robie
+qt-2004Feb0608-01 ORA-XQ-107-B: what is a valid CharRef? substantive decided XQ Scott Boag
+qt-2004Feb0606-01 ORA-XQ-106-C: can an implementation define a predefined entity ref? substantive decided XQ Jonathan Robie
+qt-2004Feb0604-01 ORA-XQ-104-B: Flagger should use XML 1.0 lexical rules even if the implementation supports X ML 1.1 substantive decided XQ Jonathan Robie
+qt-2004Feb0603-01 ORA-XQ-103-B: Flagger should flag vendor extensions that are not must-understand extensions substantive decided XQ Jonathan Robie
+qt-2004Feb0602-01 ORA-XQ-102-B: Ignorable whitespace is not defined substantive decided XQ Scott Boag
+qt-2004Feb0601-01 ORA-XQ-100-B: Flagger should flag relaxation of lexical rules as nonportable substantive decided XQ Scott Boag
+qt-2004Feb0600-01 ORA-XQ-099-C: does a pragma containing a must-understand extension get flagged? substantive decided XQ Scott Boag
+qt-2004Feb0599-01 ORA-XQ-098-B: Not good to make must-understand extensions look like comments substantive decided XQ Scott Boag
+qt-2004Feb0598-01 ORA-XQ-097-C: Can a pragma include a must-understand extension? substantive decided XQ Scott Boag
+qt-2004Feb0596-01 ORA-XQ-096-C: can a pragma include a comment? substantive decided XQ Scott Boag
+qt-2004Feb0595-01 ORA-XQ-095-B: EBNF for PragmaContents, ExtensionContents and ExprCommentContent is ambiguous substantive decided XQ Scott Boag
+qt-2004Feb0593-01 ORA-XQ-092-B: definition of static typing is too rigorous to be useful substantive decided XQ Jonathan Robie
+qt-2004Feb0592-01 ORA-XQ-089-Q: Are all XQuery errors in the xdt namespace? substantive decided XQ Jonathan Robie
+qt-2004Feb0591-01 ORA-XQ-088-C: enforcement of imported schema consistency substantive decided XQ Jonathan Robie
+qt-2004Feb0587-01 ORA-XQ-080-C: Enforcement of consistency constraints substantive decided XQ Jonathan Robie
+qt-2004Feb0585-01 ORA-XQ-078-B: XQuery should permit partial static typing substantive decided XQ Jonathan Robie
+qt-2004Feb0583-01 ORA-XQ-076-C: Is "let $i = ()" permitted? substantive decided XQ Jonathan Robie
+qt-2004Feb0576-01 ORA-XQ-073-C: "available documents is not constrained by ... statically known documents" substantive decided XQ Jonathan Robie
+qt-2004Feb0565-01 ORA-XQ-069-E: what is the default type of a collection? substantive decided XQ Jonathan Robie
+qt-2004Feb0557-01 ORA-XQ-063-C: Please clarify what is a collation substantive decided XQ Jonathan Robie
+qt-2004Feb0554-01 ORA-XQ-061-C: XQuery should allow implementation-defined namespaces substantive decided XQ Jonathan Robie
+qt-2004Feb0553-01 ORA-XQ-060-C: Which namespaces are predefined? substantive decided XQ Jonathan Robie
+qt-2004Feb0552-01 ORA-XQ-059-B: XQuery expressions do not need to be written in Unicode substantive decided XQ Scott Boag
+qt-2004Feb0550-01 ORA-XQ-206-C: type promotion substantive decided XQ Jonathan Robie
+qt-2004Feb0548-01 ORA-XQ-217-C: Clarify when the consistency constraints need to hold substantive decided XQ Jonathan Robie
+qt-2004Feb0533-01 [XQuery] MS-XQ-LC1-125 substantive decided XQ Jonathan Robie
+qt-2004Feb0532-01 [XQuery] MS-XQ-LC1-124 substantive decided XQ Jonathan Robie
+qt-2004Feb0520-01 [XQuery] MS-XQ-LC1-112 substantive decided XQ Jonathan Robie
+qt-2004Feb0516-01 [XQuery] MS-XQ-LC1-108 substantive decided XQ Jonathan Robie
+qt-2004Feb0511-01 [XQuery] MS-XQ-LC1-103 substantive decided XQ Jonathan Robie
+qt-2004Feb0508-01 [XQuery] MS-XQ-LC1-100 substantive decided XQ Jonathan Robie
+qt-2004Feb0507-01 [XQuery] MS-XQ-LC1-099 substantive decided XQ Jonathan Robie
+qt-2004Feb0500-01 [XQuery] MS-XQ-LC1-092 substantive decided XQ Jonathan Robie
+qt-2004Feb0498-01 [XQuery] MS-XQ-LC1-090 substantive decided XQ Jonathan Robie
+qt-2004Feb0497-01 [XQuery] MS-XQ-LC1-089 substantive decided XQ Jonathan Robie
+qt-2004Feb0495-01 [XQuery] MS-XQ-LC1-087 substantive decided XQ Jonathan Robie
+qt-2004Feb0494-01 [XQuery] MS-XQ-LC1-086 substantive decided XQ Jonathan Robie
+qt-2004Feb0493-01 [XQuery] MS-XQ-LC1-085 substantive decided XQ Jonathan Robie
+qt-2004Feb0492-01 [XQuery] MS-XQ-LC1-084 substantive decided XQ Jonathan Robie
+qt-2004Feb0491-01 [XQuery] MS-XQ-LC1-083 substantive decided XQ Jonathan Robie
+qt-2004Feb0490-01 [XQuery] MS-XQ-LC1-082 substantive decided XQ Jonathan Robie
+qt-2004Feb0471-01 [XQuery] MS-XQ-LC1-063 substantive decided XQ Jonathan Robie
+qt-2004Feb0458-01 [XQuery] 3.1.6 XQuery Comments: placement substantive decided XQ Scott Boag
+qt-2004Feb0455-01 [XQuery] BEA_030 substantive decided XQ Jonathan Robie
+qt-2004Feb0454-01 [XQuery] BEA_029 substantive decided XQ Jonathan Robie
+qt-2004Feb0453-01 [XQuery] BEA_028 substantive decided XQ Jonathan Robie
+qt-2004Feb0448-01 [XQuery] BEA_023 substantive decided XQ Jonathan Robie
+qt-2004Feb0446-01 [XQuery] BEA_021 substantive decided XQ Jonathan Robie
+qt-2004Feb0418-01 [XQuery] 'local' namespace substantive decided XQ Jonathan Robie
+qt-2004Feb0412-01 [XQuery] document node constructor only way to construct document? substantive decided XQ Jonathan Robie
+qt-2004Feb0411-01 [XQuery] [17] EscapeQuot substantive decided XQ Scott Boag
+qt-2004Feb0415-01 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-02 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-03 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-04 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-05 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-06 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-07 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-08 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-09 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-10 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-11 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-12 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-13 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-14 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-15 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-16 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-17 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-18 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-19 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0415-20 [XQuery] I18N last call comments substantive decided XQ Jonathan Robie
+qt-2004Feb0382-01 [General] Typing issues substantive decided XQ Jonathan Robie
+qt-2004Feb0285-01 [XQuery] 3.7.4 Namespace nodes on constructed elements substantive decided XQ Jonathan Robie
+qt-2004Feb0222-01 [XQuery] IBM-XQ-015: validate mode: skip preserve substantive decided XQ Jonathan Robie
+qt-2004Feb0218-01 [XQuery] IBM-XQ-011: Validation and identity substantive decided XQ Jonathan Robie
+qt-2004Feb0216-01 [XQuery] IBM-XQ-009: "xs" namespace should be in-scope substantive decided XQ Jonathan Robie
+qt-2004Feb0215-01 [XQuery] IBM-XQ-008: Transitivity of value comparisons substantive decided XQ Jonathan Robie
+qt-2004Feb0213-01 [XQuery] XQ-IBM-006: Context of a function body substantive decided XQ Jonathan Robie
+qt-2004Feb0212-01 [XQuery] IBM-XQ-005: Selective implementation of axes substantive decided XQ Jonathan Robie
+qt-2004Feb0209-01 [XQuery] Create namespace node for xs:QName substantive decided XQ Jonathan Robie
+qt-2004Feb0193-01 [XQuery] A.2.1 White Space Rules substantive decided XQ Scott Boag
+qt-2004Feb0181-01 [XQuery] Default element namespace and QNames? substantive decided XQ Jonathan Robie
+qt-2004Feb0177-01 [XQuery] Default element namespace and QNames? substantive decided XQ Jonathan Robie
+qt-2004Feb0173-01 Validation in 3.7.3.3 Document Node Constructors substantive decided XQ Jonathan Robie
+qt-2004Feb0169-01 Static flagger belongs in static context substantive decided XQ Jonathan Robie
+qt-2004Feb0103-01 [XQuery] 3.2 Order of nodes constructed in a path substantive decided XQ Jonathan Robie
+qt-2004Feb0101-01 FW: XML Declaration substantive decided XQ Scott Boag
+qt-2004Feb0098-01 [XQ] Meaning of substitution groups in element(ElementName,TypeName) substantive decided XQ Jonathan Robie
+qt-2004Feb0085-01 [XQuery] Reference to error XP0050 (editorial) substantive decided XQ Jonathan Robie
+qt-2004Feb0007-01 [XQuery ] doc. order of attribute nodes created in element constructor substantive decided XQ Jonathan Robie
+qt-2004Jan0426-01 [XQuery] Error Handling ? substantive decided XQ Jonathan Robie
+qt-2004Jan0418-01 [XPath] Legal vaues for a satisfies expression in a quantifier? substantive decided XQ Scott Boag
+qt-2004Jan0379-01 XQuery media type substantive decided XQ Jonathan Robie
+qt-2004Jan0360-01 [XQuery] Missing S in XmlPI rule substantive decided XQ Scott Boag
+qt-2004Jan0342-01 [XQuery] Inconsistent syntax for variable declarations substantive decided XQ Jonathan Robie
+qt-2004Jan0340-01 [XQuery] Lexical rules for comment, pi, cdata substantive decided XQ Scott Boag
+qt-2004Jan0243-01 [XQuery] A.2.2 Lexical Rules: bad transitions substantive decided XQ Scott Boag
+qt-2004Jan0242-01 [XQuery] A.2.2 Lexical Rules: erroneous patterns substantive decided XQ Scott Boag
+qt-2004Jan0241-01 [XQuery] A.2.2 Lexical Rules: pattern conflicts substantive decided XQ Scott Boag
+qt-2004Jan0238-01 [XQuery] Early Lall Call comment on Prolog syntax substantive decided XQ Jonathan Robie
+qt-2004Jan0207-01 [XQuery] MS-XQ-LC1-051 substantive decided XQ Jonathan Robie
+qt-2004Jan0206-01 [XQuery] MS-XQ-LC1-050 substantive decided XQ Jonathan Robie
+qt-2004Jan0204-01 [XQuery] MS-XQ-LC1-048 substantive decided XQ Jonathan Robie
+qt-2004Jan0208-01 [XQuery] MS-XQ-LC1-047 substantive decided XQ Jonathan Robie
+qt-2004Jan0203-01 [XQuery] MS-XQ-LC1-046 substantive decided XQ Jonathan Robie
+qt-2004Jan0200-01 [XQuery] MS-XQ-LC1-045 substantive decided XQ Jonathan Robie
+qt-2004Jan0199-01 [XQuery] MS-XQ-LC1-043 substantive decided XQ Jonathan Robie
+qt-2004Jan0198-01 [XQuery] MS-XQ-LC1-042 substantive decided XQ Jonathan Robie
+qt-2004Jan0189-01 [XQuery] MS-XQ-LC1-032 substantive decided XQ Jonathan Robie
+qt-2004Jan0186-01 [XQuery] MS-XQ-LC1-029 substantive decided XQ Jonathan Robie
+qt-2004Jan0184-01 [XQuery] MS-XQ-LC1-027 substantive decided XQ Jonathan Robie
+qt-2004Jan0175-01 [XQuery] MS-XQ-LC1-018 substantive decided XQ Jonathan Robie
+qt-2004Jan0169-01 [XQuery] IBM-XQ-002 - Metadata substantive decided XQ Jonathan Robie
+qt-2004Jan0162-01 [XQuery] MS-XQ-LC1-017 substantive decided XQ Jonathan Robie
+qt-2004Jan0160-01 [XQuery] MS-XQ-LC1-015 substantive decided XQ Jonathan Robie
+qt-2004Jan0154-01 [XQuery] MS-XQ-LC1-009 substantive decided XQ Jonathan Robie
+qt-2004Jan0149-01 [XQuery] MS-XQ-LC1-004 substantive decided XQ Jonathan Robie
+qt-2004Jan0093-01 [Xquery] Comment constructors substantive decided XQ Scott Boag
+qt-2004Jan0084-01 [XQuery] Semantics of validation context substantive decided XQ Jonathan Robie
+qt-2004Jan0083-01 [XQuery] Namespace for library modules substantive decided XQ Jonathan Robie
+qt-2004Jan0081-01 [XQuery] Uniqueness of module namespaces substantive decided XQ Jonathan Robie
+qt-2004Jan0056-01 [XQuery] Path expressions and axis features substantive decided XQ Jonathan Robie
+qt-2003Dec0288-01 multiple modules with same namespace substantive decided XQ Jonathan Robie
+qt-2003Dec0264-01 [XQuery] Precedence rules for QuantifiedExpr - OrExpr - AndExpr substantive decided XQ Scott Boag
+qt-2003Nov0307-01 [XQuery] SAG-XQ-004 Unordered substantive decided XQ Jonathan Robie
+qt-2003Nov0304-01 [XQuery] SAG-XQ-003 Run-time access to static namespace context substantive decided XQ Jonathan Robie
+qt-2003Nov0303-01 [XQuery] SAG-XQ-002 Input collection substantive decided XQ Jonathan Robie
+qt-2003Nov0292-01 computed namespace constructors substantive decided XQ Jonathan Robie
+qt-2003Nov0261-01 [XQuery] Normalizing line endings substantive decided XQ Jonathan Robie
+qt-2003Nov0249-01 [XQuery] use of XP0008 for element/attribute names substantive decided XQ Jonathan Robie
+qt-2003Nov0217-01 [XQuery] 2.6.3 Full Axis Feature substantive decided XQ Jonathan Robie
+qt-2003Nov0194-01 [XQuery] empty strings in content expressions substantive decided XQ Jonathan Robie
+qt-2003Nov0188-01 union, intersect, and except substantive decided XQ Jonathan Robie
+qt-2003Nov0186-01 recursive imporged variable declarations substantive decided XQ Jonathan Robie
+qt-2003Nov0300-01 belated namespace declaration attributes substantive decided XQ Jonathan Robie
+qt-2003Nov0032-01 [XQuery] Computed CDATA constructor substantive decided XQ Jonathan Robie
+qt-2004Mar0058-01 [XQuery] LQ-XQ-01 - human readable editorial decided XQ Jonathan Robie
+qt-2004Feb1160-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-017 editorial decided XQ Jonathan Robie
+qt-2004Feb1156-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-013 editorial decided XQ Jonathan Robie
+qt-2004Feb1155-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-012 editorial decided XQ Jonathan Robie
+qt-2004Feb1154-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-011 editorial decided XQ Jonathan Robie
+qt-2004Feb1153-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-010 editorial decided XQ Jonathan Robie
+qt-2004Feb1152-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-009 editorial decided XQ Jonathan Robie
+qt-2004Feb1151-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-008 editorial decided XQ Jonathan Robie
+qt-2004Feb1149-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-007 editorial decided XQ Jonathan Robie
+qt-2004Feb1150-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-006 editorial decided XQ Jonathan Robie
+qt-2004Feb1148-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-005 editorial decided XQ Jonathan Robie
+qt-2004Feb1147-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-004 editorial decided XQ Jonathan Robie
+qt-2004Feb1146-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-003 editorial decided XQ Jonathan Robie
+qt-2004Feb1144-01 Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-001 editorial decided XQ Jonathan Robie
+qt-2004Feb1000-01 [XQuery] BEA_033 editorial decided XQ Jonathan Robie
+qt-2004Feb0861-01 ORA-XQ-149-E: no explicit mention of lexical errors editorial decided XQ Scott Boag
+qt-2004Feb0860-01 ORA-XQ-067-E: Definitions should not have exceptions editorial decided XQ Jonathan Robie
+qt-2004Feb0858-01 ORA-XQ-125-E: please expand examples to include xml:space attribute editorial decided XQ Jonathan Robie
+qt-2004Feb0853-01 ORA-XQ-148-E: suggestion: make all whitespace explicit in the EBNF editorial decided XQ Scott Boag
+qt-2004Feb0852-01 ORA-XQ-091-E: unclear when all implementations must raise non-type-related static errors editorial decided XQ Jonathan Robie
+qt-2004Feb0851-01 ORA-XQ-090-E: please rewrite as a positive rather than a double negative editorial decided XQ Jonathan Robie
+qt-2004Feb0850-01 ORA-XQ-139-E: confusing use of "vs." in gn:xml-version editorial decided XQ Jonathan Robie
+qt-2004Feb0849-01 ORA-XQ-144-E: in ws:explicit, comments, pragmas and must-knows are not whitespace editorial decided XQ Scott Boag
+qt-2004Feb0848-01 ORA-XQ-129-E: need hot links for "name expression" and "content expression" editorial decided XQ Jonathan Robie
+qt-2004Feb0846-01 ORA-XQ-135-E: "should be regarded" should not be used editorial decided XQ Scott Boag
+qt-2004Feb0844-01 ORA-XQ-122-E: "element content" is a defined term with a conflicting meaning in XML 1.0 editorial decided XQ Jonathan Robie
+qt-2004Feb0843-01 ORA-XQ-118-E: namespace declaration attributes, improvement on the example editorial decided XQ Jonathan Robie
+qt-2004Feb0842-01 ORA-XQ-117-E: attributes must have distinct expanded QNames editorial decided XQ Jonathan Robie
+qt-2004Feb0841-01 ORA-XQ-108-E: 3.1.6 comments, does not belong beneath section 3, "Expressions" editorial decided XQ Scott Boag
+qt-2004Feb0840-01 ORA-XQ-105-E: "query" not defined editorial decided XQ Jonathan Robie
+qt-2004Feb0839-01 ORA-XQ-101-E: Improper definition, must-understand extension editorial decided XQ Jonathan Robie
+qt-2004Feb0838-01 ORA-XQ-093-E: Please explain the grammar note and whitespace rule conventions editorial decided XQ Scott Boag
+qt-2004Feb0835-01 ORA-XQ-083-E: Improper use of "has the nilled property" editorial decided XQ Jonathan Robie
+qt-2004Feb0827-01 ORA-XQ-081-E: improper use of "in the data model" editorial decided XQ Jonathan Robie
+qt-2004Feb0820-01 ORA-XQ-057-E: Inconsistent use of bolding editorial decided XQ Jonathan Robie
+qt-2004Feb0818-01 ORA-XQ-058-E: improper definitions editorial decided XQ Jonathan Robie
+qt-2004Feb0802-01 [XQuery] MS-XQ-LC1-147 editorial decided XQ Jonathan Robie
+qt-2004Feb0800-01 [XQuery] MS-XQ-LC1-145 editorial decided XQ Scott Boag
+qt-2004Feb0797-01 [XQuery] MS-XQ-LC1-142 editorial decided XQ Scott Boag
+qt-2004Feb0793-01 [XQuery] MS-XQ-LC1-139 editorial decided XQ Jonathan Robie
+qt-2004Feb0795-01 [XQuery] MS-XQ-LC1-138 editorial decided XQ Jonathan Robie
+qt-2004Feb0788-01 [XQuery] MS-XQ-LC1-133 editorial decided XQ Jonathan Robie
+qt-2004Feb0787-01 [XQuery] MS-XQ-LC1-132 editorial decided XQ Jonathan Robie
+qt-2004Feb0786-01 [XQuery] MS-XQ-LC1-131 editorial decided XQ Jonathan Robie
+qt-2004Feb0785-01 [XQuery] MS-XQ-LC1-130 editorial decided XQ Jonathan Robie
+qt-2004Feb0782-01 [XQuery] MS-XQ-LC1-127 editorial decided XQ Jonathan Robie
+qt-2004Feb0781-01 [XQuery] MS-XQ-LC1-126 editorial decided XQ Jonathan Robie
+qt-2004Feb0713-01 ORA-DM-346-B: Prefix Bindings values are out of synch with what is defined in XQuery 1.0 spec editorial decided XQ Jonathan Robie
+qt-2004Feb0699-01 ORA-XQ-339-C: Should "/a/(1 to 5)[2]" raise type error? editorial decided XQ Jonathan Robie
+qt-2004Feb0693-01 ORA-XQ-246-C: add more examples explaining why "let $i:= $i +1" is unintuitive in XQuery editorial decided XQ Jonathan Robie
+qt-2004Feb0692-01 ORA-XQ-245-E: predefined namespace needs to add xml editorial decided XQ Jonathan Robie
+qt-2004Feb0685-01 ORA-XQ-237-C: Validation of element constructed by direct element constructor should cross reference 3.13 Validate Expr editorial decided XQ Jonathan Robie
+qt-2004Feb0681-01 ORA-XQ-233-C: Orderspec should specify that empty sequence is considered as the same type as other tuples editorial decided XQ Jonathan Robie
+qt-2004Feb0680-01 ORA-XQ-232-E: Typeswitch needs to specify its special rule for propagating dynamic errors editorial decided XQ Jonathan Robie
+qt-2004Feb0679-01 ORA-XQ-231-C: Need to specify the behavior of XPath context position matching predicate for unordered sequence editorial decided XQ Jonathan Robie
+qt-2004Feb0662-01 ORA-XQ-157-B: undefined "input_stream.backup(1)" editorial decided XQ Scott Boag
+qt-2004Feb0661-01 ORA-XQ-156-B: no pattern called NotOccurrenceIndicator editorial decided XQ Scott Boag
+qt-2004Feb0658-01 ORA-XQ-153-B: rules for permissible comments etc. are not kind to humans editorial decided XQ Scott Boag
+qt-2004Feb0653-01 ORA-XQ-146-Q: what is the difference between ws:explicit and ws:significant? editorial decided XQ Scott Boag
+qt-2004Feb0652-01 ORA-XQ-145-B: "value content" not defined editorial decided XQ Scott Boag
+qt-2004Feb0650-01 ORA-XQ-142-C: which is "larger", XML 1.0 or 1.1? editorial decided XQ Scott Boag
+qt-2004Feb0649-01 ORA-XQ-141-C: gn:parens: lookahead of more than one character required editorial decided XQ Scott Boag
+qt-2004Feb0648-01 ORA-XQ-140-C: gn:parens: lookahead also needed to distinguish keyword from function editorial decided XQ Scott Boag
+qt-2004Feb0647-01 ORA-XQ-138-B: some EBNF rules stated better in XML 1.0 Recommendation editorial decided XQ Scott Boag
+qt-2004Feb0614-01 ORA-XQ-112-C: "leading slash" issue not well defined editorial decided XQ Scott Boag
+qt-2004Feb0612-01 ORA-XQ-111-C: clarify whitespace is not the issue with leading slashes editorial decided XQ Scott Boag
+qt-2004Feb0611-01 ORA-XQ-110-B: grammar note gn:parens as written does not apply to ExprCommentContent editorial decided XQ Scott Boag
+qt-2004Feb0609-01 ORA-XQ-109-B: human-readable definition of "ignorable whitespace" is needed editorial decided XQ Scott Boag
+qt-2004Feb0594-01 ORA-XQ-094-C: grammar note gn:parens does not seem to apply editorial decided XQ Scott Boag
+qt-2004Feb0588-01 ORA-XQ-082-E: undefined term "data model node"; just "node" is correct editorial decided XQ Jonathan Robie
+qt-2004Feb0586-01 ORA-XQ-079-E: (ab)use of "data model" (2) editorial decided XQ Jonathan Robie
+qt-2004Feb0584-01 ORA-XQ-077-E: undefined term "query" editorial decided XQ Jonathan Robie
+qt-2004Feb0582-01 ORA-XQ-075-E: "area labeled the external processing domain" editorial decided XQ Jonathan Robie
+qt-2004Feb0578-01 ORA-XQ-074-E: (ab)use of term "data model" editorial decided XQ Jonathan Robie
+qt-2004Feb0573-01 ORA-XQ-072-E: undefined terms "query" and "transformation" editorial decided XQ Jonathan Robie
+qt-2004Feb0566-01 ORA-XQ-071-E: wording: "in a path expression" editorial decided XQ Jonathan Robie
+qt-2004Feb0564-01 ORA-XQ-068-C: What if there is a top-level element called "global"? editorial decided XQ Jonathan Robie
+qt-2004Feb0563-01 ORA-XQ-065-E: vague quantification in "a collation may be regarded" editorial decided XQ Jonathan Robie
+qt-2004Feb0561-01 ORA-XQ-064-E: "may be regarded" may be regarded harmful editorial decided XQ Jonathan Robie
+qt-2004Feb0555-01 ORA-XQ-062-E: possible typo: "environmentor" editorial decided XQ Jonathan Robie
+qt-2004Feb0549-01 ORA-XQ-219-E: Expression processing requires forward pointer to kinds of errors editorial decided XQ Jonathan Robie
+qt-2004Feb0531-01 [XQuery] MS-XQ-LC1-123 editorial decided XQ Jonathan Robie
+qt-2004Feb0527-01 [XQuery] MS-XQ-LC1-119 editorial decided XQ Jonathan Robie
+qt-2004Feb0526-01 [XQuery] MS-XQ-LC1-118 editorial decided XQ Jonathan Robie
+qt-2004Feb0525-01 [XQuery] MS-XQ-LC1-117 editorial decided XQ Jonathan Robie
+qt-2004Feb0524-01 [XQuery] MS-XQ-LC1-116 editorial decided XQ Jonathan Robie
+qt-2004Feb0523-01 [XQuery] MS-XQ-LC1-115 editorial decided XQ Jonathan Robie
+qt-2004Feb0522-01 [XQuery] MS-XQ-LC1-114 editorial decided XQ Jonathan Robie
+qt-2004Feb0521-01 [XQuery] MS-XQ-LC1-113 editorial decided XQ Scott Boag
+qt-2004Feb0519-01 [XQuery] MS-XQ-LC1-111 editorial decided XQ Jonathan Robie
+qt-2004Feb0518-01 [XQuery] MS-XQ-LC1-110 editorial decided XQ Jonathan Robie
+qt-2004Feb0517-01 [XQuery] MS-XQ-LC1-109 editorial decided XQ Jonathan Robie
+qt-2004Feb0514-01 [XQuery] MS-XQ-LC1-106 editorial decided XQ Jonathan Robie
+qt-2004Feb0513-01 [XQuery] MS-XQ-LC1-105 editorial decided XQ Jonathan Robie
+qt-2004Feb0512-01 [XQuery] MS-XQ-LC1-104 editorial decided XQ Jonathan Robie
+qt-2004Feb0510-01 [XQuery] MS-XQ-LC1-102 editorial decided XQ Jonathan Robie
+qt-2004Feb0509-01 [XQuery] MS-XQ-LC1-101 editorial decided XQ Jonathan Robie
+qt-2004Feb0505-01 [XQuery] MS-XQ-LC1-097 editorial decided XQ Jonathan Robie
+qt-2004Feb0504-01 [XQuery] MS-XQ-LC1-096 editorial decided XQ Jonathan Robie
+qt-2004Feb0503-01 [XQuery] MS-XQ-LC1-095 editorial decided XQ Jonathan Robie
+qt-2004Feb0502-01 [XQuery] MS-XQ-LC1-094 editorial decided XQ Jonathan Robie
+qt-2004Feb0501-01 [XQuery] MS-XQ-LC1-093 editorial decided XQ Jonathan Robie
+qt-2004Feb0499-01 [XQuery] MS-XQ-LC1-091 editorial decided XQ Jonathan Robie
+qt-2004Feb0496-01 [XQuery] MS-XQ-LC1-088 editorial decided XQ Jonathan Robie
+qt-2004Feb0489-01 [XQuery] MS-XQ-LC1-081 editorial decided XQ Jonathan Robie
+qt-2004Feb0487-01 [XQuery] MS-XQ-LC1-079 editorial decided XQ Jonathan Robie
+qt-2004Feb0482-01 [XQuery] MS-XQ-LC1-074 editorial decided XQ Jonathan Robie
+qt-2004Feb0481-01 [XQuery] MS-XQ-LC1-073 editorial decided XQ Jonathan Robie
+qt-2004Feb0480-01 [XQuery] MS-XQ-LC1-072 editorial decided XQ Jonathan Robie
+qt-2004Feb0479-01 [XQuery] MS-XQ-LC1-071 editorial decided XQ Jonathan Robie
+qt-2004Feb0478-01 [XQuery] MS-XQ-LC1-070 editorial decided XQ Jonathan Robie
+qt-2004Feb0476-01 [XQuery] MS-XQ-LC1-068 editorial decided XQ Jonathan Robie
+qt-2004Feb0475-01 [XQuery] MS-XQ-LC1-067 editorial decided XQ Jonathan Robie
+qt-2004Feb0474-01 [XQuery] MS-XQ-LC1-066 editorial decided XQ Jonathan Robie
+qt-2004Feb0472-01 [XQuery] MS-XQ-LC1-064 editorial decided XQ Jonathan Robie
+qt-2004Feb0470-01 [XQuery] MS-XQ-LC1-062 editorial decided XQ Jonathan Robie
+qt-2004Feb0469-01 [XQuery] MS-XQ-LC1-061 editorial decided XQ Jonathan Robie
+qt-2004Feb0457-01 [XQuery] BEA_032 editorial decided XQ Jonathan Robie
+qt-2004Feb0456-01 [XQuery] BEA_031 editorial decided XQ Jonathan Robie
+qt-2004Feb0452-01 [XQuery] BEA_027 editorial decided XQ Jonathan Robie
+qt-2004Feb0451-01 [XQuery] BEA_026 editorial decided XQ Jonathan Robie
+qt-2004Feb0449-01 [XQuery] BEA_024 editorial decided XQ Jonathan Robie
+qt-2004Feb0447-01 [XQuery] BEA_022 editorial decided XQ Jonathan Robie
+qt-2004Feb0445-01 [XQuery] BEA_020 editorial decided XQ Jonathan Robie
+qt-2004Feb0444-01 [XQuery] BEA_019 editorial decided XQ Jonathan Robie
+qt-2004Feb0443-01 [XQuery] BEA_018 editorial decided XQ Jonathan Robie
+qt-2004Feb0441-01 [XQuery] BEA_016 editorial decided XQ Jonathan Robie
+qt-2004Feb0440-01 [XQuery] BEA_015 editorial decided XQ Jonathan Robie
+qt-2004Feb0424-01 [XQuery] A.1.1 Grammar Notes: xml-version editorial decided XQ Scott Boag
+qt-2004Feb0423-01 [XQuery] A.1.1 Grammar Notes: leading-lone-slash editorial decided XQ Scott Boag
+qt-2004Feb0422-01 [XQuery] A.1.1 Grammar Notes: lt editorial decided XQ Scott Boag
+qt-2004Feb0421-01 [XQuery] A.1.1 Grammar Notes: parens editorial decided XQ Scott Boag
+qt-2004Feb0417-01 [XQuery] too many sections in References editorial decided XQ Jonathan Robie
+qt-2004Feb0416-01 [XQuery] namespace location editorial decided XQ Jonathan Robie
+qt-2004Feb0414-01 [XQuery] wording about XQuery processor editorial decided XQ Jonathan Robie
+qt-2004Feb0413-01 [XQuery] additional namespace outputs editorial decided XQ Jonathan Robie
+qt-2004Feb0397-01 [XPath/XQuery] streamline item 2 in precedence order editorial decided XQ Scott Boag
+qt-2004Feb0396-01 [XPath/XQuery] whitespace: What is a word editorial decided XQ Scott Boag
+qt-2004Feb0380-01 [XQuery] A.1 EBNF: rename some symbols editorial decided XQ Scott Boag
+qt-2004Feb0379-01 [XQuery] A.1 EBNF: introduce DirectConstructor editorial decided XQ Scott Boag
+qt-2004Feb0378-01 [XQuery] A.1 EBNF: order of productions editorial decided XQ Scott Boag
+qt-2004Feb0368-01 [XPath 2.0] XSCH-XPATH-003 editorial decided XQ Jonathan Robie
+qt-2004Feb0321-01 [XQuery] lexical leftovers 7 editorial decided XQ Scott Boag
+qt-2004Feb0319-01 [XQuery] lexical leftovers 5 editorial decided XQ Scott Boag
+qt-2004Feb0318-01 [XQuery] lexical leftovers 4 editorial decided XQ Scott Boag
+qt-2004Feb0317-01 [XQuery] lexical leftovers 3 editorial decided XQ Scott Boag
+qt-2004Feb0314-01 ORA-XQ-055-E: Formatting is not good for hardcopy viewing editorial decided XQ Jonathan Robie
+qt-2004Feb0313-01 ORA-XQ-056-E: No definition of terms such as "may" editorial decided XQ Jonathan Robie
+qt-2004Feb0220-01 [XQuery] IBM-XQ-013: Delete unnecessary note editorial decided XQ Jonathan Robie
+qt-2004Feb0219-01 [XQuery] IBM-XQ-012: Default function namespace editorial decided XQ Jonathan Robie
+qt-2004Feb0217-01 [XQuery] IBM-XQ-010: Bug in computed constructors editorial decided XQ Jonathan Robie
+qt-2004Feb0114-01 [XQuery] use of distinct-values in chapter 3.8.4 editorial decided XQ Jonathan Robie
+qt-2004Feb0086-01 [XQuery] Extra error reference (editorial) editorial decided XQ Jonathan Robie
+qt-2004Jan0219-01 [XQuery] Issue raised by formal definition of SequenceType Matching editorial decided XQ Jonathan Robie
+qt-2004Jan0205-01 [XQuery] MS-XQ-LC1-049 editorial decided XQ Jonathan Robie
+qt-2004Jan0201-01 [XQuery] MS-XQ-LC1-044 editorial decided XQ Jonathan Robie
+qt-2004Jan0188-01 [XQuery] MS-XQ-LC1-031 editorial decided XQ Jonathan Robie
+qt-2004Jan0181-01 [XQuery] MS-XQ-LC1-024 editorial decided XQ Jonathan Robie
+qt-2004Jan0180-01 [XQuery] MS-XQ-LC1-023 editorial decided XQ Jonathan Robie
+qt-2004Jan0178-01 [XQuery] MS-XQ-LC1-021 editorial decided XQ Jonathan Robie
+qt-2004Jan0177-01 [XQuery] MS-XQ-LC1-020 editorial decided XQ Jonathan Robie
+qt-2004Jan0176-01 [XQuery] MS-XQ-LC1-019 editorial decided XQ Jonathan Robie
+qt-2004Jan0161-01 [XQuery] MS-XQ-LC1-016 editorial decided XQ Jonathan Robie
+qt-2004Jan0159-01 [XQuery] MS-XQ-LC1-014 editorial decided XQ Jonathan Robie
+qt-2004Jan0158-01 [XQuery] MS-XQ-LC1-013 editorial decided XQ Jonathan Robie
+qt-2004Jan0157-01 [XQuery] MS-XQ-LC1-012 editorial decided XQ Jonathan Robie
+qt-2004Jan0156-01 [XQuery] MS-XQ-LC1-011 editorial decided XQ Jonathan Robie
+qt-2004Jan0155-01 [XQuery] MS-XQ-LC1-010 editorial decided XQ Jonathan Robie
+qt-2004Jan0153-01 [XQuery] MS-XQ-LC1-008 editorial decided XQ Jonathan Robie
+qt-2004Jan0151-01 [XQuery] MS-XQ-LC1-006 editorial decided XQ Jonathan Robie
+qt-2004Jan0150-01 [XQuery] MS-XQ-LC1-005 editorial decided XQ Jonathan Robie
+qt-2004Jan0148-01 [XQuery] MS-XQ-LC1-003 editorial decided XQ Jonathan Robie
+qt-2004Jan0147-01 [XQuery] MS-XQ-LC1-002 editorial decided XQ Jonathan Robie
+qt-2004Jan0146-01 [XQuery] MS-XQ-LC1-001 editorial decided XQ Jonathan Robie
+qt-2004Jan0042-01 [XQuery] Static type of an external variable editorial decided XQ Jonathan Robie
+qt-2003Nov0250-01 [XQuery] What dynamic error does treat expression raise? editorial decided XQ Jonathan Robie
+qt-2003Nov0248-01 [XQuery] xmlspace declaration applies to attribute constructors? editorial decided XQ Jonathan Robie
+qt-2003Nov0247-01 [XQuery] The resulting p element (editorial) editorial decided XQ Jonathan Robie
+qt-2003Nov0246-01 [XQuery] Unqualified vs. unprefixed editorial decided XQ Jonathan Robie
+qt-2003Nov0245-01 [XQuery] simple or complex type of attribute editorial decided XQ Jonathan Robie
+qt-2003Nov0244-01 [XQuery] definitions vs. declarations (editorial) editorial decided XQ Jonathan Robie
+qt-2003Nov0046-01 Duplicate paragraph in section 3.13 editorial decided XQ Jonathan Robie
qt-2004Jan0029-01: [XQuery] MS-XQ-LC1-053
[typo, decided] 2004-10-13
[XQuery] MS-XQ-LC1-053, Michael Rys (2004-01-20)
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

qt-2004Jan0152-01: [XQuery] MS-XQ-LC1-007
[typo, decided] 2004-10-13
[XQuery] MS-XQ-LC1-007, Michael Rys (2004-01-20)
Section 2.1.1 Static Context
Editorial

"environmentor" => "environment or"

            

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

qt-2004Mar0085-01: Ref XSCH-QL-018: Example of pblm with serialization-based validation
[substantive, decided] 2004-08-31
Consider the following schema document and instance:

<xs:schema xmlns:xs="http://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: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Moved to the Data Model cluster.

RE: issue list status, Paul Cotton (2004-08-31)

            

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.

qt-2004Mar0059-01: [XQuery] LQ-XQ-02 - Calling a Web Serice
[substantive, decided] 2004-08-18
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 "http://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,
    http://www.w3.org/TR/2003/WD-wsdl20-20031110/

--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://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.

qt-2004Mar0016-01: Further to Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-019
[substantive, decided] 2004-06-02
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] http://www.w3.org/TR/2003/WD-xquery-20031112/
[2] http://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: http://www.ltg.ed.ac.uk/~ht/
[mail really from me _always_ has this .sig -- mail without it is forged spam]
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Mar0013-01: defer cyclic module import until XQuery 1.0
[substantive, decided] 2004-09-22
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   http://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.

qt-2004Feb1207-01: [XQuery] XQ-IBM-026 Function conversion rules
[substantive, decided] 2004-09-10
[XQuery] XQ-IBM-026 Function conversion rules, Don Chamberlin (2004-02-26)
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.

qt-2004Feb1161-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-018
[substantive, decided] 2004-06-02
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] http://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 [http://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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Moved to the Data Model cluster.

qt-2004Feb1159-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-016
[substantive, decided] 2004-08-31
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] http://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 = "http://example.org/math-functions";
  import module namespace math2 = "http://example.org/math2-functions";
  declare variable $x as xs:integer {$math2:z};

  module namespace math2 = "http://example.org/math2-functions";
  import module namespace math = "http://example.org/math-functions";
  declare variable $y as xs:integer {$math:x};
  declare variable $z as xs:integer {1};
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb1158-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-015
[substantive, decided] 2004-09-29
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] http://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.

qt-2004Feb1157-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-014
[substantive, decided] 2004-09-29
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] http://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.

qt-2004Feb1145-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-002
[substantive, decided] 2004-04-22
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] http://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]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

[---+-+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

qt-2004Feb1141-01: NM-XQ-5: Range expressions and empty sequences
[substantive, decided] 2004-09-10
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: http://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.

qt-2004Feb1140-01: NM-XP-4: ElementTest and control of substitution
[substantive, decided] 2004-09-29
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.

qt-2004Feb1124-01: ORA-XQ-409-B: Introduce identity-less operations as a feature
[substantive, decided] 2004-08-12
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.
XML Query Teleconference 201 Minutes 2004-08-11, Andrew Eisenberg (2004-08-12)

            

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

qt-2004Feb1110-01: ORA-XQ-411-C: base uri and xml:base interaction needs to be clarified.
[substantive, decided] 2004-08-16
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 "http://www.po.com" and has an "attachment" element that is of the anyURI type.

 Now given a query like,

 declare base-uri="http://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 http://www.some.com prefix or the xml:base property http://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="http://www.moo.com";
<A xml:base="http://www.foo.com">
  {doc("boo")}
</A>

Does the URL "boo" inside doc() resolve as http://www.foo.com/boo or http://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.

qt-2004Feb1108-01: ORA-XQ-408-B: formalize notion of tuples
[substantive, decided] 2004-08-12
ORA-XQ-408-B: formalize notion of tuples, Stephen Buxton (2004-02-20)
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.
XML Query Teleconference 201 Minutes 2004-08-11, Andrew Eisenberg (2004-08-12)

            

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

qt-2004Feb1107-01: ORA-XQ-406-B: Static type for the context item must be specified in the static context
[substantive, decided] 2004-06-20
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.
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

Minutes log just says "This issue is closed"

(joint issue)


            

[[accepted]]

qt-2004Feb1106-01: ORA-XQ-407-B: distinct values of multiple sequences should be possible
[substantive, decided] 2004-08-12
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.
XML Query Teleconference 201 Minutes 2004-08-11, Andrew Eisenberg (2004-08-12)

            

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

qt-2004Feb1092-01: [XQuery] questions about xquery/xpath core grammar
[substantive, decided] 2004-03-29
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.

qt-2004Feb1090-01: lazy or eager variable initialization?
[substantive, decided] 2004-07-27
lazy or eager variable initialization?, Per Bothner (2004-02-19)
This is a follow-on to the thread "recursive imporged [sic]
variable declarations":
http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0186.html
http://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   http://per.bothner.com/
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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)

qt-2004Feb1005-01: [XQuery] MS-XQ-LC1-148
[substantive, decided] 2004-09-29
[XQuery] MS-XQ-LC1-148, Michael Rys (2004-02-18)
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
http://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.

qt-2004Feb0865-01: ORA-XQ-385-C: Missing modules in the picture
[substantive, decided] 2004-07-27
ORA-XQ-385-C: Missing modules in the picture, Stephen Buxton (2004-02-17)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

qt-2004Feb0863-01: ORA-XQ-375-B: Implicit timezone is optional
[substantive, decided] 2004-09-22
ORA-XQ-375-B: Implicit timezone is optional, Stephen Buxton (2004-02-17)
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?

qt-2004Feb0862-01: ORA-XQ-151-E: pushState() with no argument is confusing and unnecessary
[substantive, decided] 2004-06-15
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.
qt-2004Feb0166-01: Context item, context position, context size
[substantive, decided] 2004-10-22
Context item, context position, context size, Jonathan Robie (2004-02-10)
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

qt-2004Feb0836-01: [QT] CER-14 local:
[substantive, decided] 2004-08-31
[QT] CER-14 local:, Mary Holstege (2004-02-15)
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] http://www.w3.org/TR/2003/WD-webarch-20031209/
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0834-01: [QT] CER-13 prefix vs. namespace
[substantive, decided] 2004-09-15
[QT] CER-13 prefix vs. namespace, Mary Holstege (2004-02-15)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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

qt-2004Feb0833-01: [QT] CER-15 Schema import
[substantive, decided] 2004-09-22
[QT] CER-15 Schema import, Mary Holstege (2004-02-15)
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.

qt-2004Feb0824-01: [QT] CER-04 Module import
[substantive, decided] 2004-07-27
[QT] CER-04 Module import, Mary Holstege (2004-02-15)
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 "http://example.org/application"
   Developer B: display-lib.xqy
      module "http://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 "http://example.org/application"
       import module "http://example.org/application" at "selection-lib.xqy"
       import module "http://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 "http://example.org/application"
      import module "http://example.org/application" at "constants.xqy"

   Developer B: display-lib.xqy
      module "http://example.org/application"
      import module "http://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 "http://example.org/application"

   API: application-api.xqy
      module "http://example.org/application"
      import module "http://example.org/application" at "application-lib.xqy"

   Application:
      import module "http://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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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 "http://example.org/application" import module "http://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 http://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.

qt-2004Feb0823-01: [QT] CER-05 Catching dynamic errors
[substantive, decided] 2004-08-12
[QT] CER-05 Catching dynamic errors, Mary Holstege (2004-02-15)
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.
XML Query Teleconference 201 Minutes 2004-08-11, Andrew Eisenberg (2004-08-12)

            

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)

qt-2004Feb0821-01: [General] CER-03 Input sources
[substantive, decided] 2004-09-15
[General] CER-03 Input sources, Mary Holstege (2004-02-15)
[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.
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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

qt-2004Feb0819-01: [QT] CER-02 Line-oriented comment syntax
[substantive, decided] 2004-03-24
[QT] CER-02 Line-oriented comment syntax, Mary Holstege (2004-02-15)
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.

qt-2004Feb0817-01: [QT] CER-01 Comments and pragmas
[substantive, decided] 2004-03-24
[QT] CER-01 Comments and pragmas, Mary Holstege (2004-02-15)
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.

qt-2004Feb0801-01: [XQuery] MS-XQ-LC1-146
[substantive, decided] 2004-04-24
[XQuery] MS-XQ-LC1-146, Michael Rys (2004-02-17)
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.
Re: [XQuery] MS-XQ-LC1-146, scott_boag@us.ibm.com (2004-02-23)

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
 http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0801.html

[2] Grammar issue: cast as
 http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0063.html

			
RE: [XQuery] MS-XQ-LC1-146, Michael Rys (2004-02-23)

Yes. This seems to resolve the issue.

Thanks
Mi
			

            

See [436]

qt-2004Feb0799-01: [XQuery] MS-XQ-LC1-144
[substantive, decided] 2004-08-31
[XQuery] MS-XQ-LC1-144, Michael Rys (2004-02-17)
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.
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0798-01: [XQuery] MS-XQ-LC1-143
[substantive, decided] 2004-06-20
[XQuery] MS-XQ-LC1-143, Michael Rys (2004-02-17)
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.
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

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)

qt-2004Feb0796-01: [XQuery] MS-XQ-LC1-141
[substantive, decided] 2004-06-20
[XQuery] MS-XQ-LC1-141, Michael Rys (2004-02-17)
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.
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

Issue closed - No changes to the documents at this time.

(xquery-only)


            

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

qt-2004Feb0794-01: [XQuery] MS-XQ-LC1-140
[substantive, decided] 2004-08-31
[XQuery] MS-XQ-LC1-140, Michael Rys (2004-02-17)
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.
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0792-01: [XQuery] MS-XQ-LC1-137
[substantive, decided] 2004-07-27
[XQuery] MS-XQ-LC1-137, Michael Rys (2004-02-17)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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.

qt-2004Feb0791-01: [XQuery] MS-XQ-LC1-136
[substantive, decided] 2004-07-27
[XQuery] MS-XQ-LC1-136, Michael Rys (2004-02-17)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

http://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.

qt-2004Feb0790-01: [XQuery] MS-XQ-LC1-135
[substantive, decided] 2004-07-27
[XQuery] MS-XQ-LC1-135, Michael Rys (2004-02-17)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

qt-2004Feb0789-01: [XQuery] MS-XQ-LC1-134
[substantive, decided] 2004-07-27
[XQuery] MS-XQ-LC1-134, Michael Rys (2004-02-17)
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?
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

qt-2004Feb0784-01: [XQuery] MS-XQ-LC1-129
[substantive, decided] 2004-10-13
[XQuery] MS-XQ-LC1-129, Michael Rys (2004-02-17)
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

qt-2004Feb0783-01: [XQuery] MS-XQ-LC1-128
[substantive, decided] 2004-09-29
[XQuery] MS-XQ-LC1-128, Michael Rys (2004-02-17)
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.

qt-2004Feb0776-01: [XQuery] IBM-XQ-024: Computed PI constructors
[substantive, decided] 2004-06-02
[XQuery] IBM-XQ-024: Computed PI constructors, Don Chamberlin (2004-02-16)
(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
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0775-01: [XQuery] IBM-XQ-025: Comparable types in Order By clause
[substantive, decided] 2004-09-10
(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.

qt-2004Feb0773-01: [XQuery] IBM-XQ-023: Computed attribute constructor vs. namespace declaration attribute
[substantive, decided] 2004-06-13
(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
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            


            

qt-2004Feb0774-01: [XQuery] IBM-XQ-021: Automatic assignment of default namespace
[substantive, decided] 2004-06-13
(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
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

WG Resolution: delete the 2nd paragraph feb 774


            

WG Resolution: delete the 2nd paragraph feb 774

qt-2004Feb0772-01: [XQuery] IBM-XQ-022: Casting QName to string
[substantive, decided] 2004-09-15
[XQuery] IBM-XQ-022: Casting QName to string, Don Chamberlin (2004-02-16)
(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
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

RESOLVED: CLOSED by adoption of the triple proposal

qt-2004Feb0771-01: [XQuery] IBM-XQ-020: Delimiters in computed comments
[substantive, decided] 2004-06-02
(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
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0770-01: [XQuery] IBM-XQ-019: Validation context
[substantive, decided] 2004-09-15
[XQuery] IBM-XQ-019: Validation context, Don Chamberlin (2004-02-16)
(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
http://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
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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]

qt-2004Feb0769-01: [XQuery] IBM-XQ-018: Copying namespace nodes
[substantive, decided] 2004-09-15
[XQuery] IBM-XQ-018: Copying namespace nodes, Don Chamberlin (2004-02-16)
(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
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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

qt-2004Feb0768-01: [XQuery] IBM-XQ-017: Delete error XP0018
[substantive, decided] 2004-10-08
[XQuery] IBM-XQ-017: Delete error XP0018, Don Chamberlin (2004-02-16)
(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
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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.

qt-2004Feb0767-01: [XQuery] IBM-XQ-016: Add context item to static context
[substantive, decided] 2004-06-20
(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
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

Minutes log just says "This issue is closed"

(joint issue)


            

[[accepted]]

qt-2004Feb0742-01: ORA-XQ-386-C: do external functions require a function declaration?
[substantive, decided] 2004-10-08
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.

qt-2004Feb0700-01: ORA-XQ-374-B: There is no type information for the context item
[substantive, decided] 2004-08-16
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.
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

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 http://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.

qt-2004Feb0698-01: ORA-XQ-285-B: Two ideas to deal with comments, etc.
[substantive, decided] 2004-03-24
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.

qt-2004Feb0697-01: ORA-XQ-283-B: "Deep copy" is not defined
[substantive, decided] 2004-06-02
ORA-XQ-283-B: "Deep copy" is not defined, Stephen Buxton (2004-02-16)
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0696-01: ORA-XQ-282-B: sort order of results of a step expression
[substantive, decided] 2004-10-19
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.

qt-2004Feb0694-01: ORA-XQ-262-C: Atomization result raises static error?
[substantive, decided] 2004-09-10
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

qt-2004Feb0688-01: ORA-XQ-242-C: namespace declaration attribute
[substantive, decided] 2004-06-09
ORA-XQ-242-C: namespace declaration attribute, Stephen Buxton (2004-02-16)
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.
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

WG Resolution: this has been overtaken by events, as we no longer

talk about namespace nodes.

qt-2004Feb0687-01: ORA-XQ-240-C: Use xdt:untypedAtomic for attribute node and xdt:untypedAny for element node
[substantive, decided] 2004-06-02
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Changes earlier resolution

qt-2004Feb0686-01: ORA-XQ-239-C: xdt:untypedAny or xs:anyType for element node evaluted from the enclosed expression
[substantive, decided] 2004-06-02
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Changes earlier resolution

qt-2004Feb0683-01: ORA-XQ-235-C: warning on unreachable case in typeswitch
[substantive, decided] 2004-10-08
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.

qt-2004Feb0682-01: ORA-XQ-234-C: user defined entities
[substantive, decided] 2004-08-18
ORA-XQ-234-C: user defined entities, Stephen Buxton (2004-02-16)
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.

qt-2004Feb0678-01: ORA-XQ-229-C: Using concatenation to define the result of the FLWOR expr is vague
[substantive, decided] 2004-10-08
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.

qt-2004Feb0676-01: ORA-XQ-224-B: other portability concerns besides extensions
[substantive, decided] 2004-11-13
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.

qt-2004Feb0675-01: ORA-XQ-223-C: There should be a reference implementation of an XQuery flagger
[substantive, decided] 2004-11-13
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.

qt-2004Feb0672-01: ORA-XQ-213-E: Path expressions on undefined context item
[substantive, decided] 2004-06-16
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.
XML Query Teleconference 194 Minutes 2004-06-16, Working Group Minutes (2004-06-16)

            

Section 3.1.4 - "Context item expression" - addresses this issue.

Issue closed with no change to documents

(joint issue)

qt-2004Feb0667-01: ORA-XQ-211-C: "scope of variables" is not defined
[substantive, decided] 2004-10-08
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.

qt-2004Feb0665-01: ORA-XQ-209-C: what is the type of a variable in a default clause?
[substantive, decided] 2004-10-08
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

qt-2004Feb0664-01: ORA-XQ-207-B: Xquery flagger should give WARNING not ERROR on must-understand extensions
[substantive, decided] 2004-11-13
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

qt-2004Feb0663-01: ORA-XQ-158-B: Possible missing reference: "Namespaces in XML 1.1".
[substantive, decided] 2004-08-31
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.
RE: issue list status, Paul Cotton (2004-08-31)

            

The references are all there now.

qt-2004Feb0660-01: ORA-XQ-155-B: comments not permitted in various lexical states
[substantive, decided] 2004-03-24
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.

qt-2004Feb0659-01: ORA-XQ-154-B: pushes that are never popped risk stack overflow
[substantive, decided] 2004-04-27
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.

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

Fixed, as per some other LCCs.


            

[[accepted]]

qt-2004Feb0657-01: ORA-XQ-152-B: the lexical rules do not account for whitespace
[substantive, decided] 2004-09-07
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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, http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jul/0086.html ]

qt-2004Feb0655-01: ORA-XQ-150-B: pushState() after changing state does not do what you want it to
[substantive, decided] 2004-05-11
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.

qt-2004Feb0654-01: ORA-XQ-147-B: difficulty interpreting ws:significant
[substantive, decided] 2004-06-13
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]]

qt-2004Feb0651-01: ORA-XQ-143-B: missing ws:explicit notes
[substantive, decided] 2004-06-08
ORA-XQ-143-B: missing ws:explicit notes, Stephen Buxton (2004-02-16)
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.
qt-2004Feb0646-01: ORA-XQ-136-C: No need to permit whitespace between "$" and variable name
[substantive, decided] 2004-06-08
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"
qt-2004Feb0645-01: ORA-XQ-134-B: inconsistent whitespace rules for rules borrowed from other recommendations
[substantive, decided] 2004-05-11
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]]

qt-2004Feb0643-01: ORA-XQ-133-B: grammar note gn:parens does not apply to "declare function"
[substantive, decided] 2004-05-11
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]]

qt-2004Feb0642-01: ORA-XQ-132-B: name "xmlspace" suggests an incorrect association with xml:space attribute
[substantive, decided] 2004-11-13
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.

qt-2004Feb0641-01: ORA-XQ-131-B: permitting Expr (instead of ExprSingle) in WhereClause looks dangerous
[substantive, decided] 2004-09-07
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]

qt-2004Feb0639-01: ORA-XQ-130-B: no check for duplicate namespace nodes
[substantive, decided] 2004-06-09
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.
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

Already fixed.

qt-2004Feb0638-01: ORA-XQ-128-B: PITarget should exclude "xml"
[substantive, decided] 2004-04-27
ORA-XQ-128-B: PITarget should exclude "xml", Stephen Buxton (2004-02-16)
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

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: accepted, refer to production in XML


            

[[accepted]]

qt-2004Feb0637-01: ORA-XQ-127-C: is support for XML comment constructors optional?
[substantive, decided] 2004-06-02
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0636-01: ORA-XQ-126-B: XML comments may not contain "--" (two dashes)
[substantive, decided] 2004-04-27
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

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

Don and Michael R thought this was already done

RESOLUTION: partly accepted already, resolving jan0093, but should

also be excluded from the BNF


            

[[accepted]]

qt-2004Feb0635-01: ORA-XQ-124-Q: rule 1)d) does not specify what happens to nilled property
[substantive, decided] 2004-06-02
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0634-01: ORA-XQ-123-B: rule 1)d) is incomplete
[substantive, decided] 2004-06-02
ORA-XQ-123-B: rule 1)d) is incomplete, Stephen Buxton (2004-02-16)
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0633-01: ORA-XQ-121-B: 3.7.1.3 "content": discrepancy with 3.7.3.1 "computed element constructors"
[substantive, decided] 2004-06-02
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0631-01: ORA-XQ-120-B: treatment of doc nodes is not user-friendly
[substantive, decided] 2004-05-12
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

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

qt-2004Feb0630-01: ORA-XQ-119-B: rules appear to be in wrong order
[substantive, decided] 2004-05-17
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 &#x20;,
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

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 &#x20; 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 &#x20; 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.

qt-2004Feb0629-01: ORA-XQ-116-Q: when is }} a single token and when is it two tokens?
[substantive, decided] 2004-04-27
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.

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

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


            

[[rejected]]

qt-2004Feb0628-01: ORA-XQ-115-B: << and >> should be partial orders, only defined on trees, not between trees
[substantive, decided] 2004-05-17
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

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.

qt-2004Feb0616-01: ORA-XQ-114-C: Please point out none of our expectations about order hold
[substantive, decided] 2004-05-12
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

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

qt-2004Feb0608-01: ORA-XQ-107-B: what is a valid CharRef?
[substantive, decided] 2004-04-27
ORA-XQ-107-B: what is a valid CharRef?, Stephen Buxton (2004-02-16)
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 &#x1234567890;
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

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

Closed with editorial change by Don.


            

[[accepted]]

qt-2004Feb0606-01: ORA-XQ-106-C: can an implementation define a predefined entity ref?
[substantive, decided] 2004-10-22
SECTION 3.1.1: literals

May an implementation define additional PredefinedEntityRefs?
For example, could an implementation define &euro; as &#8364; ?


- Steve B.
			
            

This was decided to be conformance at meeting 180 http://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.

qt-2004Feb0604-01: ORA-XQ-104-B: Flagger should use XML 1.0 lexical rules even if the implementation supports X ML 1.1
[substantive, decided] 2004-11-13
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.

qt-2004Feb0603-01: ORA-XQ-103-B: Flagger should flag vendor extensions that are not must-understand extensions
[substantive, decided] 2004-11-13
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

qt-2004Feb0602-01: ORA-XQ-102-B: Ignorable whitespace is not defined
[substantive, decided] 2004-06-08
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.
qt-2004Feb0601-01: ORA-XQ-100-B: Flagger should flag relaxation of lexical rules as nonportable
[substantive, decided] 2004-03-24
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.

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0600-01: ORA-XQ-099-C: does a pragma containing a must-understand extension get flagged?
[substantive, decided] 2004-03-24
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

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0599-01: ORA-XQ-098-B: Not good to make must-understand extensions look like comments
[substantive, decided] 2004-03-24
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.

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0598-01: ORA-XQ-097-C: Can a pragma include a must-understand extension?
[substantive, decided] 2004-03-24
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.

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

Already Done. Issue closed.


            

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

qt-2004Feb0596-01: ORA-XQ-096-C: can a pragma include a comment?
[substantive, decided] 2004-03-24
ORA-XQ-096-C: can a pragma include a comment?, Stephen Buxton (2004-02-16)
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.

Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

Already Done. Issue closed.


            

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

qt-2004Feb0595-01: ORA-XQ-095-B: EBNF for PragmaContents, ExtensionContents and ExprCommentContent is ambiguous
[substantive, decided] 2004-03-24
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.
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0593-01: ORA-XQ-092-B: definition of static typing is too rigorous to be useful
[substantive, decided] 2004-04-28
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
http://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.

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0592-01: ORA-XQ-089-Q: Are all XQuery errors in the xdt namespace?
[substantive, decided] 2004-05-12
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

Closed because the issue is addressed by Andrew's error proposal,

which was adopted 4 May.

qt-2004Feb0591-01: ORA-XQ-088-C: enforcement of imported schema consistency
[substantive, decided] 2004-04-28
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
http://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.

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0587-01: ORA-XQ-080-C: Enforcement of consistency constraints
[substantive, decided] 2004-04-28
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
http://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

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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

qt-2004Feb0585-01: ORA-XQ-078-B: XQuery should permit partial static typing
[substantive, decided] 2004-04-28
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
http://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.

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0583-01: ORA-XQ-076-C: Is "let $i = ()" permitted?
[substantive, decided] 2004-04-28
ORA-XQ-076-C: Is "let $i = ()" permitted?, Stephen Buxton (2004-02-16)
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?
http://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.

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0576-01: ORA-XQ-073-C: "available documents is not constrained by ... statically known documents"
[substantive, decided] 2004-04-28
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"
http://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.

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

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.

qt-2004Feb0565-01: ORA-XQ-069-E: what is the default type of a collection?
[substantive, decided] 2004-04-28
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?
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0565.html

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

         
Minutes: XML Query Teleconference 180 Agenda 2004-04-28, Working Group Minutes (2004-04-28)

            

Issue closed with no further action.

Default type of a collection should node()*.

qt-2004Feb0557-01: ORA-XQ-063-C: Please clarify what is a collation
[substantive, decided] 2004-10-08
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. http://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.

qt-2004Feb0554-01: ORA-XQ-061-C: XQuery should allow implementation-defined namespaces
[substantive, decided] 2004-04-22
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

AE: Points out that this is given in normative appendix C.1.

RESOLVED WITH NO CHANGE.

qt-2004Feb0553-01: ORA-XQ-060-C: Which namespaces are predefined?
[substantive, decided] 2004-08-31
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

AE: Points out that this is given in normative appendix C.1.

RESOLVED WITH NO CHANGE.

RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0552-01: ORA-XQ-059-B: XQuery expressions do not need to be written in Unicode
[substantive, decided] 2004-04-22
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

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

ADOPTED RESOLUTION:

ACTION-ITEM-177-02: Jim Melton to provide proposed wording.

DONE. See:

http://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."

qt-2004Feb0550-01: ORA-XQ-206-C: type promotion
[substantive, decided] 2004-04-22
ORA-XQ-206-C: type promotion, Stephen Buxton (2004-02-16)
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

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.

qt-2004Feb0548-01: ORA-XQ-217-C: Clarify when the consistency constraints need to hold
[substantive, decided] 2004-04-22
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

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.

qt-2004Feb0533-01: [XQuery] MS-XQ-LC1-125
[substantive, decided] 2004-04-22
[XQuery] MS-XQ-LC1-125, Michael Rys (2004-02-16)
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

DC: Corrected in current editor WD.

FIXED.

qt-2004Feb0532-01: [XQuery] MS-XQ-LC1-124
[substantive, decided] 2004-06-13
[XQuery] MS-XQ-LC1-124, Michael Rys (2004-02-16)
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.

qt-2004Feb0520-01: [XQuery] MS-XQ-LC1-112
[substantive, decided] 2004-04-21
[XQuery] MS-XQ-LC1-112, Michael Rys (2004-02-16)
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.

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

DC: else is still required.

Was done at Mandelieu F2F and REJECTED.


            

[[rejected]]

qt-2004Feb0516-01: [XQuery] MS-XQ-LC1-108
[substantive, decided] 2004-08-18
[XQuery] MS-XQ-LC1-108, Michael Rys (2004-02-16)
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]

qt-2004Feb0511-01: [XQuery] MS-XQ-LC1-103
[substantive, decided] 2004-06-09
[XQuery] MS-XQ-LC1-103, Michael Rys (2004-02-16)
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?
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

this has been subsumed by a response to an earlier comment

qt-2004Feb0508-01: [XQuery] MS-XQ-LC1-100
[substantive, decided] 2004-04-21
[XQuery] MS-XQ-LC1-100, Michael Rys (2004-02-16)
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

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.

qt-2004Feb0507-01: [XQuery] MS-XQ-LC1-099
[substantive, decided] 2004-04-21
[XQuery] MS-XQ-LC1-099, Michael Rys (2004-02-16)
Section 3.7.3.5 Computed Processing Instructor Constructor
Technical

Also allow an instance of xdt:untypedAtomic as a name value.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

ADOPTED.


            

ADOPTED.

qt-2004Feb0500-01: [XQuery] MS-XQ-LC1-092
[substantive, decided] 2004-06-02
[XQuery] MS-XQ-LC1-092, Michael Rys (2004-02-16)
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0498-01: [XQuery] MS-XQ-LC1-090
[substantive, decided] 2004-04-22
[XQuery] MS-XQ-LC1-090, Michael Rys (2004-02-16)
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

DC: This sentence has been removed by an action item from Mandelieu to

reword this section.

Comment has been RESOLVED, please check new section.

qt-2004Feb0497-01: [XQuery] MS-XQ-LC1-089
[substantive, decided] 2004-12-02
[XQuery] MS-XQ-LC1-089, Michael Rys (2004-02-16)
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.

qt-2004Feb0495-01: [XQuery] MS-XQ-LC1-087
[substantive, decided] 2004-05-17
[XQuery] MS-XQ-LC1-087, Michael Rys (2004-02-16)
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.
XML Query Teleconference 184 Minutes 2004-05-12, Working Group Minutes (2004-05-12)

            

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.

qt-2004Feb0494-01: [XQuery] MS-XQ-LC1-086
[substantive, decided] 2004-04-05
[XQuery] MS-XQ-LC1-086, Michael Rys (2004-02-16)
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

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.

qt-2004Feb0493-01: [XQuery] MS-XQ-LC1-085
[substantive, decided] 2004-06-02
[XQuery] MS-XQ-LC1-085, Michael Rys (2004-02-16)
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0492-01: [XQuery] MS-XQ-LC1-084
[substantive, decided] 2004-04-05
[XQuery] MS-XQ-LC1-084, Michael Rys (2004-02-16)
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.

qt-2004Feb0491-01: [XQuery] MS-XQ-LC1-083
[substantive, decided] 2004-04-05
[XQuery] MS-XQ-LC1-083, Michael Rys (2004-02-16)
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.
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

>

> Status: See Don's request for review:

> http://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: > http://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.

qt-2004Feb0490-01: [XQuery] MS-XQ-LC1-082
[substantive, decided] 2004-04-05
[XQuery] MS-XQ-LC1-082, Michael Rys (2004-02-16)
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.
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

This has been already REJECTED and publicly announced in

http://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.

qt-2004Feb0471-01: [XQuery] MS-XQ-LC1-063
[substantive, decided] 2004-08-31
[XQuery] MS-XQ-LC1-063, Michael Rys (2004-02-16)
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.

RE: issue list status, Paul Cotton (2004-08-31)

            

The offending text no longer occurs

qt-2004Feb0458-01: [XQuery] 3.1.6 XQuery Comments: placement
[substantive, decided] 2004-05-11
[XQuery] 3.1.6 XQuery Comments: placement, Michael Dyck (2004-02-16)
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]]

qt-2004Feb0455-01: [XQuery] BEA_030
[substantive, decided] 2004-04-05
[XQuery] BEA_030, Daniela Florescu (2004-02-16)
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.

qt-2004Feb0454-01: [XQuery] BEA_029
[substantive, decided] 2004-02-27
[XQuery] BEA_029, Daniela Florescu (2004-02-16)
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.

qt-2004Feb0453-01: [XQuery] BEA_028
[substantive, decided] 2004-08-16
[XQuery] BEA_028, Daniela Florescu (2004-02-16)
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.

qt-2004Feb0448-01: [XQuery] BEA_023
[substantive, decided] 2004-07-27
[XQuery] BEA_023, Daniela Florescu (2004-02-16)
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)
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

See http://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.

qt-2004Feb0446-01: [XQuery] BEA_021
[substantive, decided] 2004-07-27
[XQuery] BEA_021, Daniela Florescu (2004-02-16)
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.
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

qt-2004Feb0418-01: [XQuery] 'local' namespace
[substantive, decided] 2004-08-31
[XQuery] 'local' namespace, Martin Duerst (2004-02-15)
I don't see the need for this 'local' namespace. Why was it introduced?

Regards,    Martin.
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0412-01: [XQuery] document node constructor only way to construct document?
[substantive, decided] 2004-03-29
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.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            


            

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.

qt-2004Feb0411-01: [XQuery] [17] EscapeQuot
[substantive, decided] 2004-05-11
[XQuery] [17] EscapeQuot, Martin Duerst (2004-02-15)
Rule [17], EscapeQuot, should say /* ws: significant */, I guess.


Regards,   Martin.
Proposal accepted.

            


            

[[accepted]]

qt-2004Feb0415-01: [XQuery] I18N last call comments
[substantive, decided] 2004-10-08
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-02: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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]

qt-2004Feb0415-03: [XQuery] I18N last call comments
[substantive, decided] 2004-10-08
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-04: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-05: [XQuery] I18N last call comments
[substantive, decided] 2004-08-16
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-06: [XQuery] I18N last call comments
[substantive, decided] 2004-10-22
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-07: [XQuery] I18N last call comments
[substantive, decided] 2004-10-08
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-08: [XQuery] I18N last call comments
[substantive, decided] 2004-08-31
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.
RE: issue list status, Paul Cotton (2004-08-31)

            

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.

qt-2004Feb0415-09: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-10: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.

qt-2004Feb0415-11: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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

qt-2004Feb0415-12: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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

qt-2004Feb0415-13: [XQuery] I18N last call comments
[substantive, decided] 2004-12-26
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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: http://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. http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Dec/0107.html *** This resolves Issue qt-2004Feb0415-13. LIAM to respond to I18N working group.

qt-2004Feb0415-14: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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 http://www.example.org/collations/fr-ca, and respond to the comment RESOLVED: qt-2004Feb0415-14 accepted

qt-2004Feb0415-15: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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

qt-2004Feb0415-16: [XQuery] I18N last call comments
[substantive, decided] 2004-09-15
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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

qt-2004Feb0415-17: [XQuery] I18N last call comments
[substantive, decided] 2004-10-22
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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).

qt-2004Feb0415-18: [XQuery] I18N last call comments
[substantive, decided] 2004-10-13
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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

qt-2004Feb0415-19: [XQuery] I18N last call comments
[substantive, decided] 2004-08-31
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[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.
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0415-20: [XQuery] I18N last call comments
[substantive, decided] 2004-08-31
[XQuery] I18N last call comments, Martin Duerst (2004-02-15)
[20] The XML version for output seems to be fixed to 1.0. There needs
to be a way to output XML 1.1.
RE: issue list status, Paul Cotton (2004-08-31)

            

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

qt-2004Feb0382-01: [General] Typing issues
[substantive, decided] 2004-03-29
[General] Typing issues, Martin Duerst (2004-02-15)
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.

qt-2004Feb0285-01: [XQuery] 3.7.4 Namespace nodes on constructed elements
[substantive, decided] 2005-01-29
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="http://www.w3.org/1999/xlink"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns="http://www.w3.org/2003/10/issues"
  xmlns:xsi="http://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="http://www.w3.org/1999/xlink"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns="http://www.w3.org/2003/10/issues"
  xmlns:xsi="http://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="http://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 = "http://www.w3.org/2001/XMLSchema",
     "http://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.

qt-2004Feb0222-01: [XQuery] IBM-XQ-015: validate mode: skip preserve
[substantive, decided] 2004-06-02
(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
http://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
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0218-01: [XQuery] IBM-XQ-011: Validation and identity
[substantive, decided] 2004-03-29
[XQuery] IBM-XQ-011: Validation and identity, Don Chamberlin (2004-02-11)
(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
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            


            

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.

qt-2004Feb0216-01: [XQuery] IBM-XQ-009: "xs" namespace should be in-scope
[substantive, decided] 2004-02-27
(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="http://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
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

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.

qt-2004Feb0215-01: [XQuery] IBM-XQ-008: Transitivity of value comparisons
[substantive, decided] 2004-02-27
(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.

qt-2004Feb0213-01: [XQuery] XQ-IBM-006: Context of a function body
[substantive, decided] 2004-07-27
(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
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

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

qt-2004Feb0212-01: [XQuery] IBM-XQ-005: Selective implementation of axes
[substantive, decided] 2004-02-27
(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.

qt-2004Feb0209-01: [XQuery] Create namespace node for xs:QName
[substantive, decided] 2004-06-13
[XQuery] Create namespace node for xs:QName, Jonathan Robie (2004-02-11)
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
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

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


            

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

qt-2004Feb0193-01: [XQuery] A.2.1 White Space Rules
[substantive, decided] 2004-05-11
[XQuery] A.2.1 White Space Rules, Michael Dyck (2004-02-11)
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]]

qt-2004Feb0181-01: [XQuery] Default element namespace and QNames?
[substantive, decided] 2004-08-31
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
RE: issue list status, Paul Cotton (2004-08-31)

            

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.

qt-2004Feb0177-01: [XQuery] Default element namespace and QNames?
[substantive, decided] 2004-08-31
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
RE: issue list status, Paul Cotton (2004-08-31)

            

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.

qt-2004Feb0173-01: Validation in 3.7.3.3 Document Node Constructors
[substantive, decided] 2004-03-29
Section 3.7.3.3 of the XQuery specification says that for
document constructors, "No schema validation is performed on the
constructed document." This seems inconsistent with implicit
validation of elements. Consider the following element
constructor.

<person>
   {
      $that/name,
      $that/address,
      $that/shoesize
   }
</person>

If the person element is in the ISSD, this is validated. Now observe
what happens if this element is placed in a document node.

document
{
  <person>
    {
      $that/name,
      $that/address,
      $that/shoesize
    }
  </person>
}

Under the current language definition, the &lt;person>
element would be validated by its own constructor, and an error
would be raised if validation fails. Then the validated
<person> element would be copied under a new document node and
its type annotation would be changed to xdt:untyped. If element
constructors are implicitly validated, users will expect elements
in document nodes to be valid. Two possibilities seem
reasonable:

1. Copy the content directly to the document node
    constructor, preserving the types of child elements. This is
    simpler, but does not enforce identity
    constraints.

2. Copy the content directly to the document node
    constructor, preserving the types of child elements, then apply
    identity constraints to the document. This adds complexity, but
    ensures that the resulting document is schema valid.

The status quo does not seem reasonable.

Jonathan
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Already resolved in prior meetings.


            

> Status: This comment was identified at the F2F as being related to > the typed value decision. Agreed: this is actually a separate issue. Proposal: Copy the content directly to the document node constructor, preserving the types of child elements. This is simpler, but does not enforce identity constraints. There is no implicit validation for document nodes. Decided: The above proposal is adopted. The issue is resolved via this proposal.

qt-2004Feb0169-01: Static flagger belongs in static context
[substantive, decided] 2004-03-29
Static flagger belongs in static context, Jonathan Robie (2004-02-10)
"2.6.6.1 XQuery Flagger" says: "If the XQuery Flagger is
enabled, a static error [err:XQ0015] is raised if the query
contains a must-understand extension." This implies that the
XQuery Flagger must be available in the static context.

Jonathan

            

Andrew: This doesn't change behavior - it could be treated editorially. It simply asks for a way to record whether the flagger is on in the static context. Proposal: The default predefined value for the XQuery flagger and XQuery static flagger are set by the host environment in an implementation defined way. They may not be augmented by an implementation or in a query. They are available for both static analysis and dynamic evaluation (this is already true). Decided: The above proposal is adopted. The above issue is resolved via this proposal. Note: This is related to Jan0203, which is still open and was discussed in meeting 167.

qt-2004Feb0103-01: [XQuery] 3.2 Order of nodes constructed in a path
[substantive, decided] 2004-06-02
Currently the order of nodes constructed in a path is undefined for
many cases. For example:

let $source := <foo><a>1<a>2</a></a><a>3</a></foo>
return $source/element bar { .//a/element b { text() } }

will return a variation of <bar><b>1</b><b>3</b><b>2</b></bar> with the
"b" elements in an undefined, but stable, order. From 2.3.1 Document
Order: "The relative order of nodes in distinct trees is stable but
implementation-dependent, subject to the following constraint: If any
node in tree T1 is before any node in tree T2, then all nodes in tree
T1 are before all nodes in tree T2."

We feel this is unsatisfactory for embedded node creation; the order of
created elements should be the same across implementations (and runs on
the same implementation). One simple fix is to base the document order
of new nodes in a path on their position. However, this brings up
problems where the position repeats. For example:

let $source :=
<source>
	<foo><a>1<a>2</a></a><a>3</a></foo>
	<foo><a>4<a>5</a></a><a>6</a></foo>
</source>
return $source/element bar { .//a/element b { text() } }

Would end up with nodes 1 and 4 appearing before elements 2 and 5. We
would appreciate any input on this issue.

--Sarah
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Feb0101-01: FW: XML Declaration
[substantive, decided] 2004-03-29
FW: XML Declaration, Ashok Malhotra (2004-02-04)
Forwarding to public comments list.

All the best, Ashok

-----Original Message-----
From: Kien Lee [mailto:kien.lee@rainingdata.com]
Sent: Wednesday, February 04, 2004 10:19 AM
To: Ashok Malhotra
Subject: RE: XML Declaration

Dear Ashok Malhotra,

So, please clarify my understanding:
1. Is it a violation of the spec to put the xml declaration prolog in an
XQuery expression as the example in the original e-mail below ?

2. If it is a violation of the spec, what should an XQuery parser do
when it sees it ?

3. Since the XQuery document constructor is defined as:
[99]    CompDocConstructor    ::=    "document" "{" Expr "}"
and the processing instruction constructor is defined as:
[107]    XmlPI    ::=    "<?" PITarget Char* "?>" /* ws: explicit */
[18]    PITarget    ::=    NCName
Note: this is different from the XML 1.0 spec where processing
instruction can not have the reserved word (('X' | 'x') ('M' | 'm') ('L'
| 'l')) and is defined as:
[16]    PI    ::=    '<?' PITarget (S (Char* - (Char* '?>' Char*)))?
'?>'
[17]    PITarget    ::=    Name - (('X' | 'x') ('M' | 'm') ('L' | 'l'))
So, is it a violation of the spec if I write the following XQuery
expression on an XQuery implementation that does not automatically add
the XML declaration to a document node ?
document
{
 <?xml version='1.0'?>
 <x>
  My Query result
 </x>
}

Many thanks,
Kien

            Proposal: > 1. Is it a violation of the spec to put the xml declaration prolog in an > XQuery expression as the example in the original e-mail below ?

Yes, it should be flagged as an illegal PI by the data model (because
of http://www.w3.org/TR/2000/REC-xml-20001006#dt-pi).  The Data model
spec should make this explicit.  >

2. If it is a violation of the spec, what should an XQuery parser do > when it sees it ?

Adding such a PI to the data model should be flagged as an error.  The
Data model spec should make this explicit.  >

3. Since the XQuery document constructor is defined as:
&lt;snip/> > So, is it a violation of the spec if I write
the following XQuery > expression on an XQuery implementation that
does not automatically add > the XML declaration to a document node
? > document > { > &lt;?xml version='1.0'?> >
&lt;x> > My Query result > &lt;/x> > }

Yes, only because the above is an illegal PI.  Resolved.  Prohibit
this in the DM, and it will be reflected in the "constructor
location".

         
qt-2004Feb0098-01: [XQ] Meaning of substitution groups in element(ElementName,TypeName)
[substantive, decided] 2004-09-29
The following issue was identified during formal definition of
SequenceType matching.  Resolution of this issue is necessary to
complete closure of Issue 559 (New Sequence Type needs to be fully
implemented in Formal Semantics).

Current status:

1. The XQuery type system is based on XML Schema.

2. Section 2.4.4.3 Matching an ElementTest and an Element Node, point 2
   states that:

    a. element(ElementName, TypeName) matches a given element node if
       the name of the element node matches ElementName or matches the
       name of an element in a substitution group headed by an element
       with the name ElementName [if such a head element exists]

   b. type-matches(TypeName, AT) is true, where AT is the type of the
      given element node.

3. To express a sequence type in the XQuery type system, it should
   correspond to some valid XML Schema structure.  In XML Schema
   terminology, the sequence type syntax element(ElementName,TypeName)
   represents a new local element ElementName in the substitution
   group of a global element with the *same* ElementName, and with
   type TypeName.

   In XML Schema, you might express this sequence type as:

     <xs:element name="ElementName" substitutionGroup="ElementName"
type="TypeName"/>

Problem 1:

  XML Schema requires that all members of a substitution group be
  globally declared, therefore the above XML Schema type is invalid
  and thus there is no valid XQuery type expression that represents
  the sequence type element(ElementName, TypeName).

Problem 2:

  Even if we permitted such a type in the XQuery type system, another
  problem arises.

  XML Schema (and hence the XQuery type system) requires the type name
  of a substitution group member to be derived from the type name of
  the head of the substitution group.  This constraint is not enforced
  by sequence-type matching, and therefore it is out of the scope of
  XML Schema and our type system.

  Because the current semantics of element(ElementName, TypeName)
  cannot be expressed in the XQuery type system, any example based on
  it is potentially unsound.  To illustrate, consider the following
  XML Schema structures:

  An element person of type Person:

     define element person of type Person
     define type Person {
       element manager of type xs:string,
     }

   A type Company:

     define type Company {
       element ticker of type xs:string
     }

  and consider the sequence type:

    element(person, Company)

  There is no corresponding XML Schema or XQuery type for this
  sequence type, i.e., the following is invalid, because type Company
  is _not_ derived from type Person:

    <xs:element name="person" substitutionGroup="person"
type="Company"/>

  Consequence: we do not know how to map this sequence type into the
  XQuery type system and therefore cannot provide a static semantics
  for it.

Possible solution 1: enforce the XML Schema's type-derivation
constraint.

Possible solution 2: treat element(person,Company) as the following
local XML Schema element:

  <xs:element name="person" type="Company"/>

which is simple, but excludes substitution groups from the semantics.


--
Mary Fernandez <mff@research.att.com>
AT&T Labs - Research

            

RESOLVED by July WD changes, and internal FS.

qt-2004Feb0085-01: [XQuery] Reference to error XP0050 (editorial)
[substantive, decided] 2004-08-31
[XQuery] Reference to error XP0050 (editorial), Priscilla Walmsley (2004-02-04)
In Section 3.2 on Path Expressions, the XQuery draft says (twice):

"At evaluation time, if the root node above the context node is not a
document node, a dynamic error is raised.[err:XP0050]"

Error XP0050 has to do with the treat expression, so I don't think this is
the right error number.

Thanks,
Priscilla Walmsley

            

We believe that this is the correct error to raise. Jerome will respond to this comment.

RE: issue list status, Paul Cotton (2004-08-31)

            

Don: This error occurs when you do, $x treat as document, or when you do // (which expands to include "treat as"). Resolution is to explain that. Jerome will respond.

qt-2004Feb0007-01: [XQuery ] doc. order of attribute nodes created in element constructor
[substantive, decided] 2004-03-23
L.S.,

Can the implementation of a computed elemement constructor freely choose
the order of the attribute nodes? For example, is the result of

  element { "a" } { attribute { "b" } { "" }, attribute { "c" } { "" } }

always

   <a b="" c=""/>

or can it also be

   <a c="" b=""/>

? I would expect the latter for fundamental (attributes are essentially
unordered) and practical reasons (letting the implementation choose a
certain ordering my sometimes make certain operations more efficient),
but It's not clear to me what the informal and formal semantics exactly
have to say about this.

I already raised a related point before (the document order of the
contents of an element created with a computed element constructor seems
underspecified) but am not sure about the follow-up, so if this has
already been discussed I apologize.

-- Jan Hidders

--
   .-----------.-----------------------------------------------------.
  / Jan Hidders \  Home Page: http://www.win.ua.ac.be/~hidders/       \
 .---------------.-----------------------------------------------------.
 | Post-doctoral researcher               e-mail: jan.hidders@ua.ac.be |
 | Dept. Math. & Computer Science         tel: (+32) 3 265 38 73       |
 | University of Antwerp                  fax: (+32) 3 265 37 77       |
 | Middelheimlaan 1, BE-2020 Antwerpen, BELGIUM     room: G 3.21       |
 `---------------------------------------------------------------------'
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            


            

Andrew: This is covered by the DM spec, 2.4 Document Order, numbered item 4. Don: We should answer with the DM reference.

qt-2004Jan0426-01: [XQuery] Error Handling ?
[substantive, decided] 2004-04-05
[XQuery] Error Handling ?, Xavier Franc (2004-01-31)
This is a badly lacking feature in XQuery:
AFAIK, there is no way to recover/catch a dynamic error after it happens.

Actually, at least two kinds of dynamic errors should be distinguished:
fatal / non-fatal, or non-recoverable / recoverable
(XSLT2 has this distinction).

Clearly there is a semantic difference between:
1)  a wrong regular expression: this is a programming error,
      there is no real point to recover it
2) trying to parse a document is an environment-dependent
    operation, that may fail for unpredictable reasons:
  there isdefinitely a need to recover such an error

Two possible solutions:

1) introduce an error catching mechanism
     -- in my implementation (Qizx/open) I have simply added a
catch-error() function.
    But a more sophisticated mechanism (try/catch) would probably be better.

2) at the very least, consider modifying some functions like doc()
  so that they return a conventional value (eg the empty sequence)
  instead of raising an error
[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

2. File exists.

RESOLUTION: rejected, closed


            

2. File exists. RESOLUTION: rejected, closed


            

PC: Can we close with comment that error handling will be a v2 version. MH: Error handling is very important for our customers MRys: You can add "must-understand" extensions. PC: It's a trade-off between time and functionality. MHK: It's complex, let's leave till next version. Close with negative decision. Jonathan will respond to Xavier. Dissenting vote from MH from Mark Logic Xavier's second comment is related to Liam's comment below. Process with Liam's comment on the F&O agenda. Status: We discussed this matter at the F2F under: > 19. Request for function fn:validatesCorrectly > qt-2004Feb1001-01 and decided to not add either the proposed function or general error handling. At meeting 173 Andrew proposed that he wanted to consider a minimal try/otherwise construct could be considered. Andrew has now informed me that IBM does NOT want to go this direction. I therefore propose that we resolve this comment based on the F2F decision e.g. no try/catch functionality until V2. Related comments: [QT] CER-05 Catching dynamic errors, Mary Holstege

qt-2004Jan0418-01: [XPath] Legal vaues for a satisfies expression in a quantifier?
[substantive, decided] 2004-04-29
Hi Folks,

[If this has already been answered, or this is not the appropriate venue
for the question then please direct me to the  appropriate place.]

In the latest XPath 2.0 spec it defines a quantified expression as
follows:

QuantifiedExpr ::= (("some" "$") | ("every" "$")) VarName "in"
ExprSingle ("," "$" VarName "in" ExprSingle)*
"satisfies" ExprSingle

And ExprSingle is defined as follows:

 ExprSingle ::= ForExpr
              | QuantifiedExpr
              | IfExpr
              | OrExpr

I do not believe that this is correct.  Here is one of the examples that
is given in the discussion on quantified
expressions:

every $part in //part satisfies $part/@discounted

The satisfies expression in the example is: $part/@discounted

Clearly, it is neither a ForExpr, a QuantifiedExpr, an IfExpr, nor an
OrExpr.

In fact, wherever SingleExpr appears in the quantified expression it
makes no sense.

Can someone provide the correct BNF for the quantified expression?
/Roger

            

Hi Roger. I may be misunderstanding your question, but I think the answer is that OrExpr recurses down PathExpr. You can follow the recursion basically by clicking on the first member of the right hand side of the BNF productions. This particular cascade is what implements the built-in precedence. Anyway, I believe the BNF to be correct, and the structure, dumped from the diagnostics of the test parser, is: |XPath | Expr | QuantifiedExpr | Every every $ | VarName part | In in | PathExpr | RootDescendants // | StepExpr | NodeTest | NameTest | QName part | Satisfies satisfies | PathExpr | VarName part | StepExpr | At @ | NodeTest | NameTest | QName discounted Note that the test parser reduces many of the unneeded steps, for instance for ExprSingle to PathExpr, as I think you would for most ASTs. -scott


            

Hi Scott, Hmm, I am not sure where you are getting that expansion - where does it say the value of a quantifier's satisfies expression is a "PathExpr"? I am looking at section 3.9 of the latest XPath 2.0 spec and it says that the value of a quantifier's satisfies expression is "ExprSingle", not "PathExpr", i.e., QuantifiedExpr ::= (("some" "$") | ("every" "$")) VarName "in" ExprSingle ("," "$" VarName "in" ExprSingle)* "satisfies" ExprSingle Note the use of "ExprSingle" in three places. That said, PathExpr makes good sense. So, I believe that section 3.9 needs to be corrected to: QuantifiedExpr ::= (("some" "$") | ("every" "$")) VarName "in" PathExpr ("," "$" VarName "in" PathExpr)* "satisfies" PathExpr Agree? /Roger


            

I think you want to bind ors inside the satisfy clause. I agree with Scott that the current grammar seems to give the right precedence... A PathExpr is also a ExprSingle. Best regards Michael


            

To try and amplify Scott's response, note that OrExpr is an expression that *might* contain an "or" operator, not an expression that *must* contain an "or" operator. To simplify the grammar, when you have a series of rules such as: OrExpr ::= AndExpr ("or" AndExpr)* AndExpr ::= ArithExpr (("+"|"-") ArithExpr)* ArithExpr ::= PathExpr then every PathExpr is an ArithExpr, and every ArithExpr is an AndExpr, and every AndExpr is an OrExpr, and therefore you can use a PathExpr everywhere an OrExpr is allowed, which means you can use it in the "satisfies" clause of a quantified expression. Michael Kay

qt-2004Jan0379-01: XQuery media type
[substantive, decided] 2004-10-13
XQuery media type, Mark Baker (2004-01-26)
Hi,

I was surprised when I looked in the XQuery specification for a media
type definition, but couldn't find one.  I believe XQuery should have
its own.  FWIW, there's a TAG finding that seems to recommend it too;

"W3C Working Groups engaged in defining a language SHOULD arrange for
the registration of an Internet Media Type (defined in RFC 2046
[RFC2046]) for that language"
 -- http://www.w3.org/2001/tag/2002/0129-mime#registration

Thanks!

Mark.
--
Mark Baker.   Ottawa, Ontario, CANADA.        http://www.markbaker.ca

            

We now have an appendix about application/xquery. RESOLVED: qt-2004Jan0379-01 closed Liam will reply (see ACTION A-216-09 above) [done]

qt-2004Jan0360-01: [XQuery] Missing S in XmlPI rule
[substantive, decided] 2004-09-07
[XQuery] Missing S in XmlPI rule, scott_boag@us.ibm.com (2004-01-26)
There seems to be a missing S between PITarget and Char* in the rule for
XmlPI in the spec:

Current rule:
XmlPI    ::=    "<?" PITarget  Char* "?>"

Should be:
XmlPI    ::=    "<?" PITarget  (S  Char*)? "?>"

-scott
Re: [XQuery] Missing S in XmlPI rule, Scott Boag (2004-04-26)

            

Hi Scott. Your last call comment in [1] has been given the ID qt-2004Jan0360-01. This is the official response from the XQuery and XSLT working groups. Your issue pertaining to the error in the XmlPI has been accepted, and the WGs have approved the fix you suggested. The production will read: [110] XmlPI ::= "<?" PITarget (S Char*)? "?>" /* ws: explicit */ (Since I am writing this to myself, this mail should also provide the confirmation that this fix is satisfactory!) -Scott Boag [1] http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0360.html

			
            

SB said he believes this item should be closed. DECIDED: to confirm the decision to follow the XML syntax for XmlPI slavishly. RESOLVED: qt-2004Jan0360-01 has been resolved by our decision to follow the XML syntax for PIs.

qt-2004Jan0342-01: [XQuery] Inconsistent syntax for variable declarations
[substantive, decided] 2004-07-27
I am raising this comment because I have seen several XQuery users make
mistakes as a result of the syntactic inconsistency between global
variable declarations and local variables, and there seems to be no good
reason why they are so different.

For global variables we write:

   declare variable $x [as xs:integer] {3};

while for local variables we write:

   let $x [as xs:integer] := 3

I suggest changing the global variable syntax to:

   declare variable $x [as xs:integer] := 3;

An external variable would be:

   declare variable $x [as xs:integer] external;

Michael Kay
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

([XQuery] Inconsistent syntax for variable declarations) Approved

qt-2004Jan0340-01: [XQuery] Lexical rules for comment, pi, cdata
[substantive, decided] 2004-03-29
In section A.2.2 Lexical Rules, "<!--", "<?" and "<![CDATA[" go to
XML_COMMENT, PROCESSING_INSTRUCTION, and CDATA_SECTION respectively
with pushState(). The direct element constructor "<" goes to START_TAG
with pushState(OPERATOR)

Since the OPERATOR state is not pushed for comments, pis, and cdata,
the following is illegal:
let $a := <!-- foo -->
return $a

whereas
let $a := (<!-- foo -->)
behaves correctly.

We suggest changing "<!--", "<?", and "<![CDATA" to push the OPERATOR
state so the parentheses are not necessary.

--Sarah

            

Response Given: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0365.html

qt-2004Jan0243-01: [XQuery] A.2.2 Lexical Rules: bad transitions
[substantive, decided] 2004-03-29
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.2.2 Lexical Rules

Some of the lexical states have incorrect transitions, causing the lexer
to reject valid queries.

Specifically:

------------------------------------------------------------------------
Query:   <!---- blah ----> | e
Query:   <?PITarget ?> | e
Query:   <![CDATA[x]]> | e

Problem: In each case, after the ">", the lexer is in DEFAULT, which
         doesn't recognize "|" (or any other operator).

Fix:     In DEFAULT, for the transitions on "<!----", "<?", and
         "<![CDATA[", change "pushState()" to "pushState(OPERATOR)".

Note: I reported this on November 28, 2002 (three versions ago), in
http://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0105.html

------------------------------------------------------------------------

Query:   <Q> { typeswitch (e) case e return e default return e } </Q>

Problem: After the "}", the lexer is in OPERATOR, which doesn't
         recognize "</".

Fix:     In DEFAULT, the transition for <"typeswitch" "("> should not
         involve "pushState(OPERATOR)".

------------------------------------------------------------------------

Query:   processing-instruction {x} {x}

Problem: Accepting the last "}" causes popState() on an empty stack.

Fix:     In OPERATOR, the transition for "{" needs "pushState()".

------------------------------------------------------------------------

Query:   declare variable $x as processing-instruction()? external; e

Problem: After the ")", the lexer is in OPERATOR, which doesn't
         recognize "?".

Fix:     In ITEMTYPE, the transition for <"processing-instruction" "(">
         should change "pushState(OPERATOR)" to
         "pushState(OCCURRENCEINDICATOR)".

------------------------------------------------------------------------

Query:   declare variable $x  external; e
Query:   declare function Q() external; e

Problem: These leave DEFAULT on the stack. It's not clear whether this
         means that the lexer should reject them, but even if not, it's
         still bad form: a lexer with a maximum stack size would be much
         more likely to hit its limit.

Fix:     In DEFAULT, for the transitions on <"declare" "variable" "$">
         and <"declare" "function">, don't "pushState(DEFAULT)".

------------------------------------------------------------------------

-Michael Dyck

            

Response Given: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0364.html

qt-2004Jan0242-01: [XQuery] A.2.2 Lexical Rules: erroneous patterns
[substantive, decided] 2004-03-29
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.2.2 Lexical Rules

Many states have transitions on patterns that aren't valid for that
state. That is, for a query to put the lexer in the given state
with the remaining input matching the given pattern, the query
would have to have a syntax error.  By accepting the erroneous
pattern, the lexer delays detection of the syntax error.

Specifically, I believe the following patterns are erroneous in
the given states.

DEFAULT
    "]"
    ","
    "["

OPERATOR
    <"declare"_"function">
    <"at"_StringLiteral>
    "global"
    "("
    <"validate"_"{">
    <"typeswitch"_"(">
    <"declare"_"default"_"collation">
    <"import"_"schema">
    <"import"_"module">
    <"declare"_"default"_"element">
    <"declare"_"default"_"function">
    <"declare"_"namespace">
    <"declare"_"base-uri">
    <"declare"_"xmlspace">
    <"some"_"$">
    <"every"_"$">
    IntegerLiteral
    DecimalLiteral
    DoubleLiteral
    QName
    <NCName_":"_"*">
    <"*"_":"_NCName>
    "."
    ".."

NAMESPACEKEYWORD
    <"at"_StringLiteral>
    <"declare"_"default"_"element">
    <"declare"_"default"_"function">

KINDTEST
    "@"
    StringLiteral

SCHEMACONTEXTSTEP
    "@"

START_TAG
    "{"

END_TAG
    "{"

-Michael Dyck

            

Response Given: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0363.html

qt-2004Jan0241-01: [XQuery] A.2.2 Lexical Rules: pattern conflicts
[substantive, decided] 2004-03-29
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.2.2 Lexical Rules

In some of the states, there are conflicts between some of the patterns,
i.e. cases in which the input could match more than one pattern.

Specifically:

OPERATOR:
conflict between QName and all the single-keyword patterns
(e.g., "external", "skip", "default").
(Luckily, this appears to have an easy fix: simply delete QName
from the state: I don't think it's valid here.)

KINDTEST:
conflict between QName and the keywords "context" & "global".

EXPR_COMMENT:
conflict between ExprCommentContent, PragmaContents,
and ExtensionContents.
(Fix: They're all defined to be Char, so you could just replace them
with Char in the EBNF and here.)

EXT_KEY:
conflict between QName and the keywords "pragma" & "extension".

-Michael Dyck

            

Response Given: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0362.html

qt-2004Jan0238-01: [XQuery] Early Lall Call comment on Prolog syntax
[substantive, decided] 2004-03-29
I posted a comment to the XQuery WG last year that was moved to become a
last call. The mail is located at
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0046.html



I was asked to forward it to the public list, so here is the content of
the mail for public archiving and replies:



This mail proposes an improvement to the query prolog syntax to address
the ordering issues that several of my implementers have raised and that
I have reported previously. Currently the grammar allows a function
declaration before the default collation declaration, and a schema
import can syntactically occur after a function declaration that refers
to the type name imported. Since this arbitrary ordering complicates the
prolog processing and the specification of such, we would like to
propose a certain order in the prolog. We first have the version, then a
group of context setters, then a group of namespace declarations and
imports and then the variable and function declarations.

I propose two syntactic varieties that distinguish for variable and
function declarations and present the choice between two semantic
varieties for the variable reference case. Note that I assume that we
continue to allow a function declaration to refer to a function that is
syntactically declared later at the same module level.

Syntax A:
=========

Prolog ::= (Version Separator)?
           (Setter Separator)*
           (Decl Separator)*
           (VarDecl Separator)*
           (FunctionDecl Separator)*

Setter ::= XMLSpaceDecl     ; each setter occurs at most once
         | DefaultCollationDecl
         | BaseURIDecl
         | ValidationDecl

Decl   ::= NamespaceDecl    ; each decl appears any number of times
         | DefaultNamespaceDecl
         | SchemaImport
         | ModuleImport

Syntax B:
=========

Prolog ::= (Version Separator)?
           (Setter Separator)*
           (Decl Separator)*
           (VFDecl Separator)*

Setter ::= XMLSpaceDecl     ; each setter occurs at most once
         | DefaultCollationDecl
         | BaseURIDecl
         | ValidationDecl

Decl   ::= NamespaceDecl    ; each decl appears any number of times
         | DefaultNamespaceDecl
         | SchemaImport
         | ModuleImport

VFDecl ::= VarDecl | FunctionDecl

Semantic Interpretation I:
--------------------------

Example 1:

declare variable $a as xs:integer { $b + 42 }
declare variable $b as xs:integer { 0 }

Example 2 (only for Syntax B):

declare function foo($x as xs:integer) as xs:integer {
  $x + $const
}
declare variable $const as xs:integer

Both examples work without error.

Semantic Interpretation II:
---------------------------
Neither of the two examples works. The declaration of $a in Example 1
would raise an error about not having $b declared yet, and the function
body in example 2 would raise an error that the $const has not been
declared yet.

Which would you prefer?
A.I., A.II., B.I., or B.II?

We have a slight preference of A over B and interpretation II over I,
but can live with the others.

Best regards
Michael

            

Response Given: http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0239.html

qt-2004Jan0207-01: [XQuery] MS-XQ-LC1-051
[substantive, decided] 2004-02-13
[XQuery] MS-XQ-LC1-051, Michael Rys (2004-01-20)
Section 3.1.1 Literals
Technical

XQuery String literal should not recognize any entities as part of the
human-readable syntax. Requiring support will make parsing and
user-understanding of strings like "H&M" way too complex.

            

Resolved, this is rejected.


            

DonC: There are use cases for this in the language document, e.g. Euro character. MRys: No, that depends on input tool. Q: DonC's example is a character reference; comment only speaks to entities. A: Believe that is an oversight. Dana: Don't believe we should distinguish this from character reference issue. Limits XQuery to devices where you can enter Unicode, which I don't think this is a good idea. If we support character reference resolving, suggest we support both. Don: Worried about cases where content of string contains both kinds of string. Don't I need character references for one of them? A: No, can double them. MH: Agree Dana. MKay: Something to be said for proposal, but uneasy about it. In part because we don't say, for example, that query is Unicode. Say nothing about encoding. Have to take them both entity and character references together. Don't get benefit of writing freestanding ampersand unless you get rid of both or use context-dependent parsing or escaping mechanism. But would be happier handling Unicode problem through context-free preparse of string the way Java does. No support for the proposal. We have no statement about what encoding queries are in, and if encoding is not Unicode, we need a way to ensure that regardless of the context there should be a way to input the Unicode characters. Given you need & for the character references anyway, seems appropriate to have the same rules as in literal element content and have the predefined entities as well. DonC to respond. We decline to make the change.

qt-2004Jan0206-01: [XQuery] MS-XQ-LC1-050
[substantive, decided] 2004-11-13
[XQuery] MS-XQ-LC1-050, Michael Rys (2004-01-20)
Sections 2.6.6.1/2.6.7.1
Technical

Why are the Flaggers mandated when providing extensions? This is
basically a parser option and should be left to the implementation. I
can always run somebody else's query that contains pragma since I can
ignore them (as can other implementations) and other implementations
will always flag extensions anyway. This seems to make the flagger only
an implementation nuisance.
			
            

Flagger are no longer mandated, solved by removing flaggers.

qt-2004Jan0204-01: [XQuery] MS-XQ-LC1-048
[substantive, decided] 2004-11-13
[XQuery] MS-XQ-LC1-048, Michael Rys (2004-01-20)
Section 2.6.5/6
Technical

Please add a specification of the scoping of the pragma/extension
(implementation-defined? Within a FOR?). We would prefer to have the
scoping implementation-defined on a per pragma/extension basis.
			
            

MR: the new scoping of the syntax makes it much clearer.

qt-2004Jan0208-01: [XQuery] MS-XQ-LC1-047
[substantive, decided] 2004-11-13
[XQuery] MS-XQ-LC1-047, Michael Rys (2004-01-20)
Sections 2.6.5/6
Technical

Do not mandate the QName in a pragma/extension, but allow it (make
pragma content+). Do not require it to be a unique identifier. For
example, I may want to use the same pragma QName for all my pragmas to
indicate the product and use sub content to indicate other information.
			
            

MR: the new method makes more sense.

qt-2004Jan0203-01: [XQuery] MS-XQ-LC1-046
[substantive, decided] 2004-11-13
[XQuery] MS-XQ-LC1-046, Michael Rys (2004-01-20)
Sections 2.6.5/6
Technical

Provide static contexts for pragma/extension information
			
            

MR: now we have options I think it's clearer PC, LQ, MH: they're implementation defined, so we don't need to say this [the impl'n can do what it wants with the options, including this]

qt-2004Jan0200-01: [XQuery] MS-XQ-LC1-045
[substantive, decided] 2004-10-13
[XQuery] MS-XQ-LC1-045, Michael Rys (2004-01-20)
Section 2.6.3 Full Axis Feature
Editorial

Please reword: "(however, XQuery does not recognize the namespace axis
defined by XPath)." to "Note: XQuery does not recognize the namespace
axis defined by XPath 2.0."

            

DECISION: To leave to the editor, who advised us that he rejects the proposed change RESOLVED: qt-2004Jan0200-01 closed, rejected editorially

qt-2004Jan0199-01: [XQuery] MS-XQ-LC1-043
[substantive, decided] 2004-12-02
[XQuery] MS-XQ-LC1-043, Michael Rys (2004-01-20)
Section 2.6.1 Schema Import Feature
Editorial/Conformance

We would like to be able to do implicit schema imports (based on
externally associated schemata) while not supporting the import syntax.
We would like to have this option acknowledge here (it seems to be
possible based on implementation-defined ISSD). We propose adding the
following note:

Note: An implementation may provide implicit schema import by
initializing the static in-scope schema definitions with externally
provided schema information, even if the schema import feature is not
provided.
			
            

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

qt-2004Jan0198-01: [XQuery] MS-XQ-LC1-042
[substantive, decided] 2004-02-13
[XQuery] MS-XQ-LC1-042, Michael Rys (2004-01-20)
Section 2.5. Error Handling
Technical

Please add a sentence of the form "If an implementation can determine
during analysis phase that an expression is always raising a dynamic or
type error (if static typing option is not used), that error can be
reported during the analysis phase".

            

DonC: Text exists in 2.5.1 "Kinds of Errors" MKay: Text as quoted is not sufficient; doesn't cover cases where you can just infer error. DonC: We considered that and issue of what if this was in an else branch; if you don't know it is executed you don't want to raise the error. We therefore came to the existing working. Amended: "If an implementation can determine during analysis phase that an expression is always raising a type error (if static typing option is not used), that error can be reported during the analysis phase" Adopted. DonC to respond.

qt-2004Jan0189-01: [XQuery] MS-XQ-LC1-032
[substantive, decided] 2004-02-13
[XQuery] MS-XQ-LC1-032, Michael Rys (2004-01-20)
Section 2.4.2 Typed Value and String Value
Technical

"If the type annotation denotes a complex type with element-only
content, then the typed value of the node is undefined.": The data model
already makes this case an error. Please align the specs.

            

WG believes specs are aligned. First sentence is simply an explanation of why data model would return error for dm:typed-value, which reflected at language level by call to fn:data raising a type error. No change. ACTION: DonC will send response.

qt-2004Jan0186-01: [XQuery] MS-XQ-LC1-029
[substantive, decided] 2004-02-09
[XQuery] MS-XQ-LC1-029, Michael Rys (2004-01-20)
Section 2.4.2 Typed Value and String Value
Editorial/Technical

Remove references to "namespace nodes" since they are not exposed in
XQuery.
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

Subsumed by qt-2004Feb0207-01


            

>> Don has no problem making the change in this section, but will be references to namespaces nodes in many other places in the document. >> Michael Kay: the statement as written is true, but doesn't hurt to remove it here, as is defined in the data model anyway. >> This section doesn't talk about getting the value of a namespace node, just asserts that it has one. >> Michael R: his comment was only on this specific part of the document, and doesn't make sense to talk about getting the string value of something we can't reach. >> Don: This section just recapitulates what the DM says. >> Paul: DM section 5.5, last call Nov 5. Link takes him to E.5. >> Michael: in XQuery, is on way to get the value of a namespace node, because we can't get access to the node. >> But in XPath we can. But since this is an XQuery document, we shouldn't refer to things you can't reach. >> Don: We could name namespace XPath only in this paragraph... >> I'm neutral. >> Anyone disagree or can't live with Michael's change? >> Paul: instead, add a note that indicates that because ns axis is not accessible in XQuery... >> Don: would make it a rule not a note. >> ACCEPTED, but instead of the proposal, we will add text to XQuery to explain the non-accessiblity of namespace ndoes. Don to make the change and reply to the public comment.

qt-2004Jan0184-01: [XQuery] MS-XQ-LC1-027
[substantive, decided] 2004-06-02
[XQuery] MS-XQ-LC1-027, Michael Rys (2004-01-20)
Section 2.4.1 Predefined Types
Technical

"xdt:untypedAny is .." See problem raised in MS-DM-LC2-038 (see
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0098.html
). xdt:untypedAny should only cover the untyped not and skip validated
cases.
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

Already resolved in prior meetings.

qt-2004Jan0175-01: [XQuery] MS-XQ-LC1-018
[substantive, decided] 2004-08-31
[XQuery] MS-XQ-LC1-018, Michael Rys (2004-01-20)
Section 2.2.5 Consistency Constraints
Editorial/Technical

"For every data model node that has a type annotation other than
xs:anyType" add both untyped types or just assume that all types are
always in the ISSD (xs:anyType, xdt:untyped etc) and do not special case
these types.
RE: issue list status, Paul Cotton (2004-08-31)

            

This has been fixed in the document

qt-2004Jan0169-01: [XQuery] IBM-XQ-002 - Metadata
[substantive, decided] 2004-08-31
[XQuery] IBM-XQ-002 - Metadata, Andrew Eisenberg (2004-01-20)
XQuery currently lacks a mechanism to return metadata describing the
persistent objects of interest to its users. While this capability could
be added to each of the APIs that are designed for XQuery, we suggest that
it would be better for XQuery to provide this metadata.

SQL defines the Information Schema tables that reflect its metadata. While
these tables were provided in SQL-92, they have not been widely
implemented. By the time that they were published, vendors had already
started defining their own tables and API methods to make this type of
information available.



XQuery users can make reference to a number of objects in their queries.
The following table shows each of these objects and describes which
constructs allow their use.

XQuery object
clause that allows the use of this object
schema
Schema Import in prolog
module
Module Import in prolog
collation
Default Collation Declaration in prolog
OrderModifier in OrderBy Clause
functions such as fn:contains
collection
fn:collection
document
fn:doc


XQuery metadata might be provided by a function, fn:metadata. This
function would return the descriptions of schemas, modules, collations,
collections, and documents that are accessible to the issuer of the query.
A schema would be provided to describe the document or element produced by
this function. Implementations could provide additional metadata by
extending the types defined by this schema.

An application might request the entire metadata document, or it might
operate on it with XQuery to return only part of this metadata.

We recognize that some XQuery implementations are "closed world", with all
objects of these types registered in a repository of some sort, while
others are "open world", attempting to resolve URI's across the world wide
web. We suggest that the objects described by fn:metadata be defined to
return a subset, possibly an empty subset, of the objects that can be used
in a query. An open world implementation might return no object
descriptions at all.

A user might issue the following query:

        for $c in fn:metadata()//xqm:collection
        return fn:data($c/xqm:collection-uri)

This query might return the following:

        http://www.example.com/xqdb1/employees
        http://www.example.com/xqdb1/divisions
        http://www.example.com/xqdb2/capital-assets
        .
        .
        .


                                                        -- Andrew

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

andrew.eisenberg@us.ibm.com
Phone: 978-399-5158    Fax: 978-399-5117
RE: issue list status, Paul Cotton (2004-08-31)

            

Metadata is difficult. Jim: it's needed for just about any query that's going to be generated dynamically We learned that the hard way with static SQL. If we don't provide it in XQuery, a lot of designers of the environments in which it's used will have to provide it. JR: what are the use cases? Andrew: IBM thinks it's necessary. We have a number of statements, e.g. import schemas, documents, open collections, and there's no way to discover those. MR: SQL 1 didn't have this. Liam: we would need liaison with external goups, e.g. RDF WG, and that could take a long time. Jim: I don't think it would be that hard to come up with a small set of metadata that we believe is urgently required. By the time we got to SQL 92, vendors had all invented incompatible mechanisms. JR: a lot of queries that need metadata in SQL, you can get them through element and attribute names in XQuery. We've taken a bunch of use cases in this area and solved them. The functionaliy is important and should be done right. Andrew: Imagine you're in a GUI writing a query, you want a pull-down list of available schemas and modules. PaulC: I hear Oracle and IBM saying V1; Michael and Data Direct and Liam say not in V1, I haven't heard Mary Mary: also not in V2, there are parts of this proposal that would be [hard or impossible to implement], I'm sympathetic to the proposal but I want to sit down and discuss it. PaulC: not enough consensus for V1, so we have to reject the comment in order to meet our schedule. Jim: in the XSLT world there's esxlt; those of us interested in doing something like this would like an efn by analogy.

qt-2004Jan0162-01: [XQuery] MS-XQ-LC1-017
[substantive, decided] 2004-02-09
[XQuery] MS-XQ-LC1-017, Michael Rys (2004-01-20)
Section 2.2.3.2 Dynamic Analysis Phase
Editorial/Technical

"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 is too strong. If I know for sure
that I always will have a dynamic type error (e.g., the expected type is
xs:string and the passed value is always an instance of xs:int, I should
be able to raise this type error during the static phase even if the
static typing feature is not employed).

            

[implementations] are allowed to detect errors early, so why should the implementation be forced to go through the dynamic evaluation phase? The problem is "must proceed with the dynamic evaluation phase". Replacing "must" with "may" is the intent. Principles: 1. If you raise a type-related warning, you do not need to proceed with dynamic eval phase. 2. If you do proceed with dynamic evaluation phase after type-related warnings have been raised, you need to raise type-related errors. ACCEPTED, Don to make the change and reply to the public comment.

qt-2004Jan0160-01: [XQuery] MS-XQ-LC1-015
[substantive, decided] 2004-02-09
[XQuery] MS-XQ-LC1-015, Michael Rys (2004-01-20)
Section 2.2.3.1 Static Analysis Phase
Technical

"During the static analysis phase, 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.": We also need to exempt fn:data(())
which is used by atomization since we atomize () in an expression such
as foo(()).

            

>> Paul: Is making sure the sentence is exactly correct. >> Don: already done. >> ACCEPTED, Don to reply to the public comment.

qt-2004Jan0154-01: [XQuery] MS-XQ-LC1-009
[substantive, decided] 2004-07-27
[XQuery] MS-XQ-LC1-009, Michael Rys (2004-01-20)
Section 2.1.1 Static Context
Editorial

How does module import affect the static context items?
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

subsumed under f2f 13A: > a) Consistency rules for static context components, Don C > http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jun/0108.html (1) delete the sentence from C.1 --> adopted (2) three new cases a) binding to the same namespace prefix more than once --> adopted, a static error b) user tries to bind the same variable name more than once --> withdrawn, see discussion below, with clarifications as listed below c) xmlspace declared more than once in the prolog --> adopted, a static error Discussion of (b) by examples: 1: for $i in $this, $i in $that return $i 2: for $i in $this, $i in that($i) return $i 3: for $i in $this return for $i in $that($i) return $i 4: for $i in $this return for $i in $that return $i Looking at "The scope of a variable", Don deduced (1) isn't an error. Agreement that (4) is legal. Agreement that (4) is the same as (1), although Michael Rys produced 5: for $i in $that return for $i in $this return $i and claimed that (1) mapped to both (4) and (5). Jonathan and MichaelR both wanted the introductory text in section 3.9 FLWOR Expressions under "The scope of a variable" should probably read "the lexical scope of a variable", and it would help if the example 1 was shown to be the same as 5, because the second $i occludes the first declarations. Don will try to clarify the document, although not necessarily adding this example. adopted.

qt-2004Jan0149-01: [XQuery] MS-XQ-LC1-004
[substantive, decided] 2004-08-31
[XQuery] MS-XQ-LC1-004, Michael Rys (2004-01-20)
Section 2 Basics
Technical

For XPath 1.0 backwards compatibility, the string value of a node should
be of type xdt:untypedAtomic.
RE: issue list status, Paul Cotton (2004-08-31)

            

MR: For Query, want string() of a node always to return untypedAtomic. No support in the WG.

qt-2004Jan0093-01: [Xquery] Comment constructors
[substantive, decided] 2004-01-123
[Xquery] Comment constructors, David Carlisle (2004-01-19)
Neither form of comment constructor gives any indication of what is to
happen if (after atomization/casting) the string contains the sequence "--"
or ends in "-" neither of which are allowed in an XML comment.

3.7.2 Other Direct Constructors
3.7.3.6 Computed Comment Constructors


<!-- abc -- xyz -->

comment { "-123-"}

Both appear to be legal Xquery, but neither can directly result in an
XML comment and the first can not result in an XPath/Xquery data model
comment node:
http://www.w3.org/TR/xpath-datamodel/#CommentNode
somewhat strangely only bans "--" but allows a trailing "-".

By contrast, the xslt2 draft says,

http://www.w3.org/TR/xslt20/#creating-comments

[ERR XT0950] It is a recoverable dynamic error if the result of
evaluating the content of the xsl:comment contains the string -- or ends
with -. The optional recovery action is to insert a space after any
occurrence of - that is followed by another - or that ends the comment.


David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

            

See [448]. duplicate of qt-2004Feb0636-01, -- in comments. RESOLUTION: closed

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

duplicate of 36, -- in comments. RESOLUTION: closed


            

Do we want this to be an error, or do like XSLT2 that makes this recoverable? [people agree to go the XSLT2 way, making this recoverable] Don will fix this, and PaulC will reply to this public comment.

qt-2004Jan0084-01: [XQuery] Semantics of validation context
[substantive, decided] 2004-06-02
[XQuery] Semantics of validation context, Kay, Michael (2004-01-16)
I am having trouble understanding the meaning of the validation context
which may be specified in a validate expression (and equally, the
implicit validation context used when validating element constructors)

This seems to be specified largely by example. One of the examples is:

Suppose that $x is bound to a shipTo element. Then validate strict
context po:purchaseOrder {$x} validates the value of $x in strict mode,
in the context of the top-level element declaration po:purchaseOrder.

So what happens if the element declaration po:purchaseOrder has the
content model:

<xs:sequence>
 <xs:any namespace="##any" processContents="skip">
</xs:sequence>

Is the shipTo element valid here? I would hope that it is, because the
schema says it is allowed as a child of purchaseOrder, and it seems
wrong that we should be able to create a structure that fails validation
even though it conforms to the schema. But the specification suggests
otherwise: "strict requires that each element to be validated must be
present in the in-scope element declarations,...".

So, perhaps there is a global element declaration for shipTo. Does this
affect the outcome? Am I allowed to use the global element declaration,
even though the context path for validation specifies some local
declaration? It would be very strange if this were the case, but that's
what the text seems to suggest.

But now read it again. The "in-scope element declarations" does not
contain elements, it contains element declarations. What does it mean
for "the element to be validated" to be "present in the in-scope element
declarations"? Section 2.1.1.1 says "Each element declaration is
identified either by a QName (for a top-level element declaration) or by
an implementation-dependent element identifier (for a local element
declaration)". But the section on validation seems to be assuming
otherwise: it seems to assume that an element declaration is identified
not by a QName, but by some kind of path. Of course an element
declaration that's contained in a group, or that's referred to be an
<xs:element ref="xx"> can be reached by many different paths (an
infinite number of paths). Are these paths allowed to contain wildcards
or not?

I'll stop there. Perhaps this is all clarified in the formal semantics?

XSLT 2.0, incidentally, avoids these problems. It does not allow
validation against anything other than a global element declaration or a
global type.

Michael Kay
[VER 2] XML Query Teleconference 190 Minutes 2004-06-02, Working Group Minutes (2004-06-02)

            

qt-2004Jan0083-01: [XQuery] Namespace for library modules
[substantive, decided] 2004-07-27
[XQuery] Namespace for library modules, Kay, Michael (2004-01-16)
On an internal list, I raised the following comment:

http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0020.html

<quote>
In section 4.2 of the XQuery language book we say:

The names of all variables and functions declared in a library module
must
be explicitly qualified by the target namespace prefix.[err:XQ0048]

This must be the only place we mandate the use of a specific prefix, as
distinct from a specific URI. Was it intentional? It seems very much
contrary to the intent of QNames and namespaces.

I suggest that this should say:

"The name of every variable and function declared in a library module
must
have a namespace URI that is the same as the target
namespace.[err:XQ0048]"

Practical use case: you might want to cut and paste a set of functions
from
one module into another. Rather than changing the old prefix everywhere
it
appears, you would expect to be able to declare the old prefix to map
onto
the new URI.
</quote>

The WG discussed this comment at a telcon on 2003-12-17 and agreed with
the suggested text. To ensure public visibility, I was given the action
(XQUERY-162-05) to raise this as a public comment.

Michael Kay
Final version of the MIT face to face minutes, Massimo Marchiori (2004-07-27)

            

"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

qt-2004Jan0081-01: [XQuery] Uniqueness of module namespaces
[substantive, decided] 2004-01-123
[XQuery] Uniqueness of module namespaces, Kay, Michael (2004-01-16)
On an internal list, I raised the following comment:

http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Nov/0019.html

"There appears to be no explicit rule stating that the module namespace
of an
imported module must differ from the module namespace of the importing
module. Clearly such a rule was intended."

The Query WG discussed this on 2003-12-17, and agreed the change in
principle; to ensure public visibility I was given the action
(XQUERY-162-04) to raise the matter on the public comments list.

More recently, Per Bothner has raised the same question in a rather more
generalized form:

http://lists.w3.org/Archives/Public/public-qt-comments/2003Dec/0288.html

See Last Call issue reference qt-2003Dec0288-01

The WG discussed Per's comment at a telcon on 2004-01-14 and scheduled
further discussion at the face-to-face next week. I imagine this
discussion is likely to revisit the 2003-12-17 decision.

Michael Kay

            

c) [XQuery] Uniqueness of module namespaces, Michael Kay http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0081.html Status: We need to finalize our position since MK implies that we might re-consider our position. In the second part of the text, referring to Per's comment, MikeK seems to imply that we might change our mind. So, PaulC will send a message that we will not revisit this issue.

qt-2004Jan0056-01: [XQuery] Path expressions and axis features
[substantive, decided] 2004-01-123
[XQuery] Path expressions and axis features, Thorsten Trippel (2004-01-15)
Reading the working draft (W3C Working Draft 12 November 2003) and
testing some XQuery tools left the impression that the axis features are
sort of neglected by leaving features optional, which is not acceptable.

The introduction of the Full Axis Feature (section 2.6.3) open a way for
implementers to claim XQuery conformity without supporting certain axis
such as the sibling and ancestor axes.
These might not be relevant in unordered databases such as address
tables, where sorting takes place, if required, after querying; but XML
data provides an essential component namely the preservation of the
order.

Annotation formats for speech for example rely on rather flat XML trees
that maintain the linear order of speech. These annotations clearly show
a data centered approach to XML, which makes it a candidate for
processing with XQuery rather then XSLT. But querying such data is
interesting if access not to the whole subtree but to a context is
possible.

The same is true for flat structured textual documents where
distributional analysis of texts are required and wanted.

Accessing the linear structure of XML documents is a major advantage of
XML based databases for certain applications and clearly distinguishes
these DBs from relational data where these access structures are not to
be maintained.

Especially for the processing of natural language, in data or document
based XML, the full set of axis needs to be available.

I would strongly recommend the change of the following:
1. Section 3.2.1

OLD sentence: XQuery supports the following axes (subject to limitations
as described in 2.6.3 Full Axis Feature): <bulletlist>

NEW sentence: XQuery supports the following axes: <bulletlist>

2. Section 2.6.3 needs to be deleted. Vendors will provide their
personal flavors of XQuery, if the feature is in the specification or
not. But at least they should not find an excuse for omitting certain
axis that are justified.

If necessary I can provide example queries which are needed in language
databases.

A workaround with user defined functions (using features such as the
node number or position) or more complex contstructs is not acceptable,
as it seems to violate the priciples of navigation in XML trees.

Missing features like this would doom XQuery to failure in large and
progressing XML using communities.

Thorsten

--
-----------------------------------------------------------------------------
///////// Thorsten Trippel         ttrippel@spectrum.uni-bielefeld.de
   //     Computational Linguistics and Spoken Language
  //  //  Research Group: Text technological modelling of information
 //  //   URL: http://www.spectrum.uni-bielefeld.de/~ttrippel
    //    Bielefeld University, Federal Republic of Germany
///////// Department of Linguistics and Literary Studies
-----------------------------------------------------------------------------

            

PaulC will reply to this, alike to the David Carlise comment.

qt-2003Dec0288-01: multiple modules with same namespace
[substantive, decided] 2004-01-123
multiple modules with same namespace, Per Bothner (2003-12-31)
I asked this before, but even the latest drafts don't seem to have
a clear answer for whether there can be multiple library modules
with the same namespace.

Assume mod1.xql:

module namespace m = "M";
declare function m:f() { 1 }

and mod2.xql:

module namespace m = "M";
declare function m:g() { 2 }

Is the following main module allowed?

import module namespace m1 = "M" at "mod1.xql";
import module namespace m2 = "M" at "mod2.xql";
m1:f()+m2:g()

How about this?

import module namespace m = "M";
m:f()+m:g()

The statement in 4.7 that "The module import identifies the module
to be imported by its target namespace" implies neither are allowed
because in this case you cannot identify the module by its target
namespace.  But phrasing is sufficiently imprecise that I can't be
sure what's intended.

It would be nice to clarify this, either:
A. The target namespace must match a single library module; it is
a static error if multiple modules have the same namespace.
or:
B. If multiple modules match the target namespace, then they
are all imported.

My assumption (and strong recommendation) is that A is intended.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

            

> a) qt-2003Dec0288-01, multiple modules with same namespace > http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xquery/issues.html#qt-2003Dec0288-01 > Status: Deferred for further discussion at the XQuery F2F. Rys: we already have constraints in the static context. We might need more. Don: we could choose the simplest approach here. Which is option a), getting rid of the hint syntax. Jason/MaryH: we need this as use case, when we split functions in more files, during development. Dana: but you could use a URI resolver for that. Like similarly happens on Java, binding the logical resource to the physical resources. Rys: the things Mary and Jason want is more pertinent to a Query System rather than to a Query Language. Questions: Q1: can you have more than one ModuleImport for the same target namespace? (Per's question) [no; if you want more than one location hints use the facility to have multiple location hints] Q1a: can you have more than one ModuleImport for the same target namespace? with different locations? [no] Q2: can the namespace prefix which assigned to URI1 in one MOduleImport be the same as the Namespace prefix which is assigned to URI2 in a second ModuleImport? It should be no, but do we allow this now? Rys: We have a constraint that a Prefix must be bound to a single namespace Andrew: error XQ0033 might apply here Q3a: should we consider changing the syntax to permit multiple location hints (instead of just one) (in order to prohibit multiple ModuleImports for the same URI) [acceptable to many wg member] [and if so, we should do it for schemas too] Q3a': if we accept this should we do this for Schemas as well (for symmetry)? Q3b: should we consider dropping the location hint completely leaving the resolution of locations up to the URI resolver)? [two people in favour: Rys, Dana] So, Per's example: import module namespace m1 = "M" at "mod1.xql"; import module namespace m2 = "M" at "mod2.xql"; m1:f()+m2:g() could be written for instance as import module namespace m1 = "M" at "mod1.xql", "mod2.xql"; m1:f()+m1:g() *** * ACTION A-TAMPA-08 * on Don * to implement the resolution to * qt-2003Dec0288-01, multiple modules with same namespace, * and to reply to Per's public comment * (cf. http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xquery/issues.html#qt-2003Dec0288-01 ) *** Hints to Don for implementations of this proposal to add multiple location hints and to to prohibit multiple imports: a) Consider using text for success/failure of SchemaImport for ModuleImport b) multiple location hints should be comma separated c) consider errors if moduleImport causes function/variables/etc to be duplicated from multiple location hints d) do we raise an error if a ModuleImport causesw functions, variables etc to be duplicated form more than one location hints ---- Related question on modules by Don and IBM developers: If a module imports something (say a schema) that defines some type, and a query imports than module, I don't get eg the schemas that the module imports, but the functions. So I have to know the schemas, and explicitly import themselves. So, if I import a function that imports some type, why those types aren't imported too..? My IBM colleagues think this is broken. [people can't recollect] [so, Don will file in a Last Call comment by IBM]

qt-2003Dec0264-01: [XQuery] Precedence rules for QuantifiedExpr - OrExpr - AndExpr
[substantive, decided] 2004-01-123
I would like to enter this as a last call comment from DataDirect.

Jonathan


>  From: "Peter Coppens" <pgp.coppens@pandora.be>
>To: <www-ql@w3.org>
>Date: Fri, 19 Dec 2003 16:36:44 +0100
>Subject: Precedence rules for QuantifiedExpr - OrExpr - AndExpr
>X-Mailing-List: <www-ql@w3.org> archive/latest/701
>X-Loop: www-ql@w3.org
>Sender: www-ql-request@w3.org
>
>All,
>
>Looking at the XQuery spec, I am somewhat surprised by the consequences of
>the precedence rules for QuantifiedExpr - OrExpr and AndExpr
>
>What I mean is:
>
>Take the query
>
>for $x in (1,2,3)
>where
>   some $y in (1,2) satisfies 1 = $y and $y = 1
>return $x
>
>Which, I think, is equivalent to
>
>for $x in (1,2,3)
>where
>   some $y in (1,2) satisfies (1 = $y and $y = 1)
>return $x
>
>But now take the query
>
>for $x in (1,2,3)
>where
>   some $y in (1,2) satisfies 1 = $y or $y = 1
>return $x
>
>
>Which, I think, is equivalent to
>
>for $x in (1,2,3)
>where
>   (some $y in (1,2) satisfies 1 = $y) or $y = 1
>return $x
>
>I find that rather confusing.
>
>So I guess I have the following questions
>
>(1) is the above interpretation correct?
>(2) is this a deliberate choice and if yes, are there any motivations for
>that decision that can be shared?
>(3) would it not be possible to add an extra level of precendence where the
>OrExpr comes to sit between QuantifiedExpr and AndExpr, or would that
>propagate to have other side effects?
>
>Thanks,
>
>Peter

            

> I was rather surprised by this comment, but looking at the way the spec is > written, I can see how you came to this conclusion. So you see the issue being that "or" is at the same level as FLWORExpr, some, every, TypeswitchExpr, and IfExpr "Precedence Order" table? > I'm pretty sure the > intent was that > > some x in y satisfies a or b > > should parse as > > some x in y satisfies (a or b) Yep. As extra enforcement to this fact, here is the diagnositic results from the test parser. some $x in y satisfies a or b |QueryList | Module | MainModule | Prolog | QueryBody | Expr | QuantifiedExpr | Some some $ | VarName x | In in | PathExpr | StepExpr | NodeTest | NameTest | QName y | Satisfies satisfies | OrExpr or | PathExpr | StepExpr | NodeTest | NameTest | QName a | PathExpr | StepExpr | NodeTest | NameTest | QName b Quiz time: for $x in baz return $x or for $z in yada return $z What does this expression do, in terms of parsing? Answer: it is a syntax error. for $x in baz return for $z in yada return $z or $x What does this expression do, in terms of parsing? Answer: it parses just fine. This is a resolved issue, and I think is goodness, but is a little confusing when looking at precedence issues. -scott

Proposal accepted.

            


            

[[accepted]]


            

> c) qt-2003Dec0264-01 : [XQuery] Precedence rules for QuantifiedExpr - > OrExpr - AndExpr > http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xquery/is > sues.html#qt-2003Dec0264-01 > > Status: This item is classified incorrectly, it should be Joint, as it > relates to XPath. Deferred to joint F2F (XPath) meeting. Done as well.

qt-2003Nov0307-01: [XQuery] SAG-XQ-004 Unordered
[substantive, decided] 2004-08-31
[XQuery] SAG-XQ-004 Unordered, Kay, Michael (2003-11-27)
SAG-XQ-004 Unordered

We find that the concept of unordered() as a function, while it has some
theoretical justification, is very difficult to explain to users. This is
because it doesn't reflect the intended purpose: people call functions when
they want to perform some computation on a supplied value, not when they
want to tell the compiler to relax the rules on how the input is evaluated.

The decision also seems to be inconsistent with the decision to merge "order
by" into the FLWOR expression, rather than offering "sort" as a
free-standing function/operator as was done previously.

We propose that the functionality provided by the unordered() function be
offered instead by custom syntax in the FLWOR expressions: essentially by a
keyword UNORDERED which would be a syntactic alterative to the ORDER BY
clause.

Michael Kay
for Software AG
RE: issue list status, Paul Cotton (2004-08-31)

            

The current "unordered" is syntax now, not a function.

qt-2003Nov0304-01: [XQuery] SAG-XQ-003 Run-time access to static namespace context
[substantive, decided] 2004-10-08
SAG-XQ-003 Run-time access to static namespace context

There are a very small number of constructs in the XQuery draft that require
run-time knowledge of the static namespace context. We feel that these
constructs are undesirable.

(a) they create a dependency on the choice of prefixes that is not apparent
to the casual reader of a query, leading possibly to failures if the
prefixes are changed.

(b) they create complexities for implementors and run-time overheads,
especially for products that act as compilers rather than interpreters,
because the amount of information that needs to be retained in the compiled
code is greatly increased.

(c) they offer no functionality that cannot be achieved in some other way,
just as conveniently.

The constructs that require access to the static namespace context are:

- computed element and attribute constructors
- casting string to QName (and perhaps NOTATION)

(the latter also affects XPath)

In computed element and attribute constructors, we allow the name of the
element or attribute to be evaluated either as a value of type xs:QName, or
as a string in the lexical form of a QName. The second option is useful only
(a) where the desired name is in no namespace (and there is no default
namespace), and (b) where the desired namespace URI is known statically, but
the desired local name is computed. I think that we should retain the option
to supply the value as a string, but in this case it must be in the form of
an NCName, and the resulting node will be in no namespace. For the second
case, it is just as easy to construct an xs:QName dynamically by calling the
expanded-QName function.

For casting a string to a QName, the cast can only succeed if the prefix is
one that has been statically declared. In practice this means that the
namespace URI must either be known in advance, or must be one of a small set
of possible namespace URIs. This scenario is not especially plausible, and
when it does occur, it is just as easy to use the expanded-QName function to
construct the required QName.

In fact the main use case for casting string to QName is where the string is
supplied as a literal, for example in the constructor
xs:QName("xs:integer"). This is needed for example in an argument of a
function call where a value of type xs:QName is required. We could meet this
use case either (a) by treating the xs:QName() constructor as a special
case, and requiring the argument to be a string literal, or (b) by providing
custom syntax for QName-literals.

Michael Kay
for Software AG
	    
            

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.

qt-2003Nov0303-01: [XQuery] SAG-XQ-002 Input collection
[substantive, decided] 2004-09-15
[XQuery] SAG-XQ-002 Input collection, Kay, Michael (2003-11-27)
SAG-XQ-002 Input collection

We regret that there is no simple intuitive way of writing a query whose
input is some implicit (context-defined) collection of documents.

The input() function went some way to meeting this need, but this has
disappeared.

The context item is restricted to a single node or value, which sends the
wrong message about the purpose of XQuery, which is that it is designed
primarily to process large collections of documents, unlike XPath, which is
designed primarily to locate nodes within a single document.

Other mechanisms for supplying a collection as input to the query (using
parameter variables, and using the collection() function) are syntactically
cumbersome.

We think that for XQuery (as distinct from XPath and XSLT) the concept of an
implicit input collection is a useful one, and that there should be a
convenient syntax to refer to it. (How about "~", or perhaps "$$"?)

Michael Kay
for Software AG
XML Query Teleconference 208 Minutes 2004-09-15, Massimo Marchiori (2004-09-15)

            

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

qt-2003Nov0292-01: computed namespace constructors
[substantive, decided] 2004-06-13
computed namespace constructors, Per Bothner (2003-11-25)
The semantics of computed namespace constructors is unclear:

   3.7.3.7 Computed Namespace Constructors
   A constructed namespace node ... binds a namespace prefix represented
   as NCName in the syntax) to a URI and adds the namespace prefix to the
   in-scope namespaces for its enclosing element.

But the "in-scope namespaces" is part of the *static* context, and
constains both prefix *and* URIs:

   [Definition: In-scope namespaces. This is a set of (prefix, URI)
   pairs. The in-scope namespaces are used for resolving prefixes used
   in QNames within the expression.]

So how can a run-time namespace expression add to the static in-space
namespaces?

It might be possible to change the sementics so only the namespace
prefixes is part of the static context, while the namespace uri is
part of the dynamic context, but that would certainly complicate
implementation and probably the semantics  Consider:

element {$ename} {
    namespace xx { myns:f($myns:x) },
    namespace myns
       {if $version eq 1 then "http://example.org/v1"
        else "http://example.org/v2"},
    attribute xx:type {"myns:invoice"},
    $content
}

This has a forward reference to the myns namespace (is that allowed?),
and an function name, a variable name, and an attribute name, all of
whose namespaces have to be calculated at run-time.  I assume the
intention is to not allow that.

I suggest a separate concept of "active namespaces" consisting of
anmespaces declared in namespace attributes and namespace constructors.
This could be part of the dynamic environment, but not the static
environment.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/
XML Query Teleconference 192 Minutes 2004-06-09, Working Group Minutes (2004-06-09)

            

we've renovated this part of the document

and inviteed the author of the public comment to look at a future

WD to confirm that the semantics is clear


            

we've renovated this part of the document and inviteed the author of the public comment to look at a future WD to confirm that the semantics is clear

qt-2003Nov0261-01: [XQuery] Normalizing line endings
[substantive, decided] 2004-08-12
[XQuery] Normalizing line endings, Kay, Michael (2003-11-21)
There do not appear to be any rules saying that line endings in XQuery text
are normalized.

This means that the query:

<a>
  gotcha!
</a>

will return a different infoset depending on how the text editor used to
prepare the query represents line endings, and it will potentially produce a
different infoset from the one produced by an XML parser when applied to the
same input.

I would recommend that line endings within XQuery input text should be
normalized in the same way as XML line endings. And to avoid having to
change the rules in the future, I would suggest that we use the XML 1.1
rules rather than the XML 1.0 rules.

This rule should not apply to XPath; preprocessing of XPath input is the job
of the host language.

Michael Kay
Software AG
XML Query Teleconference 201 Minutes 2004-08-11, Andrew Eisenberg (2004-08-12)

            

JR: Do end-of-lines in query get converted to single character as per XML rules? If not, impedes testing. In addition, given that direct constructors look like XML, it would be confusing to have them behave differently. Q: What about such characters in a quoted string? A: That's a quoted string, that's different. If extracted into XML content, then it happens. Q: More specifically, string with CRLF and use that to construct element content? A: When element content gets CRLF it gets converted to new character. MK: No, don't think that's right, I think "behaving like XML" means all CRLF gets normalized as first stage. If you want a CR character you use entity reference. XML does more than normalize element content, also does it to attribute values. MR: No problem with doing that in XML construction, but have a problem of doing that to string literals. That is, if I use existing XML syntax to do XML construction use the XML rules, but if use XQuery functions or value retrieved from DM instance, then shouldn't happen. MK: Not suggesting changing data model values. So: <foo bar=" attrvalue"> <bar /> </foo> would get normalized What about: <foo bar="{ attrvalue}"> <bar /> </foo> Yes: because you get attribute value normalization. AE: Considers this surprising. MK: Considers not doing it surprising. JR: Considers it inappropriate to make results of XQuery OS-dependent. MK: Not also if have CR in there inadvertently, then serializer will have to output that as #xD, which gets messy. Should have to work quite hard to get a CR into your results. MR: If you are concerned about portability, use entity references. MH: Two sets of rules would be confusing. Often flip back from literal element construction to using functions and variables in course of development. Gets confusing to change results. DC: So XML elements vs "inside the curly brace" are the two contexts? Yes. Don't have strong opinion, but see them as sufficiently different to motivate treating them differently. JR: Why would I ever want to get different behaviour on different OSes? MR: Simple. Strings should be looked as from the POV of data model instances and therefore should not be messed with. Similar rules for whitespace. AE: Some languages, e.g. SQL, disallow end of line inside string literals to get away from this problem. JM: Sort of; SQL finesses the issue a bit. DC: What does serialization say? Do newlines get put out in OS conventions? MK: Serializer needs to preserve roundtripping. If you see CR serializer must emit as #xD, under assumption that was only way it got there and to preserve ther roundtripping. Case 1: element construction, do line-ending normalization as per JR's message which uses XML 1.1 rules MR: Wants to stick to XML 1.0 rules MK: Strongly in favour of XML 1.1 rules to prevent transition problems down the road. The rules: 1. the two-character sequence #xD #xA 2. the two-character sequence #xD #x85 3. the single character #x85 4. the single character #x2028 5. any #xD character that is not immediately followed by #xA or #x85. Items 1 and 5 are XML 1.0 rules. MR: Suggest we make it implementation-defined whether you do it as per 1.0 or 1.1, linked to existing implementation-defined decision about handling XML 1.0 or 1.1 DC: Why it is harmful for system implementing XML 1.0 to implement these rules? MR: Need to have different parsing. MK: Argument against #85 is that it means something in Windows proprietary charsets and people get them inadvertently into data when they think they are using ISO-8859-1. Don't think we should redebate pros and cons of XML 1.1 decisions here, however. MR: Disagree. We have already decided to give it an implementation option whether to support XML 1.0 or XML 1.1. MK: I think it is just sacrificing portability for no particular reason. AGREE: that XML 1.0/NS 1.0 vs XML 1.1/NS 1.1 should be a single choice across the document. AGREE: In direct element constructors, end-of-line normalization is performed, either using XML 1.0 or XML 1.1 rules, implementation-defined Case 2; string literals (inside curlies) * no normalization * normalize * ban end-of-lines in string literals DC: Asks for use case for NL in string literal JM: Have text that needs to be formatted exactly as is (e.g proglang code) and wish to express a value that has line endings in it. AGREE: Normalize line endings in source text of XQuery either using XML 1.0 or XML 1.1 rules, implementation-defined as per global switch Clarification: Not for pure XPath, a host language issue, this is just for XQuery. RESOLVED: http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0261.html by agreeing to normalize line endings in the source text of XQuery, using either the XML 1.0 rules or the XML 1.1 rules, the choice of which being implementation-defined per a global switch that selects either XML 1.0/XMLNS 1.0 rules or XML 1.1/XMLNS 1.1 rules.

qt-2003Nov0249-01: [XQuery] use of XP0008 for element/attribute names
[substantive, decided] 2004-01-15
[XQuery] use of XP0008 for element/attribute names, Priscilla Walmsley (2003-11-21)
In section 2.4.3, the XQuery language draft says:

"It is a static error [err:XP0008] to use an ElementName in an ElementTest
if that name is not found in the in-scope element definitions unless a
TypeNameOrWildcard is specified."

and

"It is a static error [err:XP0008] to use an AttributeName in an
AttributeTest if that name is not found in the in-scope attribute
definitions unless a TypeNameOrWildcard is specified."


But the error description for XP0008 reads:

"It is a static error if an expression refers to a type name, function name,
namespace prefix, or variable name that is not defined in the static
context."

which does not cover element or attribute names.  It seems to me that a new
error should be created for these 2 cases.

Thanks,
Priscilla

            

Don: these two cases have been added ot the (now non-normative) list in the January draft. ACTION A-164-02: qt-2003Nov0249-01 [XQuery] use of XP0008 for element/attribute names Carmelo to respond positively, he's correct, and we're going to change the XQuery document so that it's covered.

qt-2003Nov0217-01: [XQuery] 2.6.3 Full Axis Feature
[substantive, decided] 2004-01-123
[XQuery] 2.6.3 Full Axis Feature, David Carlisle (2003-11-18)
What is the rationale for the full axis feature?

Having these things optional greatly harms interoperability between
Xquery systems and between Xquery and Xpath.

It would be understandable if it were (say) all the reverse axes that
were optional as there are issues supporting those axes in a streaming
manner, but since parent:: and << are both non-optional these axes can
be supported by an entirely syntactic re-write. Forcing the users to do
that is a pain, and one would assume that it is much easier for a system
to spot and optimise a specific syntax such as following-sibling::foo
than the equivalent expression
let $here := . return ../foo[$here << .]

I would strongly urge that this feature be dropped and that support for
the axes be mandatory.


David

________________________________________________________________________
This e-mail has been scanned for all viruses by Star Internet. The
service is powered by MessageLabs. For more information on a proactive
anti-virus service working around the clock, around the globe, visit:
http://www.star.net.uk
________________________________________________________________________

            

Rys: we should keep the status quo, as the extra axes have problems wrt static type inference. Also, some implementation problems (eg for streaming or views). PaulC: initially we made this option as the wg didn't have enough large consensus. Pat: these axes are of use in the document community, like book authors Jason: yes, lot of use cases, eg you have a paragraph and want to cite the whole context (pre and post paragraph). Or, a chapter and you want to get its title. Rys: but that is a minority of use cases, the truth is that these axes are very problematic for typing Dana: but we can already simulate these axes, so what's the point? Massimo: yes; and, the major problem here is interoperability: if these axes are bad, let's put them out; if they are good because some people use the, let's make them mandatory. As it is now we stay in the middle of the road, with no good reasons. Steve: another possible way is to remove parent and root too. This would help providing a rational solution. Massimo: yes, that would at least be a rational position... JimM: yes, that would be very helpful for streaming. Votes (only one preference): status quo: 6 all mandatory: 4 move parent and root to being optional 4 Votes (multiple preferences possible): status quo: 8 all mandatory: 7 move parent: 7 can live with status quo: 9 can't live: 1 abstain: 4 So, status quo prevails.

qt-2003Nov0194-01: [XQuery] empty strings in content expressions
[substantive, decided] 2004-01-123
"3.7.3.1 Computed Element Constructors"

In the part that describes the processing of the content expression I think it
doesn't say exactly what happens if the "adjacent sequence of one or more
atomic values" consists of just the empty string.  In that case you clearly
cannot create a text node, but is an error raised or are such atomic values
simply removed? And if they are removed does that happen before or after the
concatenation with intermediate spaces?

Kind regards,

-- Jan Hidders

            

> g) qt-2003Nov0194-01 : [XQuery] empty strings in content expressions > http://www.w3.org/XML/Group/xsl-query-specs/last-call-comments/xquery/is > sues.html#qt-2003Nov0194-01 > > ACTION A-164-03: qt-2003Nov0194-01 : [XQuery] empty strings in content > expressions > Mike Kay to propose rewording of the paragraph "For each > adjacent sequnce of one or more atomic values", also handling the case > text { "" }, so that a sole empty string isn't an error in an element > constructor. > DONE. See: > http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jan/0041.html Rys: <tag>{{'1','','2'}</tag> this gives 1 _ 2 or 1 _ _ 2 ? (here, "_" is the blank). Jonathan: the single blank makes more sense to me. Rys: problems with the static rules and optimizations Rys: pls see my comment in (Jan/0214), cf. issue MS-DM-LC2-066 where I given an alternate way to handle this, by adapting the data model (instead of the XQuery change), so that we won't need MikeK's fix text for this. People note MikeK's text is correct, although redundant if we adopt Rys'. So, people approve MikeK's amendment. And, Srinivas will reply to this public comment. And, Michael Rys will further investigate shaping of its proposal wrt impact on the data model.

qt-2003Nov0188-01: union, intersect, and except
[substantive, decided] 2004-01-15
union, intersect, and except, Elliotte Harold (2003-11-15)
Why are the union, intersect, and except operations limited to working
on sequences of nodes? It seems to me that they are perfectly well
defined operations for sequences of arbitrary types, and that these
three operators should be declared to work on sequences of item type. If
there's no good reason for limiting them to node()*, I would ask that
the signatures of these operators be revised to item()* instead.

--
Elliotte Rusty Harold

            

Mike Kay: we decided the semantics of these operations on sets of atomic values were to different from the same operations on sets of nodes, and should be separate operators; we then decided that they were easy enough that F&O tells people how to implement them. ACTION A-164-04: qt-2003Nov0188-01 : union, intersect, and except Michael Kay to send a response to say that the WG reviewed the comment and we're not planning to make any changes.

qt-2003Nov0186-01: recursive imporged variable declarations
[substantive, decided] 2004-08-31
recursive imporged variable declarations, Per Bothner (2003-11-13)
Section 4.8 "Variable Declaration" of the XQuery November specification
says that:
   A variable may appear in the expression part of a variable declaration
   only if that variable is declared or imported earlier in the Prolog
   than the declaration in which it is used.
This is presumably to prevent indeterminacies and cycles.
However, section 4.7 "Module Import" says that:
   Two modules may import each other.

So is there anything to prohibit the following?

module namespace m1 = "M1";
import module namespace m2 = "M2";
declare variable $m1:v { $m2:v };

module namespace m2 = "M2";
import module namespace m1 = "M1";
declare variable $m2:v { $m1:v }
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/
RE: issue list status, Paul Cotton (2004-08-31)

            

Per Bothner asked about this in a public comment. This is pushback to Don's response to Per's qt-2003Nov0186-01. Don notes that there can be circularity involving separate compilation of modules, and raises an orthogonal item about this not being possible with a static error. Some discussion of this. Andrew: we have two questions: do we have a valid definition of circularity, and do we need to tie it down further. Can we leave it loose? Jonathan: I'd like to separate this from separate compilation. We don't talk about linking and module loading at all right now. Don: I'm just saying we might not define any specifications that preclude separate compilation. Mary H. and Jerome pointed out that we had more complex text before from Paul Pederson and they weren't sufficient, so we deleted them. Mary: I think the right way to proceed is to stick with what we have, and the only reason to get more specific is because we think implementors won't be abe to make interoperable implementations, but I think in practice this won't be a problem. If difficulties arise, we'll know more clearly. straw poll: Want clearer defintion of circularity: 0.5 Current document is OK: 5 Abstain: 3 Jonathan drafted a response tp Per and will send it; no changes to the documents.

qt-2003Nov0300-01: belated namespace declaration attributes
[substantive, decided] 2004-01-123
belated namespace declaration attributes, Per Bothner (2003-11-26)
Consider the following query:

declare namespace n = "N";
declare namespace m = "M";
declare variable $n:x {"nx"};
declare variable $m:x {"mx"};
declare variable $e {<e n:a="{$n:x}" xmlns:n="M"/>};
declare variable $f {<f a="{$e/@a}" xmlns="M"/>};
<result>
e: {$e}
f: {$f}
</result>

The output I expect is:

<result>
e: <e xmlns:n="M" n:a="mx"/>
f: <f xmlns="M" a="mx"/>
</result>

Saxon 7.8 emits:

<result>
e: <e xmlns:n="M" n:a="nx"/>
f: <f xmlns="M" a=""/>
</result>

Kawa doesn't handle namespace declaration attributes,
but it's next on my list of projects to tackle.

This is tricky to implement (and for humans to read),
because the namespace declaration attribute follows
an enclosed expression that makes use of it.  This
means that namespace resolution cannot be done during
the first parsing pass.

XQuery could avoid this complexity, by requiring that
namespace declaration attributes come before regular
attributes - or at least before any enclosed expressions.
--
	--Per Bothner
per@bothner.com   http://per.bothner.com/

            

> e) 2003Nov/0300 belated namespace declaration attributes > http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0300.html MikeK: Per is correct, and we should make that clear Don: Yes, and that's what XML does, and there's no intention that our constructor syntax should diverge in any way from XML AndrewE: see Namespace Declaration, 4.10 *** * ACTION A-TAMPA-20 * on Jonathan Robie * to respond to the public comment on belated namespace declaration attributes * (http://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0300.html) * saying that we want to be the same as XML, and the order will not be made significant. ***

qt-2003Nov0032-01: [XQuery] Computed CDATA constructor
[substantive, decided] 2004-01-123
[XQuery] Computed CDATA constructor, Sarah Wilkin (2003-11-10)
It seems for every direct constructor there is a computed constructor
-- except for CDATA sections. Since the WG has allowed CDATA direct
constructors at all, there should be full support including computed
constructors. I can understand if the CDATA sections were only to ease
creating/viewing files that would otherwise require many entities, but
since they also may be serialized by implementors it is limiting to not
to have this functionality.

Proposed rule:
CompCdataConstructor ::= "cdata" "{" Expr? "}"

--Sarah
Hi Sarah,

The XML Query Working Group has considered your feedback in the
following message:

http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jan/0042.html

The following is an official response from the XML Query Working
Group:

You have correctly pointed out a confusing inconsistency in our
specification. The reason for this inconsistency is that a
CompCdataConstructor does not actually create a CDATA node - in fact,
there is no such thing as a CDATA node in the Data Model. Although the
syntax of CDATA section in XML looks a lot like other things that
really are constructors in XML, and probably would be treated as a
constructor if CDATA nodes existed, this is not the case. (We
confirmed in yesterday's meeting that the WG does not want to add
CDATA sections to the data model.)

 From an XQuery or XSLT perspective, a CDATA section is merely a way of
changing the treatment of special characters within a region of
text. We have decided to change XQuery in the following way:

1. Remove all references to CData sections from Section 3.7.2 ("Other
Direct Constructors"). There should be no reference to a "CData
Section constructor" anywhere in the language document.

2. Remove CDataSection from the production named Constructor, but
leave it in the production named ElementContent. Move the production
named CDataSection to the top of Section 3.7 ("Constructors"), near
the production named ElementContent.

3. In Section 3.7.1.3 ("Direct Element Constructors--Content"), in the
list of rules labeled "Conceptually, the content of an element
constructor is processed as follows", change the rule (1a) to:
"Predefined entity references and character references are expanded
into their referenced strings, as described in 3.1.1 Literals
<http://www.w3.org/TR/xquery/#id-literals#id-literals>. Characters
inside of a CDataSection are treated like XML CData sections and are
mapped directly into string content. The content of a CDataSection may
not contain the string "]]>" since this string is used to delimit the
CDataSection".

We believe this improves our specification by making it more
consistent with the semantics of our data model, and thank you for
your input.

Please let us know if this response is satisfactory for you,

Jonathan
Jonathan,

This is quite satisfactory, thanks.

--Sarah

On Jan 21, 2004, at 2:04 PM, Jonathan Robie wrote:

> Hi Sarah,
>
> The XML Query Working Group has considered your feedback in the
> following message:
>
> http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jan/0042.html
>
> The following is an official response from the XML Query Working
> Group:
>
> You have correctly pointed out a confusing inconsistency in our
> specification. The reason for this inconsistency is that a
> CompCdataConstructor does not actually create a CDATA node - in fact,
> there is no such thing as a CDATA node in the Data Model. Although the
> syntax of CDATA section in XML looks a lot like other things that
> really are constructors in XML, and probably would be treated as a
> constructor if CDATA nodes existed, this is not the case. (We
> confirmed in yesterday's meeting that the WG does not want to add
> CDATA sections to the data model.)
>
> From an XQuery or XSLT perspective, a CDATA section is merely a way of
> changing the treatment of special characters within a region of
> text. We have decided to change XQuery in the following way:
>
> 1. Remove all references to CData sections from Section 3.7.2 ("Other
> Direct Constructors"). There should be no reference to a "CData
> Section constructor" anywhere in the language document.
>
> 2. Remove CDataSection from the production named Constructor, but
> leave it in the production named ElementContent. Move the production
> named CDataSection to the top of Section 3.7 ("Constructors"), near
> the production named ElementContent.
>
> 3. In Section 3.7.1.3 ("Direct Element Constructors--Content"), in the
> list of rules labeled "Conceptually, the content of an element
> constructor is processed as follows", change the rule (1a) to:
> "Predefined entity references and character references are expanded
> into their referenced strings, as described in 3.1.1 Literals
> <http://www.w3.org/TR/xquery/#id-literals#id-literals>. Characters
> inside of a CDataSection are treated like XML CData sections and are
> mapped directly into string content. The content of a CDataSection may
> not contain the string "]]>" since this string is used to delimit the
> CDataSection".
>
> We believe this improves our specification by making it more
> consistent with the semantics of our data model, and thank you for
> your input.
>
> Please let us know if this response is satisfactory for you,
>
> Jonathan
>

            

Mary: this text could be a bit more precise, and also say what happens eg when predefined entities are expanded. It'd be good if this boilerplate would be the same both for the language and formal semantics doc and for XSLT. Rys: pls see my text in http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Jan/0052.html People agree that mixing Don's 042 message and Rys' 0052 (amendment to Don's point (3)), is the good way to go here. Don will take care. Jonathan will send a reply to this public comment. [approved]

qt-2004Mar0058-01: [XQuery] LQ-XQ-01 - human readable
[editorial, decided] 2004-10-17
[XQuery] LQ-XQ-01 - human readable, Liam Quin (2004-03-04)
[minor editorial]

In section 1. Introduction, 2nd paragraph, we have,
    The Query Working Group has identified a requirement for both a
    human-readable query syntax and an XML-based query syntax

In fact the Requirements document does not talk about a
"human-readable" syntax, and does not discuss a concept that the
non-XML syntax is intended for human consumption and the XML syntax
is intended only for machine use (not human readable).

There are people who consider that at least some XML documents - for
example, XSLT stylesheets - can be read by humans.

I suggest using the terms "XML syntax" and "non-XML syntax".

Thanks,

Liam

--
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1160-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-017
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-017 Section B.2 Operator Mapping

There are few typos in the table Binary Operators - the xs:dateTime is named
xs:datetime (lowercase T) in the following rows :

  A + B xs:datetime xdt:yearMonthDuration     op:add-yearMonthDuration-to-dateTime(A, B) xs:dateTime
  A + B xdt:yearMonthDuration xs:datetime     op:add-yearMonthDuration-to-dateTime(B, A) xs:dateTime
  A + B xs:datetime xdt:dayTimeDuration       op:add-dayTimeDuration-to-dateTime(A, B)   xs:dateTime
  A + B xdt:dayTimeDuration xs:datetime       op:add-dayTimeDuration-to-dateTime(B, A)   xs:dateTime


  A - B xs:datetime xs:datetime               fn:subtract-dateTimes-yielding-dayTimeDuration(A, B) xdt:dayTimeDuration
  A - B xs:datetime xdt:yearMonthDuration     op:subtract-yearMonthDuration-from-dateTime(A, B) xs:dateTime
  A - B xs:datetime xdt:dayTimeDuration       op:subtract-dayTimeDuration-from-dateTime(A, B) xs:dateTime
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1156-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-013
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-013 Section 3.7.3.1 Computed Element Constructors

    The content expression of a computed element constructor is processed as
    follows:

    1. For each node ...

       Any sequence of adjacent text nodes in the content sequence is merged
       into a single text node.

Suggest adding the phrase:

    "by concatenating their contents, with no intervening blanks"

to be precise as bullet 4 in "3.7.1.3 Content".
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1155-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-012
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-012 Section 3.7.2 Other Direct Constructors

    A CDATA section constructor constructs a text node whose content is the
    same as the content of the constructor.

Since the term "content of CDATA section constructor" was not defined seems
better to use more precise wording

    A CDATA section constructor constructs a text node whose content is the
    sequence of characters placed between starting and ending delimiters of
    the CDATA section constructor.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Overtaken by events. CData section constructors no longer exist.

qt-2004Feb1154-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-011
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-011 Section 3.7.1 Direct Element Constructors

There is a seeming contradiction between definitions of "direct element
constructor"

    If the name, attributes, and content of the element are all constants,
    the element constructor is based on standard XML notation and is called
    a direct element constructor.

and later

    In a direct element constructor, curly braces { } delimit enclosed
    expressions, distinguishing them from literal text.

This contradiction could be remedied by modifying the first definition as

    One form of a direct element constructor is where the name, attributes,
    and content are all constants in standard XML notation.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1153-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-010
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-010 Section 3.5.3 Node comparison.

    4. A comparison with the << operator returns true if the first
    operand node precedes the second operand node in document order;
    otherwise it returns false.

    5. A comparison with the >> operator returns true if the first
    operand node follows the second operand node in document order;
    otherwise it returns false.

Seems better to use more usual and neutral "left and right operands"
instead of "first and second" since the natural ordering while reading
not always is "left-to-right".
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1152-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-009
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-009 Section 3.4 Arithmetic Expression

    If the operand types are now valid for the given operator, the
    operator is applied to the operands, resulting in an atomic value
    or a dynamic error (for example, an error might result from dividing
    by zero.)

We recommend an anchor over "dividing by zero" pointing to the functions
and operators document, e.g. [2].

[2] http://lists.w3.org/Archives/Member/member-query-specs/2003Dec/att-0001/xpath-functions.html#func-numeric-divide
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. This sentence is intended as an example of a possible error (dividing by zero). No value is added by referencing a specific error code or message. Adding cross-document references makes the documents fragile and subject to breakage as the target document is edited.

qt-2004Feb1151-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-008
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-008 Section 3.2.2 Predicates.

A left-to-right order of applying of predicates is not specified but
such order is implied by samples and other definition in the section.
Explicit wording about order of applying of predicates would avoid
misreading.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. Text has been revised, and currently says "The value of the step consists of those items that satisfy the predicates." I do not see any value in constraining an implementation to evaluate the predicates from left to right. However, in partial response to this comment, I have inserted an example of a step with multiple predicates.

qt-2004Feb1149-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-007
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-007 Missing anchors on error types (document wide)

A few instances referring to errors are missing anchors.  To be
consistent these should probably be fixed.

3.12.1 Instance Of
   "dynamic error" in the last sentence isn't an anchor.

4.7 Module Import
   "static error" in the first paragraph isn't an anchor.

4.8 Variable Declaration
   "static error" in first paragraph isn't an anchor.

4.8 Variable Declaration
   "type error" in second paragraph isn't an anchor.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb1150-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-006
[editorial, decided] 2005-01-20
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-006 Section 2.4.4 SequenceType Matching

In the definition of the function 'type-matches' it would be helpful
to describe some reasons why derivation by extension for unknown
actual type is not treated by the spec as base for a positive result
of type-matches(ET, AT).  A brief description of the reason for
the difference would be helpful.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests a more detailed justification for the "winged horse" rules. Why is derivation by restriction treated differently from extension? Status: No action taken. If the working group wants to add this material, I will need some help in preparing it. [closed with no action]

qt-2004Feb1148-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-005
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-005 Section 2.4.4 SequenceType Matching

In the definition of the function 'type-matches', phrases like

  type-matches(ET, AT) returns true if:
    1.AT is a known type, and is the same as ET, or is derived by one
     or more steps of restriction or extension from ET, or
    2.AT is an unknown type, and an implementation-dependent mechanism
     is able to determine that AT is derived by restriction from ET.

might be better stated as

       "validly derived from ET according to the XML Schema
       specification rules"

instead of

       "derived by one or more steps of restriction or extension
       from ET"
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. The referenced text has been debated extensively. We intend to emphasize the difference between derivation by restriction and by extension.

qt-2004Feb1147-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-004
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-004 Section 3.7.1.5  Type of a Constructed Element

Bullet point 2 for the case of "strict" validation. The search for a
type definition is described as "the in-scope element declarations are
searched for an element declaration whose unique name matches the name
of the constructed element."

This description is not complete: it should also mention that the
presence of "xsi:type" in the constructed element can also be used.
Further, that "xsi:type" will take precedence over in-scope element
declarations.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Overtaken by events. The referenced text no longer exists. We no longer have validation modes.

qt-2004Feb1146-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-003
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-003 Section 3.7.3.2 Computed Attribute Constructors

The last paragraph in this section says, "the computed attribute
constructor must not be a namespace declaration attribute--that is,
its name must not be xmlns or a QName with prefix xmlns."

In the Namespace 1.1 Recommendation at [2], the following definition
appears in section 3 "Declaring Namespaces":

[Definition: A namespace (or more precisely, a namespace binding) is
declared using a family of reserved attributes. Such an attribute's
name must either be xmlns or begin xmlns:. These attributes, like
any other XML attributes, may be provided directly or by default. ]

Note that the term prefix is not used.

Suggested text:
   --that is, the QName must not be xmlns and must not begin xmlns:.

(N.B. in the rec both "xmlns" and "xmlns:" appear in bold).

[2] http://www.w3.org/TR/2003/PR-xml-names11-20031105/#ns-decl
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Overtaken by events. The referenced text no longer exists. The constraint is described in terms of a URI rather than a namespace prefix.

qt-2004Feb1144-01: Last Call comments on XQuery 1.0: An XML Query Language XSCH-QL-001
[editorial, decided] 2004-10-17
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] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-001 Section 2 Basics

Section 2, third paragraph, says, "some kinds of nodes have typed
values, string values, and names, which can be extracted from the
node".  Although technically this is correct, it would be better to
refer to section 2.4.2, where it explains that all (not just some)
have typed values and string values, though not all allow access to
the values.

It can be made more precise by saying something like:

  "All nodes have typed values and string values, some of which can be
  extracted from the node.  Some kinds of nodes also have names,
  which can be extracted from the node.  For details on how these values
  are determined and on their availability for various node types
  please see section 2.4.2."
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Mostly done. Fixed text to denote that all nodes have typed value and string value. This is an introductory section, not a place for detail.

qt-2004Feb1000-01: [XQuery] BEA_033
[editorial, decided] 2005-01-20
[XQuery] BEA_033, Daniela Florescu (2004-02-18)
XQuery:  editorial


Section 2.1 as written can lead to misunderstandings.
I think we should reword it a little bit by making clear
the following two points, and correcting an error.

(a) The information in the static context of an expression
  is also used for the evaluation phase.

(error: as consequence of this, first paragraph in 2.1.1 should mention
that this
information can also decide if the expression has a dynamic error)

(b) Each subexpression of an expression can have a different static and
dynamic context during the entire lifetime of that expression: parsing,
static analysis and evaluation.

Best regards,
Dana
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests a statement that static context is used also during the evaluation phase. Status: Recommend to reject, because this is already made clear by paragraph 3 of Section 2.1.2, Dynamic Context.

qt-2004Feb0861-01: ORA-XQ-149-E: no explicit mention of lexical errors
[editorial, decided] 2004-06-13
SECTION A.2.2: lexical rules

Second para, second sentence: "Each table corresponds to a
lexical state and shows that the tokens listed are recognized
when in that state."  It would help to state that any unlisted
tokens are lexical errors.  For the reader who misses this
sentence entirely, it might help if each table had a last
row whose "Pattern" is "any other token" and whose "Transition
to state" was "lexical error".


- Steve B.
Accepted.

            

We looked at Scott's modified text.


            

[[accepted]]

qt-2004Feb0860-01: ORA-XQ-067-E: Definitions should not have exceptions
[editorial, decided] 2005-01-20
SECTION 2.1.1: Static context

The definition of "default collation" is followed immediately by
the sentence "for exceptions to this rule...".  To me, a
definition should be something that has no exceptions.  One
way to fix this would be to move the exceptions into the definition.
Thus, "Default collation.  This collation is used ... except as
specified in 4.11 Default Collation Declaration."


- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Overtaken by events. Referenced sentence no longer exists.

qt-2004Feb0858-01: ORA-XQ-125-E: please expand examples to include xml:space attribute
[editorial, decided] 2005-01-20
SECTION 3.7.1.4: whitespace in element content

It would also be useful to show examples with xml:space attributes.
The last example looks like a good starting point.
<a>{"   "}</a> creates <a>   </a> even if xmlspace is strip.
Thus with "declare xmlspace strip",
<a xml:space='preserve'>   </a> creates <a xml:space='preserve></a>
in spite of the xml:space='preserve' attribute, because boundary
whitespace is stripped.   On the other hand,
with "declare xmlspace preserve",
<a xml:space='default'>{"   "}</a> creates
<a xml:space='default'>   </a> in spite of the xml:space='default'
attribute.  The xml:space attribute is advice to the application
that ultimately consumes the element, whereas xmlspace is
a directive (stronger than advice) to the XQuery engine constructing
the element.  The user must use both in order to get any
particular desired result.

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Recommend to reject. We have decided that xml:space is treated as an ordinary attribute that does not affect the content of the constructed node. The document states this rule. I do not think that we need examples to illustrate this lack of effect.

qt-2004Feb0853-01: ORA-XQ-148-E: suggestion: make all whitespace explicit in the EBNF
[editorial, decided] 2004-05-11
SECTION A.2.1: white space rules

Whereas:

a) the whitespace rules for XQuery are so complex
(What is "ignorable whitespace"? How will the user learn
that he can put a comment between a $ and a QName, but not
between "for" and "$"?  What is the difference between
"whitespace: explicit" and "whitespace: significant"?
Do the XQuery whitespace rules govern EBNF's that are quoted
from other documents that don't have XQuery conventions?)

b) there are different whitespace rules for so many
different cases (in direct element constructors not nested within an
enclosed expression; in other kinds of direct constructors;
in comments, pragmas, and must-understand extensions;
in keyword phrases that are necessary for disambiguation;
in all other contexts -- I think I got them all, but I am not
sure).

My suggestion is that you give up on implicit whitespace rules
in the EBNF, and go with totally explicit whitespace in every
EBNF.  You already have S to represent spaces, tabs and newlines.
To that you can add other symbols.  For example IWS might stand
for what you call "ignorable whitespace".
I think IWS ::= S | Pragma | MUExtension | ExprComment.
Now given S and IWS, you can clearly write
ForClause ::= "for" S? "$" IWS? Varname IWS? TypeDeclaration? ...
etc., which clearly shows that a comment is not allowed between
"for" and "$".

You can also clear up the nesting possibilities of comments,
pragmas and must-understand extensions.  E.g., is it
Pragma ::= "(::" S? "pragma" S? QName S? ...
or is it
Pragma ::= "(::" IWS? "pragma" IWS? QName IWS? ...

- Steve B.
Proposal accepted.  See http://lists.w3.org/Archives/Member/w3c-xsl-wg/2004Jun/0069.html.

            


            

qt-2004Feb0852-01: ORA-XQ-091-E: unclear when all implementations must raise non-type-related static errors
[editorial, decided] 2005-01-20
SECTION 2.6.2: static typing feature

Second sentence: "However, non-type-related static errors must
be detected and raised during the static analysis phase."
It is unclear whether this applies only to implementations that
support the static typing
feature, or to all implementations.  I think you mean the latter
(if not, this sentence belongs within the Definition).
In that case, it would read better as: "All XQuery implementations
must detect and raise non-type-related static errors during the
static analysis phase."

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

[unclear when all implementations must raise non-type-related static errors] Status: Overtaken by events. Section has been rewritten and the referenced sentence no longer exists.

qt-2004Feb0851-01: ORA-XQ-090-E: please rewrite as a positive rather than a double negative
[editorial, decided] 2005-01-20
SECTION 2.6.2: static typing feature

First sentence: "[Definition: An XQuery implementation that does
not support the Static Typing Feature is not required to raise
type errors during the static analysis phase.]"  This
would read better if stated positively: "An XQuery implementation
that supports the Static Typing Feature is required to raise
type errors during the static analysis phase."

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Accepted and implemented.

qt-2004Feb0850-01: ORA-XQ-139-E: confusing use of "vs." in gn:xml-version
[editorial, decided] 2005-01-20
SECTION A.1.1: grammar notes

grammar-note: xml-version
It says "The general rules for [XML 1.1] vs. [XML 1.0],
as described in A.2 Lexical structure, should be applied...".
The word "vs." is confusing.  When I first read this, I
thought you meant "The general rules for [XML 1.1], and not
the general rules for [XML 1.0], should be applied...".
However, consulting section A.2, I think what you mean is
"It is implementation-defined whether the general rules for
[XML 1.0] or [XML 1.1] are applied, as described in section
A.2...".

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Accepted and implemented.

qt-2004Feb0849-01: ORA-XQ-144-E: in ws:explicit, comments, pragmas and must-knows are not whitespace
[editorial, decided] 2004-06-13
SECTION A.2.1: white space rules

It would be helpful to state in Rule "ws: explicit"
that comments, pragmas and must-know extensions are not
whitespace, as the term is understood for any rule marked with
this annotation.  The only thing that is meant by whitespace
for the sake of this rule is S, which does not include comments,
pragmas or must-know extensions.

- Steve B.
We looked at Scott's modified text.

Don: What about "1(: hello :)2"? Treat it as 12 in element constructor?

Scott: yes, in element constructor, not in other contexts such as let

Accepted.

            

We looked at Scott's modified text.


            

[[accepted]]

qt-2004Feb0848-01: ORA-XQ-129-E: need hot links for "name expression" and "content expression"
[editorial, decided] 2005-01-20
SECTION 3.7.3.1: computed element constructor

The sentence after rule [100] says "The name expression of a
computed element expression is processed as follows...".
Just looking at this section, it seems that
the term "name expression" is not defined.  Actually, it is
defined, in section 3.7.3 "Computed constructors".  Providing
a hot link to the definition of name expression would be useful.
Likewise for content expression later in this section,
and similarly for the other kinds of computed constructors.

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Accepted and implemented.

qt-2004Feb0846-01: ORA-XQ-135-E: "should be regarded" should not be used
[editorial, decided] 2004-04-27
SECTION A.1: EBNF

First para, last sentence: "This appendix should be regarded as
normative...".  I think it is better to avoid the word "should".
Just say "This appendix is normative...".



- Steve B.

            

See [435]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: adopted ACTION A-SJ04-29 Don to change "should be regarded as" to "is"


            

[[accepted]]

qt-2004Feb0844-01: ORA-XQ-122-E: "element content" is a defined term with a conflicting meaning in XML 1.0
[editorial, decided] 2005-01-20
SECTION 3.7.1.4: whitespace in element content

This section uses the phrase "element content", which is a term
defined in XML 1.0 section 3.2.1 "element content" as
"[Definition: An element type has element content when elements
of that type must contain only child elements (no character
data), optionally separated by white space (characters matching
the nonterminal S.]".  The XQuery working draft, on the other
hand, has no definition for "element content", either explicitly
or by reference to XML 1.0.  It seems in the present section
that your use of "element content" is not the same as the
definition in XML 1.0.  For one thing, XML 1.0 uses the phrase
"element content" only with reference to validated XML, whereas
you use it only with reference to the result of a direct
element constructor, which is unvalidated.  I think you mean
"the content of an element" whereas XML 1.0 means "content
which consists solely of elements and whitespace".

I grant that your use of "element
content" is probably closer to ordinary English usage than XML
1.0's, but having two conflicting meanings for the same phrase
in these two specifications will be very confusing.  There will
be dialogs in which one person means the XML 1.0 meaning and
the other person means the XQuery meaning, and the two people will
have to go through a lot of discussion before they realize they are
not using the words to mean the same thing.  There will be
people who misunderstand the XQuery specification because of
prior familiarity with XML 1.0, and vice versa.  Since XML 1.0
is already a recommendation, I suggest you find some other phrase,
such as "content of an element", and avoid "element content".

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests that we stop using the common English term "element content" because its meaning has been pre-empted by XML 1.0. Status: Accepted and implemented.

qt-2004Feb0843-01: ORA-XQ-118-E: namespace declaration attributes, improvement on the example
[editorial, decided] 2005-01-20
SECTION 3.7.1.2: namespace declaration attributes

It would be better if the example showed both ways to get a
namespace declared for an element constructor, using both the
prolog and a namespace declaration attribute, like this:

declare namespace metric="http://example.org/metric/units";
<box xmlns:english = "http://example.org/english/units">
  <height> <metric:meters>3</metric:meters> </height>
  <width> <english:feet>6</english:feet> </width>
  <depth> <english:inches>18</english:inches> </depth>
</box>

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Suggests that an example, intended to illustrate namespace declaration attributes, also illustrate prolog namespace declarations at the same time. Status: Recommend to reject. This example illustrates the intended feature. Other features are described and illustrated elsewhere.

qt-2004Feb0842-01: ORA-XQ-117-E: attributes must have distinct expanded QNames
[editorial, decided] 2005-01-20
SECTION 3.7.1.1: Attributes

Second para, last setence: "All the attribute nodes ... must
have distinct names".  More precisely, they must have distinct
expanded QNames, as explained in section 5.3 of "Namespaces
in XML" or section 6.3 of "Namespaces in XML 1.1".


- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Accepted and implemented.

qt-2004Feb0841-01: ORA-XQ-108-E: 3.1.6 comments, does not belong beneath section 3, "Expressions"
[editorial, decided] 2004-03-24
SECTION 3.1.6: Comments

This section appears to be misplaced, since it says that
"Comments may be used anywhere ignorable whitespace is allowed."
I assume this means they can be used in the prolog as well
as in expressions.  In that case, this section is broader in
scope than just expressions, so it does not belong as a
subsection of section 3 "Expressions" or (worse) 3.1 "Primary
Expressions".  On the other hand, direct
element constructors are part of the expression syntax, yet
ExprComments are not allowed in them.  Thus the connection
between ExprComments and expressions is a non-connection in
both directions: you can have comments outside expressions,
and sometimes you can't have comments within expressions.

- Steve B.
            

Don will change the status quo to make the explanation better.


            

Some discussion of whether or not PW's proposal addresses this issue. ScB: This issue is where do we discuss comments in the document? DC: I'm abstaining on how comments should be treated in the grammar, but I am in sympathy with this comment. Right now comments are documented as a sub-category of primary expression. Really they're broader than that. I'm willing to do that. JR: There are productions for comments and they're part of the grammar. PC: This item is clearly only about where comments are described. Accepted: Don will change the status quo to make the explanation better.

qt-2004Feb0840-01: ORA-XQ-105-E: "query" not defined
[editorial, decided] 2005-01-20
ORA-XQ-105-E: "query" not defined, Stephen Buxton (2004-02-17)
SECTION 3: Expressions

Third para: "a query may consist..."  The term "query" is not
defined.  Perhaps this sentence is (part of) the definition.
But in that case "may" seems like the wrong word.  The
definition of "query" might be something like
"[Definition: a query consists of one or more modules.]"


- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests a definition of the term "query". Status: Accepted and implemented.

qt-2004Feb0839-01: ORA-XQ-101-E: Improper definition, must-understand extension
[editorial, decided] 2005-01-20
SECTION 2.6.6 : must-understand extensions

Definition, last sentence: "A must-understand extension may be
used anywhere that ignorable whitespace is allowed."
This does not belong in a definition.
A definition tells how to recognize when something is present,
or how to construct it, but
not where it is permitted to be present.  This is like saying
"[Definition: a human being is a talking biped.  A human
being may be in Antarctica.]"


- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests a better definition for must-understand extensions. Status: Overtaken by events. Must-understand extensions no longer exist.

qt-2004Feb0838-01: ORA-XQ-093-E: Please explain the grammar note and whitespace rule conventions
[editorial, decided] 2004-04-27
SECTION 2.6.5: pragmas

Rule [1] "Pragma" is followed by a C-style comment
/* gn:parens */.  I think this is the first rule in the specification
with such a comment.  What does this mean?  I expected to find a
section near the beginning of the specification, possibly called
"Conventions" or the like, to explain your metalanguage.
I see that XML 1.0 did something similar with their
VC and WFC notes, which was never explained as a convention
either, but at least they put the specification of the
validity constraint or well-formedness constraint shortly
after the occurrence of the VC or WFC note.
In your case, it turns out that you have placed all the
/* gn: ... */ in one place, in Appendix A.1.1. "Grammar
notes".  Similarly the /* ws:... */ comments are collected
in Appendix A.2.1 "White space rules".  It would help the reader
to have a conventions section near the beginning to explain
this convention.  Perhaps your reply is that you already have
hot links on these things.  That is fine for people reading the
document on the web, but not everyone wants to read the spec
in a browser.  The problem with browsers is that it is difficult
to flip back and forth between sections, which is fairly easily
done in hardcopy with sticky notes, or just a finger or pen stuck
between pages.  Hot links do not justify never explaining your
conventions.

- Steve B.

            

excerpt:

Andrew: could these comments be filtered out altogether and be put in the summary instead? Jonathan: everything must be completely specified and be as clear as possible. I'd rather give the editors a chance to play with this than give a specific solution. Scott: I tend to like Andrew's idea, as it unclutters the exposition a little bit. Don: I'm pretty neutral on this Proposals: (1) amend the text up front to explain what the comments are (2) put the comments only in the section that's already prefaced with a comment that explains them. ACTION on Don and Scott to choose and implement one of these.

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

Proposals:

(1) amend the text up front to explain what the comments are

(2) put the comments only in the section that's already prefaced with

a comment that explains them.

ACTION A-SJ04-28 on Don and Scott to choose and implement one of these.


            

[[accepted]]

qt-2004Feb0835-01: ORA-XQ-083-E: Improper use of "has the nilled property"
[editorial, decided] 2005-01-20
SECTION 2.4.4.3 : Matching an ElementTest and an Element Node

List item 2)b) says
"...if the given element node has the nilled property...".
This condition is always true; every element node has a
nilled property (though the value of the nilled property may be false).
What is meant is "...if the nilled property of the element node
is true...".

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests change in semantics of nilled property in element tests. Status: Overtaken by events. This section has been rewritten.

qt-2004Feb0827-01: ORA-XQ-081-E: improper use of "in the data model"
[editorial, decided] 2005-01-20
SECTION 2.2.5 : Consistency constraints

second para, definition: "...For a given node in the data model..."
But the data model is an abstraction, and it is not particular to the
run-time environment in which an expression is evaluated.
A node, on the other hand, is a data value, found in the run-time
environment.  Thus "in" can not mean any kind of physical or
logical containment in the phrase "node in the data model".
What you probably mean is "node, as defined by the Data Model
specification."  But there is no need to qualify
every occurrence of "node" with such a phrase, because the only
data that XQuery considers is data that conforms to the Data
Model specification.  Thus this sentence reduces to just "for a given
node".

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Requests deletion of certain occurrences of this phrase. Status: Accepted and implemented.

qt-2004Feb0820-01: ORA-XQ-057-E: Inconsistent use of bolding
[editorial, decided] 2005-01-20
ORA-XQ-057-E: Inconsistent use of bolding, Stephen Buxton (2004-02-17)
SECTION no specific location

Words and phrases appear in bold throughout the document.
There is no description of the convention being followed.
It appears to be that a bolded word or phrase has a formal
definition somewhere.  There does not appear to be a consistent
convention about whether a bolded phrase is appearing in its
own definition, or the definition is merely being referenced.
For example, most of the bolded words in section 2 "Basics"
appear within the [Definition:...] convention, which is fairly
self-explanatory (although widely misused for things that are
not really definitions at all, but that is the
subject of other comments).  On the other hand, in section 3.7.3
"Computed constructors", the phrases "name expression" and
"content expression" are bolded, and their definitions are here,
though not enclosed in the [Definition: ...] convention.
These same phrases appear in other passages in bold, where they
are to be understood as references back to the definition.
The point is that there is no consistency about how to tell
whether a use of bolding indicates a definition, or a reference
to a definition.  By way of contrast, a common convention is that
a term is italicized when it is being defined, and not italicized
when it is being referenced.

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Observes that some bold terms appear in definitions and some do not. Status: This is true and I have a work item to invest more effort in adding termdefs and termrefs to the document, but I do not consider this to be high-priority work. I do not think this work is a prerequisite to entering Last Call.

qt-2004Feb0818-01: ORA-XQ-058-E: improper definitions
[editorial, decided] 2005-01-20
ORA-XQ-058-E: improper definitions, Stephen Buxton (2004-02-17)
SECTION no specific locaton: none

Many of the things called definitions are not.  A definition
should tell a reader how to recongize something when he
comes across it, or how to find or construct a thing.
Consider this definition from 2.4.4.4 "Matching an AttributeTest..."
"[Definition: An AttributeTest is used
to match an attribute node by its name and/or type.]"
This is like saying "[Definition: a bulldozer is used to move
dirt.]"  A true fact, but I still don't know a bulldozer
when I see one, nor how to build a bulldozer.  If all I had was
this definition, I might think a shovel or a dump truck was
a bulldozer.  Coming back to the definition I cited,
the actual definition of AttributeTest is found in rule [130].
Perhaps the things defined by EBNF need no [Definition:...].

Eliminating definitions of things defined in the EBNF would be
a start, but there are many other improper definitions.
Consider setion 2.6.6 "Must-understand extensions", first
para: "[Definition: An implementation may extend XQuery
functionality by supporting must-understand extensions.
A must-understand extension may be used anywhere that
ignorable whitespace is allowed.]"  This is not a definition,
it is discussion of the properties of a must-understand extension.

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Gives two examples of non-helpful definitions and claims there are many more. Status: The two examples cited have been eliminated. If further changes are required, please submit specific change proposals.

qt-2004Feb0802-01: [XQuery] MS-XQ-LC1-147
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-147, Michael Rys (2004-02-17)
Appendices
Editorial

Some appendices seem to be explicitly marked as non-normative. Some that
are not marked should be marked so as well: E.g. the precedence table,
the glossary etc.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Partially done. Normative vs. non-normative must be specified at the level of a whole appendix, and all the normative appendices must come before any non-normative ones. I made the error-code appendix normative and the glossary non-normative, and moved the error-code appendix before the glossary appendix.

qt-2004Feb0800-01: [XQuery] MS-XQ-LC1-145
[editorial, decided] 2004-04-27
[XQuery] MS-XQ-LC1-145, Michael Rys (2004-02-17)
Appendix A.1 EBNF
Editorial

Is there a reason why "$" is outside of the production of VarName? We
can still use something like <"for" VarName> to indicate the necessary
token lookahead and define VarName as "$" QName.

            

RESOLUTION: closed, rejected. See [450]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: closed, rejected


            

[[rejected]]

qt-2004Feb0797-01: [XQuery] MS-XQ-LC1-142
[editorial, decided] 2004-04-27
[XQuery] MS-XQ-LC1-142, Michael Rys (2004-02-17)
Section 4.12 Function Declaration
Editorial

Non-normative [120]: Why is it (")" | (")" "as" SequenceType))  and not
")" ( "as" SequenceType)?

            

See [432], excerpt:

Because the long token has to transit to lexical state ITEMTYPE. Can he live with it? RESOLUTION: qt-2004Feb0797-01 closed with no action Microsoft can live with not making the change.

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: qt-2004Feb0797-01 closed with no action Microsoft can live

with not making the change.


            

[[rejected]]

qt-2004Feb0793-01: [XQuery] MS-XQ-LC1-139
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-139, Michael Rys (2004-02-17)
Section 4.10 xmlspace declaration
Editorial/Technical

"The xmlspace declaration in a Prolog controls whether boundary
whitespace is preserved by element and attribute constructors during
execution of the query" -> "The xmlspace declaration in a Prolog
controls whether boundary whitespace is preserved by element and
attribute constructors during parsing of the query"

Also: renaming this property to boundary space or xquery whitespace is
acceptable (see Oracle comment).
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Partially done. Changed "execution of query" to "processing of query". Whitespace preservation does not apply only to parsing, but to the semantics of element construction. Details are found in "Content" subsection of Direct Element Constructors.

qt-2004Feb0795-01: [XQuery] MS-XQ-LC1-138
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-138, Michael Rys (2004-02-17)
Section 4.8	Variable Declaration
Editorial

"All variable names declared in a library module must be explicitly
qualified by the namespace prefix of the module's target
namespace.[err:XQ0048] ": It should be the namespace URI and not prefix
that drives this.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0788-01: [XQuery] MS-XQ-LC1-133
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-133, Michael Rys (2004-02-17)
Section 4.6	Schema Import
Editorial

The Note on static typing and DTD is a bit unmotivated. Why do we need
to say this here? We have not mentioned DTDs before. Please either
remove or make the context more relevant.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0787-01: [XQuery] MS-XQ-LC1-132
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-132, Michael Rys (2004-02-17)
Section 4.5	Default Namespace Declaration
Editorial

"The effect of declaring a default function namespace is that all
functions in the default function namespace, including
implicitly-declared constructor functions, are aliased with a name that
has the original local name, but no namespace URI. ": This is a weird
way of explaining that the syntactic name resolver will add the
namespace URI given as the default if no prefix is specified. Please
reword this sentence.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. It suggests rewording a sentence that was debated for a long time. Since this was a contentious issue it should be changed only by consensus of the working group.

qt-2004Feb0786-01: [XQuery] MS-XQ-LC1-131
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-131, Michael Rys (2004-02-17)
Section 4.5	Default Namespace Declaration
Editorial

"The string literal used in a default namespace declaration must be a
valid URI [err:XQ0046], and may be a zero-length string.[err:XQ0046] ":
Remove double reference to error. Also see comment MS-XQ-LC1-127
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0785-01: [XQuery] MS-XQ-LC1-130
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-130, Michael Rys (2004-02-17)
Section 4.4	Namespace Declaration
Editorial

Please change
"The output of the above query is as follows.

<foo:bing> Lentils </foo:bing>" to

"The output of the above query is as follows.

<foo:bing xmlns:foo="http://example.org"> Lentils </foo:bing>"
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0782-01: [XQuery] MS-XQ-LC1-127
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-127, Michael Rys (2004-02-17)
Section 4.3	Base URI Declaration
Editorial/Technical

Please rewrite "A static error [err:XQ0046] is raised if the string
literal in a base URI declaration does not contain a valid URI." to "A
static error [err:XQ0046] should be raised if the string literal in a
base URI declaration does not contain a valid URI." Note that we do not
require URI format checks in other contexts either.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. It suggest changing "an error is raised" to "an error should be raised". The error and its triggering condition remain the same. I see no motivation for making this change.

qt-2004Feb0781-01: [XQuery] MS-XQ-LC1-126
[editorial, decided] 2004-10-17
[XQuery] MS-XQ-LC1-126, Michael Rys (2004-02-17)
Section 4.2	Module Declaration
Editorial

"The names of all variables and functions declared in a library module
must be explicitly qualified by the target namespace
prefix.[err:XQ0048]": When is the error called? What happens with
variables and functions inside a library module that does not have the
same namespace? Also, please do require the targetnamespace URI and not
the prefix to be the same.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0713-01: ORA-DM-346-B: Prefix Bindings values are out of synch with what is defined in XQuery 1.0 spec
[editorial, decided] 2005-01-20
SECTION 2.2.1 : Prefix Bindings

fn:  is bound to
http://www.w3.org/2003/05/xpath-functions
It should be
http://www.w3.org/2003/11/xpath-functions
as defined in the XQuery 1.0 language spec.

In general, it is better to refer these common prefix bindings
to XQuery 1.0 language spec.

- Steve B.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Overtaken by events. Each new version of the specification updates these URIs with new dates.

qt-2004Feb0699-01: ORA-XQ-339-C: Should "/a/(1 to 5)[2]" raise type error?
[editorial, decided] 2004-10-17
SECTION 3.2.1: Steps

It says in section 3.2, "This sequence of steps is then evaluated from left to right. Each operation E1/E2 is evaluated as follows: Expression E1 is evaluated, and if the result is not a sequence of nodes, a type error is raised." So query "/a/(1 to 5)[2]" should raise a type error because (1 to 5) does not return a sequence of nodes.

However, it also says in section 3.2.1, "A filter step consists simply of a primary expression followed by zero or more predicates. ... This result may contain nodes, atomic values, or any combination of these." This should be clarified, e.g. by saying "a filter step must return a set of nodes when used in a path expression."


- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Overtaken by events. Filter steps are now called filter expressions and are described separately from path expressions.

qt-2004Feb0693-01: ORA-XQ-246-C: add more examples explaining why "let $i:= $i +1" is unintuitive in XQuery
[editorial, decided] 2004-10-17
SECTION 3.1.2: Variable References

Consider the following query:
for $j in (1,2) let $i:= $i +1 return <foo>{$i}</foo>

This  raises a dynamic error because the $i on the right is not
bound yet. This is based on 3.8 Flwor expression rule
on variable scope: "The scope does not include
the expression to which the variable is bound".
However, this is counter-intutive for users
who are used to procedural programming
and now work on XQuery which is a functional language.

It would be better to list this as an example to explain why
the variable reference of $i on the right results in dynamic errors.


- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

I recommend rejection of this comment. It suggests inserting an example into Section 3.1.2 that requires understanding of FLWOR and constructor expressions, which have not been introduced yet. This example would be helpful in a tutorial, but it is not necessary in a specification.

qt-2004Feb0692-01: ORA-XQ-245-E: predefined namespace needs to add xml
[editorial, decided] 2004-10-17
SECTION 2: Basics

There is a list of predefined namespace prefixes stated in
Basics.
It should add
xml = http://www.w3.org/XML/1998/namespace
as well, which is consistent with 4.4

- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0685-01: ORA-XQ-237-C: Validation of element constructed by direct element constructor should cross reference 3.13 Validate Expr
[editorial, decided] 2004-10-17
SECTION 3.7.1.5: Type of a constructed element

In 3.7.1.5, the spec states how the type of a constructed element
is assigned via automatic schema validation process. The
conceptual description here is more or less repeated from
3.13 validate expression.
It would be better if the spec made a cross reference to 3.13
here. If there are any inconsistencies between the two, then
3.13 validate Expression should be considered normative.

- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Overtaken by events. Automatic validation is gone.

qt-2004Feb0681-01: ORA-XQ-233-C: Orderspec should specify that empty sequence is considered as the same type as other tuples
[editorial, decided] 2004-10-17
SECTION 3.8.3: Order by and Return Clauses

In 3.8.3, it has a rule stated as:
"Each orderspec must return values of the same type for all
tuples in the tuple stream".
Later, the orderspec considers the special values in the orderspec,
such as empty sequence.
Then, empty sequence should be considered the same type as
for all other tuples in the tuple stream.

Suggested rewording:
"For each position in the tuple, there must exist an atomic type for which the gt operator is defined, such that the value of the orderspec in that position is either the empty sequence or can be promoted to that atomic type".

Consider a tuple stream of 2 tuples, the first tuple is empty sequence and the second tuple is an atomic
value with type "xs:string" and typed value is "cat". From the spec,
it is not clear if this tuple stream is legal for order unless we
state that empty sequence is considered the same type as
'xs:string' in this case.


- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0680-01: ORA-XQ-232-E: Typeswitch needs to specify its special rule for propagating dynamic errors
[editorial, decided] 2004-10-17
SECTION 3.12.2: Typeswitch

In 2.5.3 Errors and Optimizations:
"To avoid unexpected errors caused by reordering of expressions, tests that are designed to prevent dynamic errors should be expressed using conditional or typeswitch expressions. Conditional and typeswitch expressions raise only dynamic errors that occur in the branch that is actually selected."
And in 3.10 Conditional Expressions:
"Conditional expressions have a special rule for propagating dynamic errors...."
However, for 3.12.2 typeswitch, there is no similar paragraph
to state that typeswitch expressions have a special rule for propagating dynamic errors, that is, only the the branch that is actually selected can raise dynamic errors.


- Steve B.
Status of XPath and XQuery editorial comments, Don Chamberlin (2004-10-17)

            

Done.

qt-2004Feb0679-01: ORA-XQ-231-C: Need to specify the behavior of XPath context position matching predicate for unordered sequence
[editorial, decided] 2004-05-07
SECTION 3.9 : Unordered Expressions

Unordered Expressions, as defined in 3.9, returns a sequence of
items in a nondeterministic order.
Consider the following XQuery example defined in 3.2.2 Predicates
by applying the additional fn:unordered() function:

(fn:unordered(21 to 29))[5]

Since fn:unordered() returns a sequence in a nondeterminstic order,
it should be clarified that the result can be any integer
value between 21 and 29.
The behavior needs to be specified in 3.9 and 3.2.2.

- Steve B.

            

This comment from a participant (Steve Buxton, Oracle) asks for clarification about the non-determinance of application of fn:unordered() to certain expressions containing a predicate that is a numeric value. This comment is addressed in intent by the "unordered" proposal's specification of non-deterministic results when the "unordered{}" syntax is used. Because that usage is a syntactic shorthand for uses of fn:unordered(), the clear implication is that those uses of fn:unordered() also return non-deterministic results. Subject to proper application of the "unordered" proposal's specifications, this comment is resolved. I consider this comment to be resolved by the "unordered" proposal.

qt-2004Feb0662-01: ORA-XQ-157-B: undefined "input_stream.backup(1)"
[editorial, decided] 2004-04-27
SECTION A.2.2: lexical rules

OCCURRENCEINDICATOR state table, first row: There is no
description of what input_stream.backup(1) means.  This
should go in the explanatory material at the beginning of
this section.

- Steve B.

            

See [437]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: accepted, Scott to add explanation


            

[[accepted]]

qt-2004Feb0661-01: ORA-XQ-156-B: no pattern called NotOccurrenceIndicator
[editorial, decided] 2004-04-27
SECTION A.2.2: lexical rules

OCCURRENCEINDICATOR state table, first row: There is no
pattern called NotOccurrenceIndicator.  Probably what is meant
is 'anything except "?", "*" or "+"'.  A better way to
handle this would be to make this the last row of the table
rather than the first, and change the Pattern column to
something like "(anything other than "?", "*"
or "+")".



- Steve B.

            

See [440]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: accepted as per item 29 above


            

[[accepted]]

qt-2004Feb0658-01: ORA-XQ-153-B: rules for permissible comments etc. are not kind to humans
[editorial, decided] 2004-03-24
SECTION A.2.2: lexical rules

The rules in the tables do not appear to allow comments,
pragmas and must-know extensions as ignorable whitespace
in the middle of certain sequences of tokens.  For example,
in the DEFAULT state table, first row, last list item,
<"declare" "validation">, or more importantly, fourth row,
items <"for" "$">, <"let" "$">, <"some" "$">, <"every" "$">.
I believe the intention is to permit comments, pragmas and
must-know extensions in the midst of these token sequences.
Note that there is no recognition of just the first token
in these sequences ("declare", "for", "let", "some", "every")
so that for example

  for (: set up loop :) $i in fn:doc("...")

is unrecognizable by these tables, and presumably a lexical
error.  Glancing at the tables, it seems that whenever
you enclose a sequence of patterns in angle brackets <...>,
that it is not permitted to have a comment.  This seems far
too limiting.  How will users ever learn where they can insert
comments?

- Steve B.
Keep the status quo, but clarify that comments are allowed everywhere that implicit space is. Waiting detailed proposal.

            

ScB: Requesting approval for the intent. A proposal is needed for the details. MK: Jerome seemed to be the lone voice of opposition on this change. ScB: I'll give Jerome a call. ScB: Nothing points to the comment productions (from elsewhere in the grammar). ScB: I don't want to put it explicitly in the BNF, but we need more exposition. DC: These new words will go in the grammar part of the document and don't require any changes to the earlier sections. ScB: I'll start with the grammar appendix and we can review it to see if the change needs to go elsewhere. Accepted: We'll keep the status quo. Waiting detailed proposal. [Liam note: the minutes mention that this issue is closed in several places despite the words "Waiting detailed proposal"]

qt-2004Feb0653-01: ORA-XQ-146-Q: what is the difference between ws:explicit and ws:significant?
[editorial, decided] 2004-06-08
SECTION A.2.1: white space rules

It is hard to understand the distinction between /* ws:explicit */
and /* ws:significant */.  For example, rule [106] CDataSection
and rule [108] XmlComment have been labeled /* ws:significant */,
whereas rule [107] XmlPI is labeled /* ws:explicit */.  I don't
see any difference between these three things from the standpoint
of the XML 1.0 Recommendation.  What distinction are you trying to
make here?


- Steve B.
Accepted.
qt-2004Feb0652-01: ORA-XQ-145-B: "value content" not defined
[editorial, decided] 2004-06-08
ORA-XQ-145-B: "value content" not defined, Stephen Buxton (2004-02-16)
SECTION A.2.1: white space rules

The definition of /* ws:significant */ says it means "that
whitespace is significant as value content".  But "Value content"
is not defined.  Does it mean "the value of the non-terminal
on the left hand side of the indicated EBNF rule"?

- Steve B.
Accepted.
qt-2004Feb0650-01: ORA-XQ-142-C: which is "larger", XML 1.0 or 1.1?
[editorial, decided] 2004-04-27
SECTION A.2 : lexical structure

The first sentence characterizes the legal characters of XML 1.1
as forming a "larger set" than those of XML 1.0.  Actually,
it is the other way around: Char in XML 1.1 is a subset of
Char in XML 1.0 (a lot of characters called "discouraged" in
the XML 1.0 Errata have been removed in XML 1.1).

What you may be thinking of in this sentence is that
Name in XML 1.1 is a superset of Name in XML 1.0.  This is
true, but it is not exactly relevant, since XQuery never
references Name.  Instead, the basic component of your identifiers
is NCName, which is defined in either "Namespaces in XML"
(i.e., XML 1.0) or "Namespaces in XML 1.1".  Unfortunately,
D.2 "Normative references" does not reference the latter.

In summary, what I think you want for the first sentence is
"It is implementation defined whether
the lexical rules of [XML 1.0] and [XML Names] are followed,
or alternatively, the lexical rules of [XML 1.1] and
[XML Names 1.1] are followed." (using [XML Names 1.1] as the
normative reference to "Namespaces in XML 1.1").

There are other possible resolutions.  One would be that
implementations have two choices: 1. whether Char is XML 1.0
or XML 1.1, and 2. whether NCName is playing by 1.0 or 1.1 rules.
Another resolution would be that implementations
can choose either the most restrictive for both (ie, Char from
XML 1.1 and NCName from 1.0) or the most inclusive for both
(ie, Char from XML 1.0 and NCName from XML 1.1).

- Steve B.

            

See [462]

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: Adopted, Scott will remove the incorrect statement


            

RESOLUTION: Adopted, Scott will remove the incorrect statement

qt-2004Feb0649-01: ORA-XQ-141-C: gn:parens: lookahead of more than one character required
[editorial, decided] 2004-04-2004
SECTION A.1.1: grammar notes

grammar-note:parens says "a look-ahead of one character is
required to distinguish function patterns from a QName followed
by a comment."  You need to look ahead more than one character
in order to distinguish Pragma, MUExtension and ExprComment.

- Steve B.

            

See [117]. Yes, needs to be fixed. Waiting complete proposal from scott.

qt-2004Feb0648-01: ORA-XQ-140-C: gn:parens: lookahead also needed to distinguish keyword from function
[editorial, decided] 2004-04-2004
SECTION A.1.1: grammar notes

grammar-note:parens says "a look-ahead of one character is
required to distinguish function patterns from a QName followed
by a comment."  Look-ahead is also required to distinguish
between a function pattern and a keyword, for example
"for (: whom the bell :) $tolls =" is the beginning of a
ForClause.  That's using my notion of what "ignorable
whitespace" ought to be, not what it evidently is according
to A.2 Lexical rules.


- Steve B.

            

See [116]. Yes, needs to be fixed. Waiting complete proposal from scott.

qt-2004Feb0647-01: ORA-XQ-138-B: some EBNF rules stated better in XML 1.0 Recommendation
[editorial, decided] 2004-03-24
SECTION A.1: EBNF

Some of the non-terminals duplicate definitions found in XML 1.0,
namely rule [106] CDataSection is the same as rule [18] CDSect
in XML 1.0; rule [107] XmlPI is the same as rule [16] PI in
XML 1.0, and rule [108] XmlComment is the same as rule [15]
Comment in XML 1.0.  Actually, the rules are stated better in
XML 1.0, since that document is careful to exclude the
terminating symbols where your rules just have Char*.
It would be better to just cite the XML 1.0 definitions.

- Steve B.

            

Proposal fails, we keep the status quo.


            

ScB: I think it's a great idea to reference XML for those productions. I think we can work around any parsing obscurities. Proposal: make the change. MK: I feel uneasy, but I don't know why. DC: They make our document less self-contained. JR: Can we compromise by copying it directly? MK: Then we have the problem of which is normative. ScB: Personally, I'd rather just point to the XML spec. Proposal: make the change. Preference poll: 7=no change, 3=change, 5=abstain Proposal fails, we keep the status quo.

qt-2004Feb0614-01: ORA-XQ-112-C: "leading slash" issue not well defined
[editorial, decided] 2004-04-27
SECTION 3.2: path expressions

Seventh para (excluding rules [69] and [70]), last sentence
says "In general it is best to use parentheses when "/" is used
as the first operand of an operator, e.g., (/) * 5."

And in "grammar-note: leading-lone-slash" in A.1.1 we find:
"The "/" presents an issue because it occurs both in a leading position and an operator position in expressions. Thus, expressions such as "/ * 5" can easily be confused with the path expression "/*". Therefore, a stand-alone slash, in a leading position, that is followed by an operator, will need to be parenthesized in order to stand alone, as in "(/) * 5". "5 * /", on the other hand, is fine.
"

It will help to augment the example like this:
"4 + / * 5" is a parse error, because the slash, although it
appears following the + operator, is still the first operand of
the * operator.  On the other hand, "4 * / + 5" is not a
parse error, because it is equivalent to "(4 * /) + 5",
meaning that the slash is not the first operand of an
operator.

In "4*/*5", is the "/" a "leading slash" ?
Is "/div 2" legal ?

We recommend using "Should, Must or May" in place of e.g. "will need to be".


- Steve B.

            

See [439]. RESOLUTION: Don: use MUST as per comment. Add the 4 + / * 5 with blanks but not the (incorrect) 4 * / + 5 example. The way to avoid the parse error is to put ( ) around the leading slash to make (/).

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

Scott noted that the suggested examples in the comment may be

incorrect: 4 * / + 5 is also a parse error.

RESOLUTION: Don: use MUST as per comment. Add the 4 + / * 5 with

blanks but not the (incorrect) 4 * / + 5 example. The way to avoid the

parse error is to put ( ) around the leading slash to make (/).


            

[[accepted]]

qt-2004Feb0612-01: ORA-XQ-111-C: clarify whitespace is not the issue with leading slashes
[editorial, decided] 2004-09-26
SECTION 3.2 : path expressions

Seventh para (excluding rules [69] and [70]) says
"For instance, "/*" is an expression with a wildcard, and "/*5"
is a parse error".  It would help to mention that use of
whitespace will not alter this analysis: "/ *" is
an expression with a wildcard, but "/ * 5" is a parse error.


- Steve B.

            

See [438]. RESOLUTION: Don to add white space as described

[minutes from April meeting] 2004-04-22, Working Group Minutes (2004-04-22)

            

RESOLUTION: Don to add white space as described


            

[[accepted]]

XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0611-01: ORA-XQ-110-B: grammar note gn:parens as written does not apply to ExprCommentContent
[editorial, decided] 2004-09-26
SECTION 3.1.6: XQuery comments

Rule [4] ExprCommentContent refers to /* gn: parens */.  The
text of that grammar note does not appear to be relevant to
rule [4], since the grammar note only talks about distinguishing
a function from a comment.  Perhaps what is meant is that,
when processing the interior of a comment, if you encounter
"(", you need to look ahead one more character to see if the
"(" is part of ExprCommentContent or the beginning of a new
ExprComment.  If so, grammar note gn:parens needs to be enhanced
to discuss this issue.

- Steve B.
Proposal accepted.

            


            

[[accepted]]

XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. The referenced grammar note no longer exists.

qt-2004Feb0609-01: ORA-XQ-109-B: human-readable definition of "ignorable whitespace" is needed
[editorial, decided] 2004-09-26
SECTION 3.1.6: XQuery coments

It says that "Comments may be used anywhere ignorable whitespace
is allowed" but there is no definition of ignorable whitespace,
only a reference to section A.2 Lexical rules.  The rules in
that section are so dense that most readers will find them
unintelligible.  It would be helpful to provide a reader-friendly
definition of "ignorable whitespace".


- Steve B.
Accepted.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Requests a reader-friendly definition of "ignorable whitespace." Unfortunately I do not know such a definition. The technical definition in Appendix A.2 is referenced. If the submitter of this comment can make this definition reader-friendly, I encourage him to submit a specific wording.

qt-2004Feb0594-01: ORA-XQ-094-C: grammar note gn:parens does not seem to apply
[editorial, decided] 2004-09-26
SECTION 2.6.5: pragmas

Rule [1] Pragma has an attached grammar note gn:parens, but the
text of that grammar note does not appear to be relevant, since
the grammar note only talks about distinguishing function calls
from comments.  Perhaps the note needs to talk about doing
two character look-ahead to distinguish function calls, comments
and pragmas.  Though that is still not enough look-ahead, because
you also have MUExtensions to distinguish.  This requires
scanning over indefinitely long whitespace (which might itself
be comments) before you come to the keywords "pragma" or
"extension".

- Steve B.
Proposal accepted.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. The referenced grammar note no longer exists.

qt-2004Feb0588-01: ORA-XQ-082-E: undefined term "data model node"; just "node" is correct
[editorial, decided] 2004-09-26
SECTION 2.2.5 : Consistency constraints

First bullet: "for every data model node...": what is a "data
model node"?  I think this term is undefined; I think
the term you want is just "node".  The second bullet also uses
this term.  I suggest searching for "data model" and checking
that each use is correct.

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0586-01: ORA-XQ-079-E: (ab)use of "data model" (2)
[editorial, decided] 2004-09-26
ORA-XQ-079-E: (ab)use of "data model" (2), Stephen Buxton (2004-02-16)
SECTION 2.2.5 : Consistency constraints

First sentence: "In order for XQuery to be well defined, the data
model, the static context, and the dynamic context must be
mutually consistent."  This is a misuse of the term "data model".
The data model is an abstract framework, whereas the static
context and dynamic context are values present in the run-time
environment of the evaluation of an XQuery expression.  Presumably what you mean is that the data (not the data model) must be consistent with the static and dynamic contexts.

Perhaps changing "data model" to "data model instance" in this location would resolve the issue?


- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0584-01: ORA-XQ-077-E: undefined term "query"
[editorial, decided] 2004-09-26
ORA-XQ-077-E: undefined term "query", Stephen Buxton (2004-02-16)
SECTION 2.2.3.2 : Dynamic evaulation phase

The second sentence refers to "the value of the query".  "Query"
is undefined; perhaps you mean "the value of the expression".

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0582-01: ORA-XQ-075-E: "area labeled the external processing domain"
[editorial, decided] 2004-09-26
SECTION 2.2 : Processing model

The paragraph below the figure mentions "an area labeled the
external processing domain".  Actually, it is labeled just
"External Processing".  Similarly the label inside the thick
black line is "Query Processing", not "query processing domain".


- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0578-01: ORA-XQ-074-E: (ab)use of term "data model"
[editorial, decided] 2004-09-26
ORA-XQ-074-E: (ab)use of term "data model", Stephen Buxton (2004-02-16)
SECTION 2.2: processing model

First para after figure 1, third sentence:
"The external processing domain includes the generation
of the data model".  But the data model is an
abstract framework describing the kind of data found
during an XQuery execution.  Confer "XQuery 1.0 and
XPath 2.0 Data Model" Introduction, second para, for
a definition of "data model".  If anything "includes
the generation of the data model" it has been the
W3C group working on that specification.
Perhaps what you mean here is "The external processing domain
includes the generation of the data."
Of course, the data forms a time-varying collection
of values, so it might be more accurate to say
"The external processing domain includes the
generation of the initial values of the data."

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0573-01: ORA-XQ-072-E: undefined terms "query" and "transformation"
[editorial, decided] 2004-09-26
SECTION 2.1.2: dynamic context

The definition of "current date and time" refers to "processing
of a query or transformation".  These are undefined terms.
Section 2 "Basics" first sentence says that the "basic building
block of XQuery is the expression".  What is the relationship
between expression, query and transformation?

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Partially done. All references to "transformation" have been made XPath-only. The assumption is that XSLT users will understand the concept of a transformation, and XQuery users will understand the concept of a query.

qt-2004Feb0566-01: ORA-XQ-071-E: wording: "in a path expression"
[editorial, decided] 2004-09-26
ORA-XQ-071-E: wording: "in a path expression", Stephen Buxton (2004-02-16)
SECTION 2.1.2: dynamic context

It says "the context item is the item currently being processed
in a path expression".  But a path expression is a piece of syntax,
and an item is a value, so an item is not "in" a path expression.
I think you mean "the item currently being processed in the
evaluation of a path expression".  Similarly in the definitions of
context position and context size.



- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Fixed as a side effect of processing another comment. These definitions no longer refer to path expressions.

qt-2004Feb0564-01: ORA-XQ-068-C: What if there is a top-level element called "global"?
[editorial, decided] 2004-09-26
SECTION 2.1.1: Static context

Validation context: said to be "either global or a context path
that starts with the name of a top-level element...".  What if
there is a top-level element called "global"?
I think you mean that the validation context consists
of two things: a flag, whose value is "global" or "not global",
and a path, which is ignored when the flag is "global".
Perhaps saying that the path starts with a QName (not just a
"name") would help, if that insures that "global" is never a
value of the lexical space of paths.

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. "Validation context" no longer exists.

qt-2004Feb0563-01: ORA-XQ-065-E: vague quantification in "a collation may be regarded"
[editorial, decided] 2004-09-26
SECTION 2.1.1: Static context

In-scope collations: it says that "a collation may be regarded...".
The use of "a" in "a collation", together with "may",
is not clear.  Is this universal quantification
("every collation may be regarded..."), existential
("there exists a collation that may be regarded...")
or just totally permissive ("perhaps there exists a collation
that may be regarded...")?

My own interpretation of your words is that you are not trying
to prescribe how a collation is implemented, but that, no matter
how it is implemented, it shall be open to the interpretation
that it is an object with two functions in its interface.
This might be better expressed "a collation is effectively an object
with two functions...".



- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0561-01: ORA-XQ-064-E: "may be regarded" may be regarded harmful
[editorial, decided] 2004-09-26
SECTION 2.1.1: static context

In-scope collations: it says that a collation "may be regarded...".
Unlike F&O, there is no definition of "may".  The F&O
definition ("Conforming documents and processors are permitted to,
but need not, behave as described") does not seem appropriate here.
Is an implementation permitted, but
not required, to "regard" a collation as an object with two
functions?  I don't think an implementation can "regard" anything,
since "regarding" is a mental act (though implementers, their
product literature and their users might have such a mental model).

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0555-01: ORA-XQ-062-E: possible typo: "environmentor"
[editorial, decided] 2004-09-26
ORA-XQ-062-E: possible typo: "environmentor", Stephen Buxton (2004-02-16)
SECTION 2.1.1: static context

I'm unsure if this is a typo in third and fourth
"hollow circle" bullets (those for default element/type namespace and default function namespace): "environmentor".
Should this be "environment or", or perhaps there is an undefined noun "environmentor", which presumably is something that creates or initializes the environment.


- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0549-01: ORA-XQ-219-E: Expression processing requires forward pointer to kinds of errors
[editorial, decided] 2004-09-26
SECTION 2.2.3: Expression Processing

2.2.3 refers to type errors, dynamic errors, static errors, which are defined in 2.5.1.
Suggest adding a line under the first paragraph of 2.2.3 saying "During expression processing, the following errors may be raised .... These errors are defined at 2.5.1"

- Steve B.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0531-01: [XQuery] MS-XQ-LC1-123
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-123, Michael Rys (2004-02-16)
Section 3.12.6 Treat
Editorial

Provide an example and motivation for treating across. An example for
treating across is: the static type is a union of T1 | T2 and you want
to pass this to a function that only allows T1.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests adding an example of "treat". I think the existing example is adequate. The suggested example uses a notation (T1 | T2) that has not been introduced in the language document. I would prefer to reject this comment.

qt-2004Feb0527-01: [XQuery] MS-XQ-LC1-119
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-119, Michael Rys (2004-02-16)
Section 3.12.3 Cast
Editorial

Use item, sequence of item or atomic value instead of value as
appropriate.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests avoiding the use of the word "value". Duplicate of comment 2004Jan/0146. I believe that the usages of the word "value" in this section are appropriate, and I think this comment should be rejected.

qt-2004Feb0526-01: [XQuery] MS-XQ-LC1-118
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-118, Michael Rys (2004-02-16)
Section 3.12.2 Typeswitch
Editorial

"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.
If the return expression does not depend on the value of the operand
expression, the variable may be omitted from the case or default
clause." : Please rewrite along the line of: "If return depends on
value, Variable is required, otherwise it does not matter"
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0525-01: [XQuery] MS-XQ-LC1-117
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-117, Michael Rys (2004-02-16)
Sections 3.12.2/3.12.6
Editorial

Add link to Sequence Type Matching. Also please attempt to make such
references more consistent across the document.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0524-01: [XQuery] MS-XQ-LC1-116
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-116, Michael Rys (2004-02-16)
Section 3.12 Expressions on SequenceTypes
Editorial

"This example returns true if the context item is an element node. If
the context item is undefined, a dynamic error is raised." : Also add
case when context item is not an element node but defined.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0523-01: [XQuery] MS-XQ-LC1-115
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-115, Michael Rys (2004-02-16)
Section 3.12 Expressions on SequenceTypes
Editorial

Replace
"<a>{5}</a> instance of xs:integer

This example returns false because the given value is not an integer;
instead, it is an element containing an integer."

with
"<a>{5}</a> instance of xs:integer

This example returns false because the given item is an element and not
an integer."

Note that the content of the element depends on schema and validation
context.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0522-01: [XQuery] MS-XQ-LC1-114
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-114, Michael Rys (2004-02-16)
Section 3.11 Quantified Expressions
Editorial

Make the term "effective boolean value" consistent in the document:
Either always bold, or always a link.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done. (But in some cases where "effective boolean value" appears multiple times in the same paragraph, I make only the first occurrence a link to avoid a cluttered appearance.)

qt-2004Feb0521-01: [XQuery] MS-XQ-LC1-113
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-113, Michael Rys (2004-02-16)
Section 3.11 Quantified Expressions
Editorial

Replace
(("some" "$") | ("every" "$")) VarName
with
("some" | "every") "$" VarName

In the non-normative grammar.
proposal accepted.  (Comment is rejected.)

            

We follow Scott's proposal instead.


            

[[rejected]]

XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

This is a requested grammar change that was rejected in joint telcon 183 on 5/11/04.

qt-2004Feb0519-01: [XQuery] MS-XQ-LC1-111
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-111, Michael Rys (2004-02-16)
Section 3.8.4 Example
Editorial/Technical

"for $a in fn:distinct-values($books)//author": is not correct.
Fn:distinct-values returns a list of atomic values and cannot be used in
a path expression.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0518-01: [XQuery] MS-XQ-LC1-110
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-110, Michael Rys (2004-02-16)
General Comment
Examples

We should reduce the amount of examples that use // and instead write
them with the full path. This is giving a bad example to users in cases
where a clear path exists.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Eliminated "//" operators from many examples by specifying more explicit paths. This was a fairly extensive change, and people will want to review it carefully during the internal review.

qt-2004Feb0517-01: [XQuery] MS-XQ-LC1-109
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-109, Michael Rys (2004-02-16)
Section 3.8.4 Example
Editorial

"The input bibliography is a list of books in which each book contains a
list of authors. ": Mention that it is bound to  the variable $books
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0514-01: [XQuery] MS-XQ-LC1-106
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-106, Michael Rys (2004-02-16)
Section 3.8.3 Order By and Return Clauses
Editorial

Please add to orderspec rules whether an orderspec may be a union of
promotable types (such as xdt:untypedAtomic | xs:string,
xs:integer|xs:double).
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0513-01: [XQuery] MS-XQ-LC1-105
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-105, Michael Rys (2004-02-16)
Section 3.8.1 For and Let Clauses
Editorial

Replace
"for $x in $w
let $y := f($x)
for $z in g($x, $y)
return h($x, $y, $z)
" with
"for $x in $w, $a in f($x)
let $y := f($a)
for $z in g($x, $y)
return h($x, $y, $z)
"

to show order in for list.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0512-01: [XQuery] MS-XQ-LC1-104
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-104, Michael Rys (2004-02-16)
Section 3.8.1 For and Let Clauses
Editorial

"for $i in (1, 2), $j in (3, 4)

The tuple stream generated by the above for clause ": Rewrite this into
a full XQuery expression. Same for example for "at".
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests that an example in the For-clause section that illustrates a For-clause should be expanded to a full XQuery expression. I believe this is not necessary and would make the example less clear rather than more clear.

qt-2004Feb0510-01: [XQuery] MS-XQ-LC1-102
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-102, Michael Rys (2004-02-16)
Section 3.7.3.7 Computed Namespace Constructor
Editorial

Wouldn't it be clearer if we move this into a subsection of the element
constructor? (see also comment: MS-XQ-LC1-081).
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. We no longer have computed namespace node constructors.

qt-2004Feb0509-01: [XQuery] MS-XQ-LC1-101
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-101, Michael Rys (2004-02-16)
Sections 3.7.3.5/3.7.3.6
Editorial

Show XML serialization of constructed node in examples.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0505-01: [XQuery] MS-XQ-LC1-097
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-097, Michael Rys (2004-02-16)
Section 3.7.3.2	Computed Attribute Constructor
Editorial

Replace "The value of the size attribute is "7"." with "The value of the
size attribute is "7" of type xdt:untypedAtomic."
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0504-01: [XQuery] MS-XQ-LC1-096
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-096, Michael Rys (2004-02-16)
Sections 3.7.1.*/3.7.3.*
Editorial

Can some of the constructor rules be expressed by using the
fn:string-join() function instead of prose?
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests an alternative approach to defining element constructors. The would be a big change, but the suggestion is not specific enough to act upon. I do not think there is anything broken about the current definition of element constructors. I would prefer to reject this comment.

qt-2004Feb0503-01: [XQuery] MS-XQ-LC1-095
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-095, Michael Rys (2004-02-16)
Section 3.7.3.2 Computed Attribute Constructor
Editorial

Replace "Atomization is applied to the value of the content expression"
with "Atomization is applied to the result of the content expression"
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0502-01: [XQuery] MS-XQ-LC1-094
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-094, Michael Rys (2004-02-16)
Section 3.7.3.1 Computed Element Constructor
Editorial

The two examples for constructed names seem redundant. Only keep one.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests deleting one of the two examples of computed element constructors (does not specify which one). I think both examples are helpful and illustrate different applications of computed constructors. I would prefer to reject this comment.

qt-2004Feb0501-01: [XQuery] MS-XQ-LC1-093
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-093, Michael Rys (2004-02-16)
Section 3.7.3.1 Computed Element Constructor
Editorial

It is not clear if the new element with twice the numeric content is
typed or not. Make this clearer.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

All constructed elements are untyped until they are validated. This is a change since the Last Call document that provoked this comment. I would make no change, and classify this comment as "overtaken by events."

qt-2004Feb0499-01: [XQuery] MS-XQ-LC1-091
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-091, Michael Rys (2004-02-16)
Sections 3.7.1.*/3.7.3.*
Editorial

Can we combine the common construction rules in one place and refer to
it in the other? That way we guarantee consistency.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0496-01: [XQuery] MS-XQ-LC1-088
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-088, Michael Rys (2004-02-16)
Section 3.7.1.4 Whitespace in Element Content
Editorial

"If xmlspace is not declared in the prolog or is declared as xmlspace =
strip, boundary whitespace is not considered significant and is
discarded.": Make this sentence dependent on xmlspace policy in static
context and not on value in prolog (since that may be given in an
implementation-defined place).
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0489-01: [XQuery] MS-XQ-LC1-081
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-081, Michael Rys (2004-02-16)
Section 3.7	Constructors
Editorial

"Constructors are provided for every kind of node in the data model
([XQuery 1.0 and XPath 2.0 Data Model]). ": We do not really provide a
namespace node constructor, only a namespace declaration component to
the element constructor.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. The XQuery document no longer discusses namespace nodes.

qt-2004Feb0487-01: [XQuery] MS-XQ-LC1-079
[editorial, decided] 2005-01-20
[XQuery] MS-XQ-LC1-079, Michael Rys (2004-02-16)
Section 3.5.3 Node Comparisons
Editorial

Example: //book[isbn="1558604820"] is //book[call="QA76.9 C3845"] will
statically fail. Provide static wording as well, eg
exactly-one(//book[isbn="1558604820"]) is
exactly-one(//book[call="QA76.9 C3845"]). Same for
//purchase[parcel="28-451"] << //sale[parcel="33-870"].
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

M.Rys requests that a type-safe form of a query example be added. The existing example compares books and parcels with specific keys, intending to suggest that they represent singleton values. Status: Recommend to reject. This is a special case of the working group decision not to require all our examples to be type-safe.

qt-2004Feb0482-01: [XQuery] MS-XQ-LC1-074
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-074, Michael Rys (2004-02-16)
Section 3.3.1 Constructing Sequences
Editorial

Make "In places where the grammar calls for ExprSingle, such as the
arguments of a function call, any expression that contains a top-level
comma operator must be enclosed in parentheses. " a note.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0481-01: [XQuery] MS-XQ-LC1-073
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-073, Michael Rys (2004-02-16)
Section 3.3.1 Constructing Sequences
Editorial

Please replace "A sequence may contain duplicate values or nodes" with
"A sequence may contain duplicate atomic values or nodes"
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0480-01: [XQuery] MS-XQ-LC1-072
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-072, Michael Rys (2004-02-16)
Section 3.3.1 Constructing Sequences
Editorial

Please replace "the resulting values, in order, into a single result
sequence" with "the resulting sequences, in order, into a single result
sequence".
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0479-01: [XQuery] MS-XQ-LC1-071
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-071, Michael Rys (2004-02-16)
Section 3.2.4 Abbreviated Syntax
Editorial

Please replace "// is effectively replaced by " with "// is
syntactically replaced by ". Otherwise we have a conflict with section
3.2 in the beginning.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

I don't see any conflict. Section 3.2 states that // is expanded according to the rules in Section 3.2.4, and Section 3.2.4 provides the rules. I think this comment should be rejected.

qt-2004Feb0478-01: [XQuery] MS-XQ-LC1-070
[editorial, decided] 2005-01-20
[XQuery] MS-XQ-LC1-070, Michael Rys (2004-02-16)
Section 3.2.4 Abbreviated Syntax
Editorial

Can I write section/@attribute(id)? Please also explain again what
child::section/attribute::attribute(id) means.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

M.Rys requests an explanation of the step attribute::attribute(id). Status: Recommend to reject. I think the description is sufficiently clear. The step searches on the attribute axis to find an attribute named id with any type annotation.

qt-2004Feb0476-01: [XQuery] MS-XQ-LC1-068
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-068, Michael Rys (2004-02-16)
Section 3.2.3 Unabbreviated Syntax
Editorial

", and otherwise selects nothing" is the case for all expressions.
Remove since explained in previous section.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

(changed "selects nothing" to "returns an empty sequence".)

qt-2004Feb0475-01: [XQuery] MS-XQ-LC1-067
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-067, Michael Rys (2004-02-16)
Section 3.2.3 Unabbreviated Syntax
Editorial

"child::node()": mention that no attributes are returned.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0474-01: [XQuery] MS-XQ-LC1-066
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-066, Michael Rys (2004-02-16)
Section 3.2.2 Predicates
Editorial

Please add an example that uses more than one predicate (e.g.,
E[p1][p2]) and where the second predicate depends on the context of the
first predicate.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

I don't understand "E[p1][p2] where the second predicate depends on the context of the first predicate". Predicates are independent. The result of E is filtered by p1, and the result of E[p1] is filtered again by p2. I think this comment should be rejected.

qt-2004Feb0472-01: [XQuery] MS-XQ-LC1-064
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-064, Michael Rys (2004-02-16)
Section 3.2.1.2 Node Tests
Editorial

"mixed" -> "interleaved" and add definition/reference to definition of
"interleaved".
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0470-01: [XQuery] MS-XQ-LC1-062
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-062, Michael Rys (2004-02-16)
Section 3.2.1.1 Axes
Editorial

"the preceding-sibling axis contains the context node's preceding
siblings, those children of the context node's parent that occur before
the context node in document order; if the context node is an attribute
node or namespace node, the following-sibling axis is empty": replace
following-sibling with preceding-sibling
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0469-01: [XQuery] MS-XQ-LC1-061
[editorial, decided] 2004-09-26
[XQuery] MS-XQ-LC1-061, Michael Rys (2004-02-16)
Section 3.2.1.1 Axes
Editorial

XQuery does not really expose namespace nodes. Should we remove them
from this discussion?
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0457-01: [XQuery] BEA_032
[editorial, decided] 2004-09-26
[XQuery] BEA_032, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 2.1.1 defines the signature of a function.
It is common practice to define the signature of a
function as the static types of the arguments and
of the results, and to not add the name of the function to it.
We suggest we eliminate the name of the function
from the signature.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Suggests removing function name from function signature in static context. But the name of the function is needed in the static context, and "function signature" is the name we have chosen for this context item. I think this comment should be rejected.

qt-2004Feb0456-01: [XQuery] BEA_031
[editorial, decided] 2004-09-26
[XQuery] BEA_031, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 3.8.3. says:

The order by clause is the only facility provided by XQuery for
specifying an order other than document order. Therefore, every query
in which an order other than document order is required must contain a
FLWOR expression, even though iteration would not otherwise be
necessary.


This statement is not true. The ",", i.e. the sequence concatenation
operator
creates sequences in other orders then the document order for example.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0452-01: [XQuery] BEA_027
[editorial, decided] 2004-09-26
[XQuery] BEA_027, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 3.7.3: references to xs:anyType and xs;anySimpleType
have to be replaced with xdt:untyped and xdt:untypedtomic.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done, but some references to xs:anyType and xs:anySimpleType remain in appropriate places.

qt-2004Feb0451-01: [XQuery] BEA_026
[editorial, decided] 2004-09-26
[XQuery] BEA_026, Daniela Florescu (2004-02-16)
XQuery: editorial, minor


Section 3.7.1.3 and 3.7.1.4  talk about the xmlspace declaration in the
query's prolog. This should be replaced with the xmlspace
property in the static context of the query instead.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0449-01: [XQuery] BEA_024
[editorial, decided] 2004-09-26
[XQuery] BEA_024, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 3.2.2  point 1 describes the case where the value of the
predicate
is numeric. We should make explicit that the two values have to be
equal via the
eq value comparison.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0447-01: [XQuery] BEA_022
[editorial, decided] 2004-09-26
[XQuery] BEA_022, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 2.4.4.3 talks about an element "having the nilability property".
This should be replaced with "having the nillability property being
true",
because all elements have the nillability property (some true, some
false).
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Overtaken by events. This section has been extensively rewritten.

qt-2004Feb0445-01: [XQuery] BEA_020
[editorial, decided] 2004-09-26
[XQuery] BEA_020, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 2.1.2 defines the context item as being the current item
being processed as part of a path expression.  This should not be
limited to path expressions. The current item can be used in any
Xquery expression.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0444-01: [XQuery] BEA_019
[editorial, decided] 2004-09-26
[XQuery] BEA_019, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 2 third paragraph states that the name of a node is
a Qname. It should be an optional Qname.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Wants the name of a node to be an "optional QName". Current text states that some nodes have names, and the name of a node is a QName. I believe these two statements, taken together, are accurate and complete. I think this comment should be rejected.

qt-2004Feb0443-01: [XQuery] BEA_018
[editorial, decided] 2005-01-20
[XQuery] BEA_018, Daniela Florescu (2004-02-16)
XQuery: editorial, major

First paragraph in section 2 notes that the language does not allow
variable substitution if the definition expression creates new nodes.
This is only a particular case where variable substitution (and
function inlining
in the same time) does not hold, but there are other causes: validation
context and element constructors with namespace declarations.

This particular "feature" of XQuery that the semantics of an expression
depends on the *syntactical* context it is placed in makes XQuery very
different from most other programming languages.

We should devote some space to explain this "feature" in more details
potentially using some examples.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Dana says that, in the very beginning of the "Basics" section, where we first say that XQuery is a functional language, we should add some examples illustrating obscure reasons why it is not really a functional language after all (because of element constructors with namespace declarations etc.) These examples would depend on features that are not introduced until much later. Status: Recommend to reject. I do not think the proposed examples would be helpful to the reader at this point in the document. I am not sure they would be helpful at all. If Dana feels strongly about this I think she should make a more specific suggestion for material to be added at one or more later points in the document.

qt-2004Feb0441-01: [XQuery] BEA_016
[editorial, decided] 2004-09-26
[XQuery] BEA_016, Daniela Florescu (2004-02-16)
XQuery: editorial, minor

Section 2.4.2 bullet 4 a says: "If an element has type annotation
xdt:untypedAtomic...."

Our data model doesn't seem to allow this case.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0440-01: [XQuery] BEA_015
[editorial, decided] 2005-01-20
[XQuery] BEA_015, Daniela Florescu (2004-02-16)
XQuery: editorial, minor.

The XQuery specification in particular uses Qname in places
where an expanded Qname is technically the right terminology.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Dana requests some instances of "QName" be changed to "expanded QName". Status: Accepted and implemented.

qt-2004Feb0424-01: [XQuery] A.1.1 Grammar Notes: xml-version
[editorial, decided] 2004-06-08
[XQuery] A.1.1 Grammar Notes: xml-version, Michael Dyck (2004-02-15)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1.1 Grammar Notes
grammar-note: xml-version

"The general rules for [XML 1.1] vs. [XML 1.0], as described in the A.2
Lexical structure section, should be applied to this production."

    The phrase "general rules" is vague, and doesn't connect well with
    A.2, which doesn't present rules in its discussion of XML versions.
    Also, "should be applied to this production" is vague.  How about:

        An implementation's choice to support the XML 1.0 or 1.1
        character set determines the external document from which
        to obtain the definition for this production.

    But where are the (external) definitions of NCName and QName for
    XML 1.1 documents?

    Also, XML 1.0 and 1.1 have the same definition for S, so the
    gn: xml-version annotation doesn't apply to [11] S.

-Michael Dyck
Accepted.
qt-2004Feb0423-01: [XQuery] A.1.1 Grammar Notes: leading-lone-slash
[editorial, decided] 2004-05-11
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1.1 Grammar Notes
grammar-note: leading-lone-slash

"Therefore, a stand-alone slash, in a leading position, that is followed
by an operator, will need to be parenthesized in order to stand alone,
as in "(/) * 5". "5 * /", on the other hand, is fine."

    What is a "leading position"?

    What is an "operator"?

    If "5 * /" is fine, is "5 * / * 5" fine?

    This sentence is more than just a helpful note, it actually
    restricts the language. It should probably be given a different
    status.

-Michael Dyck
> Proposed, recommended, or existing response:
>   Clean up and request approval
        Accepted, let's make this a normative part of the spec.
        Scott will take care.
Scott's proposal accepted, as amended by correcting
                   inversion of RHS with LHS.

            

Scott's proposal accepted, as amended by correcting

inversion of RHS with LHS.


            

[[accepted]]

qt-2004Feb0422-01: [XQuery] A.1.1 Grammar Notes: lt
[editorial, decided] 2004-03-29
[XQuery] A.1.1 Grammar Notes: lt, Michael Dyck (2004-02-15)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1.1 Grammar Notes
grammar-note: lt

"Token disambiguation of the overloaded '<' pattern"

    Why do you call "<" an "overloaded" pattern? Is it the fact that it
    occurs in more than one place in the grammar? There are about 24
    such patterns. So why single out "<"?

    Moreover, the leading-lone-slash restriction ensures that there is
    no ambiguity around the "<" pattern, so there is no (further)
    disambiguation to do.

"The "<" comparison operator can not occur in the same places as a "<"
tag open pattern. The "<" comparison operator can only occur in the
OPERATOR state and the "<" tag open pattern can only occur in the
DEFAULT and the ELEMENT_CONTENT states."

    Note that even if they *could* occur in the same state, it wouldn't
    matter, because the A.2.2 machine doesn't distinguish the two cases;
    it simply reports an instance of the "<" pattern.

-Michael Dyck
No action. Scott will reply.
qt-2004Feb0421-01: [XQuery] A.1.1 Grammar Notes: parens
[editorial, decided] 2004-05-11
[XQuery] A.1.1 Grammar Notes: parens, Michael Dyck (2004-02-15)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1.1 Grammar Notes
grammar-note: parens

"A look-ahead of one character is required to distinguish function
patterns from a QName followed by a comment."

    Change "comment" to "comment, pragma, or extension".

"For example:
    address (: this may be empty :)
may be mistaken for a call to a function named "address" unless this
lookahead is employed."

    It sounds like this lookahead would have to be incorporated into the
    operation of the A.2.2 machine. If so, that's another way in which
    A.2.2 is under-defined (see
    http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0348.html).

-Michael Dyck
Proposal accepted.

            


            

[[accepted]]

qt-2004Feb0417-01: [XQuery] too many sections in References
[editorial, decided] 2005-01-20
[XQuery] too many sections in References, Martin Duerst (2004-02-15)
It is unclear how the various reference sections have been made
up (except for the 'normative reference' section). I suggest to
just have 'normative references' and 'non-normative refences'.

Regards,   Martin.
Status of XQuery Last Call editorial comments, Don Chamberlin (2005-01-20)
			
            

Status: Accepted and on my work list.

qt-2004Feb0416-01: [XQuery] namespace location
[editorial, decided] 2004-09-26
[XQuery] namespace location, Martin Duerst (2004-02-15)
The xhtml example in 4.6 should use the schema location at W3C,
not some arbitrary example location.

Regards,   Martin.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done by using a different example of an imported schema.

qt-2004Feb0414-01: [XQuery] wording about XQuery processor
[editorial, decided] 2004-09-26
[XQuery] wording about XQuery processor, Martin Duerst (2004-02-15)
The following two text fragments from 4.1 don't really match up:

"The version number "1.0" indicates the requirement that the query must be
processed by an XQuery Version 1.0 processor."

"An XQuery implementation must raise a static error [err:XQ0031] when
processing a query labeled with a version that the implementation does not
support."

If an XQuery 2.0 processor is defined to support both XQuery 1.0 and
2.0, this won't make sense.


Regards,    Martin.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0413-01: [XQuery] additional namespace outputs
[editorial, decided] 2004-09-26
[XQuery] additional namespace outputs, Martin Duerst (2004-02-15)
3.7.4, last paragraph: How can an XQuery programmer make sure that
a namespace declaration is included so that the xs namespace
prefix in the example is declared in the output? There has to
be a clear way to do that.


Regards,   Martin.
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

Done.

qt-2004Feb0397-01: [XPath/XQuery] streamline item 2 in precedence order
[editorial, decided] 2004-05-11
in A.4, precedence order, in item 2, please streamline, i.e.
"for, some, every, if, or". Also, please add () at the bottom,
and please change "(comma)" to ", (comma)" or so.

Regards,   Martin.
Proposal accepted.

            


            

[[accepted]]

qt-2004Feb0396-01: [XPath/XQuery] whitespace: What is a word
[editorial, decided] 2004-06-08
[XPath/XQuery] whitespace: What is a word, Martin Duerst (2004-02-15)
in A.2.1, "words" isn't clearly defined.


Regards,    Martin.
Accepted.
qt-2004Feb0380-01: [XQuery] A.1 EBNF: rename some symbols
[editorial, decided] 2004-03-29
[XQuery] A.1 EBNF: rename some symbols, Michael Dyck (2004-02-15)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1 EBNF

It would be good if some groups of related symbols were named more
consistently. Specifically...

--------

'content characters':

    ElementContentChar      (no change)
    QuotAttrContentChar      (no change)
    AposAttrContentChar      (no change)
    ExprCommentContentChar  instead of ExprCommentContent
    PragmaContentChar       instead of PragmaContents
    ExtensionContentChar    instead of ExtensionContents

(Mind you, I've elsewhere suggested renaming ExprComment as just
Comment, so that would give you CommentContentChar.)

--------

computed constructors:

    CompDocConstructor     (no change)
    CompElemConstructor    (no change)
    CompNSConstructor      (no change)
    CompAttrConstructor    (no change)
    CompTextConstructor    (no change)
    CompCommentConstructor instead of CompXmlComment
    CompPIConstructor      instead of CompXmlPI

--------

direct constructors:

    DirElemConstructor         (no change)
    DirAttributeList           instead of AttributeList
    DirAttributeValue          instead of AttributeValue
    DirElemContent             instead of ElementContent
    DirCommentConstructor      instead of XmlComment
    DirPIConstructor           instead of XmlPI
    DirCdataSectionConstructor instead of CDataSection

or else:

    XmlElement        instead of DirElemConstructor
    XmlAttributeList  instead of AttributeList
    XmlAttributeValue instead of AttributeValue
    XmlElementContent instead of ElementContent
    XmlComment        (no change)
    XmlPI             (no change)
    XmlCdataSection   instead of CDataSection

-Michael Dyck
Seems like goodness to me, worth the trouble?

Accepted, apart from the
DirCdataSectionConstructor instead of CDataSection
(which has gone anyway).
Scott will tackle this.
qt-2004Feb0379-01: [XQuery] A.1 EBNF: introduce DirectConstructor
[editorial, decided] 2004-03-29
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

3.7 Constructors,
A.1 EBNF

I think it would be an improvement if you changed

    [80] Constructor        ::= DirElemConstructor
                                | ComputedConstructor
                                | XmlComment
                                | XmlPI
                                | CDataSection

to

    [80] Constructor        ::= DirectConstructor | ComputedConstructor
    [new] DirectConstructor ::= DirElemConstructor
                                | XmlComment
                                | XmlPI
                                | CDataSection

This would better reflect the division between computed and direct
constructors. Incidentally, it would also mean that you could change:

    [109]   ElementContent  ::= ElementContentChar
                                | "{{"
                                | "}}"
                                | DirElemConstructor
                                | EnclosedExpr
                                | CDataSection
                                | CharRef
                                | PredefinedEntityRef
                                | XmlComment
                                | XmlPI

to just:

    [109]   ElementContent  ::= DirectConstructor
                                | ElementContentChar
                                | "{{"
                                | "}}"
                                | CharRef
                                | PredefinedEntityRef
                                | EnclosedExpr

------------------------------------------------------------------------

Moreover, if you introduced

    [new]  CommonContent  ::= PredefinedEntityRef
                              | CharRef
                              | "{{"
                              | "}}"
                              | EnclosedExpr

then you could eliminate a bunch of repetition in [109,112,113]:

    [109]  ElementContent       ::= DirectConstructor
                                    | ElementContentChar
                                    | CommonContent

    [112]  QuotAttrValueContent ::= QuotAttrContentChar | CommonContent


    [113]  AposAttrValueContent ::= AposAttrContentChar | CommonContent

-Michael Dyck
Seems like goodness to me, worth the trouble?

Accepted. Scott and Don will tackle this.
qt-2004Feb0378-01: [XQuery] A.1 EBNF: order of productions
[editorial, decided] 2004-03-29
[XQuery] A.1 EBNF: order of productions, Michael Dyck (2004-02-15)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

A.1 EBNF

It would be more helpful to the reader if you presented the productions
in an order such that:
(1) The definition for a symbol is close to (and after) its uses (except
    for ubiquitous symbols like ExprSingle and TypeDeclaration).
(2) Definitions for related symbols are close.

Of course, there are tradeoffs involved, but here is an ordering that I
believe fulfills these two desiderata better than the current ordering:

------------------------------------

 [30]  Module
 [36]  VersionDecl
 [31]  MainModule
 [32]  LibraryModule
 [33]  ModuleDecl
 [34]  Prolog
 [35]  Separator
[118]  NamespaceDecl
[115]  XMLSpaceDecl
[119]  DefaultNamespaceDecl
[116]  DefaultCollationDecl
[117]  BaseURIDecl
[146]  SchemaImport
[147]  SchemaPrefix
 [37]  ModuleImport
 [38]  VarDecl
[145]  ValidationDecl
[120]  FunctionDecl
[121]  ParamList
[122]  Param
[114]  EnclosedExpr

 [39]  QueryBody
 [40]  Expr
 [41]  ExprSingle
 [42]  FLWORExpr
 [43]  ForClause
 [44]  PositionalVar
 [45]  LetClause
 [46]  WhereClause
 [47]  OrderByClause
 [48]  OrderSpecList
 [49]  OrderSpec
 [50]  OrderModifier
 [51]  QuantifiedExpr
 [52]  TypeswitchExpr
 [53]  CaseClause
 [54]  IfExpr
 [55]  OrExpr
 [56]  AndExpr
 [57]  InstanceofExpr
 [58]  TreatExpr
 [59]  CastableExpr
 [60]  CastExpr
 [61]  ComparisonExpr
 [82]  GeneralComp
 [83]  ValueComp
 [84]  NodeComp
 [62]  RangeExpr
 [63]  AdditiveExpr
 [64]  MultiplicativeExpr
 [65]  UnaryExpr
 [66]  UnionExpr
 [67]  IntersectExceptExpr
 [68]  ValueExpr
 [78]  ValidateExpr

 [69]  PathExpr
 [70]  RelativePathExpr
 [71]  StepExpr
 [72]  AxisStep
 [85]  ForwardStep
 [89]  ForwardAxis
 [87]  AbbrevForwardStep
 [86]  ReverseStep
 [90]  ReverseAxis
 [88]  AbbrevReverseStep
 [91]  NodeTest
 [92]  NameTest
 [93]  Wildcard
 [73]  FilterStep
 [77]  Predicates

 [75]  PrimaryExpr
 [94]  Literal
 [95]  NumericLiteral
 [76]  VarRef
 [96]  ParenthesizedExpr
 [74]  ContextItemExpr
 [97]  FunctionCall

 [80]  Constructor
 [81]  ComputedConstructor
 [99]  CompDocConstructor
[100]  CompElemConstructor
[101]  CompNSConstructor
[102]  CompAttrConstructor
[105]  CompTextConstructor
[104]  CompXmlComment
[103]  CompXmlPI

 [98]  DirElemConstructor
[110]  AttributeList
[111]  AttributeValue
[112]  QuotAttrValueContent
[113]  AposAttrValueContent
[109]  ElementContent
[108]  XmlComment
[107]  XmlPI
[106]  CDataSection

[124]  SingleType
[123]  TypeDeclaration
[125]  SequenceType
[144]  OccurrenceIndicator
[127]  ItemType
[126]  AtomicType
[128]  KindTest
[141]  AnyKindTest
[138]  DocumentTest
[140]  TextTest
[139]  CommentTest
[137]  PITest
[130]  AttributeTest
[129]  ElementTest
[135]  AttribNameOrWildcard
[134]  ElementNameOrWildcard
[136]  TypeNameOrWildcard
[132]  AttributeName
[131]  ElementName
[133]  TypeName

 [79]  SchemaContext
[143]  SchemaContextLoc
[142]  SchemaContextPath

------------------------------------

 [18]  PITarget
 [20]  VarName

 [12]  SchemaMode
 [13]  SchemaGlobalTypeName
 [14]  SchemaGlobalContext
 [15]  SchemaContextStep

  [7]  IntegerLiteral
  [8]  DecimalLiteral
  [9]  DoubleLiteral
 [16]  Digits
 [10]  StringLiteral
 [22]  PredefinedEntityRef
 [24]  CharRef
 [23]  HexDigits

 [17]  EscapeQuot
 [25]  EscapeApos
 [27]  ElementContentChar
 [28]  QuotAttrContentChar
 [29]  AposAttrContentChar

  [3]  ExprComment
  [4]  ExprCommentContent
  [1]  Pragma
  [5]  PragmaContents
  [2]  MUExtension
  [6]  ExtensionContents

 [21]  QName
 [19]  NCName
 [11]  S
 [26]  Char

------------------------------------

-Michael Dyck

            

Don't think it's quite worth the trouble, begs the issue of whether tokens should be separated out or not. But I'm willing.

Accepted. Scott will tackle this.

qt-2004Feb0368-01: [XPath 2.0] XSCH-XPATH-003
[editorial, decided] 2004-09-26
[XPath 2.0] XSCH-XPATH-003, Lisa Martin (2004-02-15)
Dear Colleagues,

This comment pertains to the Nov. 12 2003 version of XPath 2.0 [1].

[1] http://www.w3.org/TR/xpath20/

Lisa Martin, on behalf of the XML Schema Working Group
----------------------------------------------------

Section 2.4.4 Sequence Type Matching

   In the definition of type-matches in 2.4.4, known and unknown derived
   types are treated differently with respect to derivation by extension
   and restriction. Implementations are free to return true if they can
   determine that unknown types are derived by restriction but not if they
   are derived by extension or a mix of extension and restriction steps,
   whereas known types will return true if derived by any means.   If this
   non-parallelism is intentional, an explanatory note might help avoid
   confusion on the part of readers.   If it is not intentional, it should
   be fixed.   In addition, the rules are careful to say "derived by one or
   more steps of restriction or extension" but say simply "derived by
   restriction".   Is it intended that this be confined to a single
   derivation step?   Or would one or more restriction steps be OK?
XQuery editorial comments, Part 3, Don Chamberlin (2004-09-26)

            

This comment is about the definition of the "type-matches" pseudo-function, which has been replaced by a new pseudo-function named "derives-from" with a new definition. I believe that the new definition addresses the issue raised by this comment. I consider this comment to be "overtaken by events."

qt-2004Feb0321-01: [XQuery] lexical leftovers 7
[editorial, decided] 2004-05-11
[XQuery] lexical leftovers 7, Michael Dyck (2004-02-13)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

Here is a comment from
http://lists.w3.org/Archives/Public/public-qt-comments/2002Dec/0019.html
that did not receive a response from the WG.

------

A.4 Precedence Order

"In the cases where a number of operators are a choice at the same
production level, the expressions are always evaluated from left to
right."

    The phrase "a choice at the same production level" is vague.

    And the order in which the *expressions* are evaluated is immaterial.
    For example, in the AdditiveExpr A - B - C, the order in which you
    evaluate A, B, and C doesn't matter (except in the presence of
    dynamic errors); what matters (when you're defining precedence) is
    the order in which you evaluate the subtractions.

    Here's something that addresses these points, and comes closer to
    using standard terminology:
        When a production directly derives a sequence of expressions
        separated by binary operators, the operators are evaluated from
        left to right.

    In any event, an example might help.

-Michael Dyck
Scott's proposal goes too far. Among operators at the
                   same precedence level, operators must be applied from
                   left to right (otherwise minus becomes nondeterministic).
                   Amended proposal is accepted.

            

Scott's original proposal goes too far. Among operators at

the same precedence level, operators must be applied from

left to right (otherwise minus becomes nondeterministic).

Amended proposal is accepted.


            

[[accepted]]

qt-2004Feb0319-01: [XQuery] lexical leftovers 5
[editorial, decided] 2004-05-11
[XQuery] lexical leftovers 5, Michael Dyck (2004-02-13)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

Here is a comment from
http://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0091.html
that did not receive a response from the WG.

------

A.1 EBNF

[17] EscapeQuote ::= '"' '"'
    For the right-hand side, why not just '""'?
    (Note that EscapeApos is "''".)

-Michael Dyck
Closed as duplicate of 2004Feb0411.

            

Duplicate of 2004Feb0411

qt-2004Feb0318-01: [XQuery] lexical leftovers 4
[editorial, decided] 2004-05-11
[XQuery] lexical leftovers 4, Michael Dyck (2004-02-13)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

Here are some comments from
http://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0090.html
that did not receive a response from the WG.

It turns out that, in my recent submission:
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0193.html
I already re-stated many of the unanswered comments from the Nov 2002
posting. These two are the remainder.

------

A.2.1 White Space Rules

"white space is needed to disambiguate the token"
    In my recent posting, I suggested changing "token" to "grammar".
    But I think I prefer what I said in Nov 2002:

        The phrase "disambiguate the token" is, I believe, a misuse of
        the concept of ambiguity. At any rate, I think it would be
        plainer and more accurate to say that whitespace is needed to
        prevent two adjacent tokens from being (mis-)recognized as one.

        For instance, consider the character-sequence
            a- b
        Note that there is a space before the 'b'. It thus has only one
        derivation from Module (the "a minus b" one), so there is no
        ambiguity involved, no disambiguation needed. Nevertheless, it
        is still a case in which (I assume) whitespace is needed between
        'a' and '-' to prevent the longest-match rule from
        (mis-)recognizing 'a-' as a QName.


"Special whitespace notation"
    Note that only the *notation* is special. The treatment of
    whitespace characters in "ws: explicit" and "ws: significant"
    productions is *not* special: they treat them like any other
    character, just as the XML spec does.  It's the *unmarked*
    productions that have special interpretation with respect to
    whitespace.

-Michael Dyck
Proposal accepted.

            


            

[[accepted]]

qt-2004Feb0317-01: [XQuery] lexical leftovers 3
[editorial, decided] 2004-03-29
[XQuery] lexical leftovers 3, Michael Dyck (2004-02-13)
XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

Here are some comments from
http://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0021.html
that did not receive a response from the WG.

------

A.1 EBNF

"The following grammar uses the same Basic Extended Backus-Naur Form
(EBNF) notation as [XML 1.0], except that grammar symbols always have
initial capital letters."

    I still wonder what the reason for this exception is.

    And that isn't the only difference from the notation used in XML.
    In fact, you immediately discuss two others -- the <> terminal
    groupings, and the /**/ production comments. Another is the use (in
    prodns [11,19,21,26]) of references to symbols in other
    specifications. Maybe you could just change "except that" to
    something like "with the following minor differences".

    Also (this isn't actually a leftover comment, but while I'm here):
    there's no reason to capitalize the word "Basic".  The XML spec
    itself uses the word "simple".

    (These comments also apply to a similar sentence in 1 Introduction.)

-----

A.2 Lexical structure

"The rules for calculating these states are given in the A.2.2 Lexical
Rules section."
    No, A.2.2 does not give rules for calculating the states.

-Michael Dyck

            

Adapt "Symbols are written with an initial capital letter if they are the start symbol of a regular language, otherwise with an initial lower case letter."? Also, be more specific about differences with EBNF in XML? Worth the work?

On the A.1 EBNF part: ok, accepted, Scott will take this action up.

Don: also note in the intro of the lang book "Grammar symbols have initial caps" etc, should I delete this?

Scott: yes.

qt-2004Feb0314-01: ORA-XQ-055-E: Formatting is not good for hardcopy viewing
[editorial, decided] 2005-01-20