Last Call Comments for xquery.

Section 3.1.5 Function Calls
Editorial

Please reword: " parameteror " with " parameter or "

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

         

Section 2.1.1 Static Context
Editorial

"environmentor" => "environment or"

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

         

Consider the following schema document and instance:

<xs:schema xmlns:xs="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]

            
Moved to the Data Model cluster.

         

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

         

The Web Serice Description Language (WSDL) [1] provides a facility for
describing Web services - a WSDL document could be thought of as an
XML description of a set of function signatures.

Some XML Query implementations will very likely support the idea
of calling such functions in XPath expressions.

Would it increase interoperability of such implementations if
one could explicitly associate a namespace prefix with a WSDL
document in the XML Query Prolog?

For example,
    import service cvt at "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.

         

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]

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.

         

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

--Don Chamberlin

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

         

Dear Colleagues,

This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].

Please accept our sincere apologies on being past-due with this
submission.

Regards,
David Ezell (on behalf of the XML Schema WG)

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

            
Moved to the Data Model cluster.

         

Dear Colleagues,

This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].

Please accept our sincere apologies on being past-due with this
submission.

Regards,
David Ezell (on behalf of the XML Schema WG)

[1] 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};

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

         

Dear Colleagues,

This comment pertains to the 12 November 2003 internal WD of
XQuery 1.0: An XML Query Language [1].

Please accept our sincere apologies on being past-due with this
submission.

Regards,
David Ezell (on behalf of the XML Schema WG)

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

         

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.

         

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]

         

            


            
[---+-+1, multiple unary operators before an expression, there for

            
backward compatibility, group previously didn't want to change it]

            
ACTION A-SJ04-27: Don will add a note to the XPath document to explain the rationale

         

Range expressions (op:to) should treat empty sequence arguments in same way as other binary operators:
if one of argument is empty sequence, result is empty sequence.

I don't see reason for making exception for range expressions.

Best Regards,
Noe Michejda
7th Portal S.C.

            
+ DC: The current rule is consistent with the function conversion rules
for integer. This is nice and simple.
++ M.Rys: Allowing empty sequences as operands of "to" would avoid
static errors in some cases.
++ M.Kay: TO is unlike other binary operators because it takes singleton
inputs and returns a sequence output.
++ Andrew: Advocates accepting the empty sequence in order to avoid
error cases.
++ DECISION: Accepted last call comment qt-2004Feb/1141, subject to
approval by XSL WG since it affects XPath. "TO" operator will accept
empty sequences.
++Note from Chair: This decision was subsequently confirmed by the XSL
WG. See:
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.

         

Current syntax of SequenceType gives user no control over allowing substitutions of element or not.
User can't test for local element name if there is global declaration with same name
without allowing of elements from substitution group of global element.
Or element will be matched agains unanticipated type from global declaration,
where user wanted only name test. And there will be no warning from processor.
If schema is authored by another person than stylesheet or query this can lead
to disaster if at some point declaration will be added without knowledge of stylesheet author.
Using of declarations and substitution groups should be explicit.

I propose following changes in syntax of elementTest to something like this:

 element()  : matches any element
 element(*,type) : matches type if element type is 'type' or is derived from it

 element(qname ["decl" | "subst"] [,type] ["nillable"])
    if "decl" is present, element is matched to global element declaration
    if "subst" is present, element is matched to global element declaration allowing substitutions
    if neither "decl" or "subst" is present element name is matched to 'qname'

    additionally if 'type' is present, element type must be derived from 'type'

 element(SchemaContextPath qname)
  element is matched to local element declaration

same applies to attribute() [without 'subst']


This will remove synonyms:
element() = element(*) = element(*,*)
attribute() = attribute(*) = attribute(*,*)


Another (maybe better to read) notation:

element(decl(qname),type)
element(subst(qname),type)
 or
element(substitutions(qname),type)
element(substitution(qname),type)

attribute(decl(qname))
etc.

Best Regards,
Noe Michejda
7th Portal S.C.

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

         

SECTION 2.6: Optional Features

  Today XQuery requires node identities to be preserved in the language quite strongly. All nodes that are from an external source or created in the language require node identities to be preserved. This is a strict requirement that is not necessary for a large number of applications that need to deal only with the values contained in the nodes rather than the nodes' identity.

 This is also a great burden for implementations that can otherwise use streaming mechanisms for XML processing.

 This is also a problem for implementations that choose to push down the query to be evaluated in native systems like relational databases or other non-XML value based systems.

Suggestion:
 Include a static context flag that specifies whether node identities need to be preserved. If the option is true, then no node based operations such as "is", "<<" , ">>" etc.. should be allowed. Further this could also restrict non-forward axes like parent(), sibling(), root(), etc..



- Steve B.

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

         

SECTION 4.3: Base URI

Does specifying the baseuri in a module only take effect for lexically defined URIs or does it also apply to any URI values present in the system?

In particular does the xml:base property affect resolution of URLs inside a document?

* When we convert an anyURI value from an element or an attribute to a string using the resolve-uri() function, does it take into account the xml:base property?

e.g. consider a purchaseorder document with an xml:base property defined as "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.

         

SECTION 3.8: FLWR Expressions

Currently, the tuple is defined for the FLWR and order by clauses as containing a set of bound variables. It might help to formalize the tuple notion so that a lot of trivial operations that are possible in languages like SQL (and quite cumbersome to do in XQuery) can be made easy.

Example:
i) If we map any external related set of values (example an SQL row or an XML file in a file system along with some metadata like author etc..) into XQuery, since there is no notion of a tuple, we have to wrap the XML values in another XML element. This causes issues, since node identities, document boundaries etc.. are lost.

ii) When returning values as well, without the notion of tuples, related values either have to be enclosed in an XML element or streamed as siblings in the sequence. This also leads to the same problems as (i).

Example - I want to return a Resume XML document and a computed score for the resume. Either we have to return a sequence that has the resume document followed by it's score or create a new XML element and stuff the two in there - the latter will lose the resume document's node identity and typing.

ii) Performing duplicate elimination is quite a challenge without tuples. (See G.5)

iii) Performing grouping operations is also hard.

Suggestion:
 Formalize the tuple as something in between an item and a sequence - A sequence consists of tuples which consists of items. Or maybe introduce a notion of a tuple-sequence as different from a regular sequence.

- Steve B.

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

         

SECTION C.1: Static Context Components

The dynamic context today includes the context item. However, the static context does not include a static type for the context item. This must be included for doing reasonable static type checking.

The table in C.1 - Static Context components could include the following item -

 Component: Context item -
 Predefined value: none
 Overwritable by implementation: Overwritable and Augmentable
 Overwritable by query: -- ??
 Scope - Global
 Consistency rules - Only one context item from the outside environment


- Steve B.

            
Minutes log just says "This issue is closed"

            
(joint issue)

         

            
[[accepted]]

         

SECTION G.5: Selecting distinct combinations

Today, the distinct-values takes a single sequence as input and returns a sequence of distinct values. This makes it quite cumbersome to perform distinct values across a tuple.

 It is trivial in SQL for example to perform a distinct across values -

select DISTINCT price, orderno, date
from table;

 With XQuery, one has to get distinct prices, ordernos and dates and then somehow combine them back with the original node. This is both cumbersome and harder to optimize in a general query.

Suggestions:
i) If we have a sequence of tuples or sequence of sequences, then distinct values can take in a sequence of tuples/sequence of sequences and return a sequence containing distinct values.

ii) Or - Add a DISTINCT clause that prunes out nodes that have the same value.
Example - the query in G.5 with a distinct clause -

  for $p in .
  distinct-values on $p//product, $p//size, $p//color
  return
      <option>
        <product>{$p//product}</product>
        <size>{$s//size}</size>
        <color>{$c//color}</color>
      </option>

 The clause can remove nodes that have the same value for product, size and color and return some $p that has a distinct set of values.

- Steve B.

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

         

Dear XQuery Formal semantic editor:
	I have some question about  XQuery/Xpath core grammar in "XQuery 1.0 and XPath 2.0 Formal Semantics" (2003-11-12).

	1)Some Non-Terminal only occur in the left side of core grammar production,but no Non-Terminal can yield it.
	  For example:
      	PrimaryExpr
	  	OrderByClause
      	QuantifiedExpr
      could you explain it in detail?

    2)In Formal semantic,OrderByClause can be normalized to nested let and for expressions,but why it still
       remain in the core grammar?

    3) In XQuery standard grammar:
		ExprSingle    ::=     FLWORExpr
							| QuantifiedExpr
							| TypeswitchExpr
							| IfExpr
							| OrExpr
        In XQuery Core grammar:
         ExprSingle    ::=    FLWORExpr
							| TypeswitchExpr
							| IfExpr
							| OrExpr
		QuantifiedExpr has been removed ,why?




		best regards
						liao wei

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

         

This is a follow-on to the thread "recursive imporged [sic]
variable declarations":
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/

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

         

Section 2.4.4.3 Matching an ElementTest and an Element Node
Technical

The current semantics of element(Name, *) is that it matches any element
of any type (the same as element(Name, xs:anyType). We think that this
semantics is problematic when implementing a statically typed system for
the use case where you want to only operate on untyped data. It seems
counter-intuitive that if I do not care about types, that I actually
have to write the function signature element(Name, xdt:untyped) to
preserve the static untypedness inside a function. It would seem better,
if we can define element(Name, *) to either refer to the untyped case or
make it something that will provide late static type binding by
preserving the inferred type of the expression passed. Note that the
later obviously complicates separate compilation of the function since
you need to know the static type of what is being passed...

Here is an example:

define function addWATax($e as element(invoice,*)) as xs:double
{ $e/cost[1] * 1.088 }

With the current semantics of element(invoice, *), $e/cost[1] would
infer the static type element(cost, xs:anyType)? which currently cannot
be atomized because it may have an non-atomizable element at runtime and
would raise a static type error. By changing the semantics to mean
element(invoice, xdt:untyped) the inference for  $e/cost[1] would be
element(cost, xdt:untyped)? that can be atomized to xdt:untypedAtomic?
which in turn will be promoted to xs:double and the function results in
the expected result.

Note that this issue is preserved even if we change the meaning of
element(name) to mean element(name,*) (see
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.

         

SECTION 2.2: Processing Model

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

- Steve B.

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

         

SECTION 2.1.2: Dynamic context

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

- Steve B.

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

         

SECTION A.2.2: lexical rules

The action pushState is used inconsistently in the transitions,
sometimes with an argument and sometimes without.  The only
guidance to the reader is the sentence "In some cases, a
transition will 'push' the current state or a specific state
onto an abstract stack...".  The reader is left to surmise
that pushState() means "push the current state" whereas
pushState with an argument means "push the argument state".
But if we look at the table for OPERATOR state, first row,
we see the pair of actions:

  DEFAULT
  pushState(DEFAULT)

This seems to mean: first, change the current state to DEFAULT,
and then push the state DEFAULT on the stack.  In that case,
couldn't you just write the second action as pushState()?
If we look at the next to the last line in the same table,
we see

  EXT_KEY
  pushState()

which seemingly means, change the current state to EXT_KEY, and
then push that state.  This leaves this reader confused, why
in one case you chose to push the state explicitly, and in the
other case you did not?  I toyed with the possibility that the
latter example is to be interpreted "change the current state to
EXT_KEY, but push the former state on the stack."  But if that
is your intention, wouldn't it be better to write it

  pushState()
  EXT_KEY

? (Actually, there is considerable evidence in other rules
that this is indeed your meaning; I am filing a separate comment
asking you to please list the actions in the order of execution
instead of this confusing reverse order of execution.)

The best solution in my opinion is simply to get rid of the
argumentless pushState -- always write out explicitly what
state you want to push.  That also eliminates the issue of order
of execution.

- Steve B.

Proposal accepted.

According to table C2, the context item, context position, and context
size are all overwriteable by the implementation.  The context position
"Must be consistent with context item and context size", and the context
size "Must be consistent with context item".

I think we should clearly say that if there is no context item, the
context position and context size are undefined. It is not reasonable to
have no context item but set the context position to 42 and the context
size to 43.

I think we should clearly say that if there is a context item, the
context position and context size are 1. It is not meaningful to say
that the single context item is in position 42 of some sequence to which
the query has no access. (Obviously, the context item might have a
position in a child sequence to which the query has access).

Jonathan

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

Query Lang [4.12] local:

   "The declared function name in a function declaration must be a QName with a
   non-empty namespace prefix. If the namespace prefix of a declared function
   name is empty, a static error is raised.[err:XQ0045]"

and

   "It is a static error if the declared name in a function declaration uses
   one of the predefined namespace prefixes other than local.[err:XQ0045]"

What is the rationale for this restriction on the function _prefix_? Is there a
defined mapping from the prefix "local" in the QName "local:myFcn" to a URI?
If so, what is it? If there is no such mapping, this seems at odds with
recommendations of the web architecture [1]. A constraint on the specific
prefix seems very unsound architecturally.

Why not permit functions in the main module to have no namespace? Why not
permit functions in the main module to use the default function namespace (and
its associated prefix)?

Suggest:
* Strike the second constraint entirely, and remove the special-casing for
  the prefix 'local'.
* Either:
     Strike the first constraint entirely.
  or
     Recast in terms of namespaces (rather than namespace prefixes) and
     permit function declarations to assume the default function namespace.

[1] http://www.w3.org/TR/2003/WD-webarch-20031209/

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

         

Query Lang [4.12] Function Declaration prefix vs. namespace.

   "The declared function name in a function declaration must be a QName with a
   non-empty namespace prefix. If the namespace prefix of a declared function
   name is empty, a static error is raised.[err:XQ0045]"

This restriction as stated should be that the _namespace_ be non-empty. If a
default function namespace is in effect in the module, it seems that the
logical thing to do would be to apply it equally to function definitions.

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

         

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

         

Query Lang [4.8] Schema Import

It does not appear to be possible to import a schema with no target namespace.
The syntax rules require a namespace to be present.

Suggest either (1) making the second StringLiteral in the production for
SchemaImport optional or (2) adding alternatives that use an explicit
"nonamespace" token, e.g.

(1) import schema at "nonamespace.xsd";
       or, with no location hint:
    import schema;

(2) import schema nonamespace at "nonamespace.xsd";
       or, with no location hint:
    import schema nonamespace;

Alternative (2) is more in line with XML Schema's explicit marking on
non-namespaced schemas; alternative (1) is simpler.

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

         

Query Lang [4.9] Module Import

"It is a static error if the target namespace of the module to be imported is
 the same as the target namespace of the importing module. [err:XQ0056]"

Request that this sentence be struck. It introduces no useful constraint that
is not already covered by existing rules, but introduces a constraint that is
highly detrimental to application development.

The analogy to imagine here is that a module namespace is a Java package name,
and the individual module instances are individual Java classes. This rule is
equivalent to saying that each Java class can only import classes in other
packages. It can import multiple classes from other packages, but not any from
its own package.

Consider a complex XQuery application, where the code is partitioned across
multiple developers.  There are a number of cases where module namespaces do
not provide the level of granularity for managing complex code bodies. In these
cases, providing the means to partition the namespace across multiple sources,
and use the module locations in the intuitive fashion (i.e. a file location
locates a file which is syntactically a complete module) provides great benefit.

To get the full benefit of this ability to partition an application namespace
across multiple sources, the decision to forbid importation of modules from the
same namespace should have been reconsidered in the context of the decision to
allow imports of the same module namespace from multiple locations.

Case 1:
   Two independent developers, working on different functions.

   Developer A: selection-lib.xqy
      module "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.

            
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.

         

Query Lang [2.5.2] Cannot catch errors

Dynamic errors can be raised, for example through fn:error(), but there is no
means to catch them. This is a serious deficiency for writing robust
applications, as one must take immense pains to ensure that no expression can
ever, given any set of data, raise a dynamic error if one wants to produce an
application level error result instead of an implementation level one.

Suggest: add try $expression catch $variable $expression
where the variable binds to the error and is an item
This expression will return the value of the try clause unless a dynamic error
was raised, in which case it will return the value of the catch clause.

Example: A function with a parameter that you want to validate using
"validate". If it's not valid, the query blows up and cannot recover, for
example, by fixing up the bad data. The query should be able to do some
internal recovery.
Example: A query performs a division somewhere resulting in an xs:decimal, and
it happens to result in an overflow, from which the application could benignly
recover. The application should be given that chance.

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

         

[General] Input sources

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

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

         

See related comment CER-01

Query Lang [3.1.6, Appendix A] Line-oriented comment syntax

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

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

         

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

         

Query Lang [2.6.6, 3.1.6, Appendix A] Comments and pragmas

The overlap in syntax of pragmas and comments, as well as the nesting of
comments creates difficulties and questions about corner cases that are not
clear from the text:

(1) (: is this a comment? ::)
(2) (: can I comment out a (:: pragma ::) like this? :)
(3) (: is this a comment? ::) or an error? :)
(4) (: what about a partial (:: pragma? :)
(5) (:: pragma with a comment (: is this ok? :) or not ::)
(6) (:: pragma with a comment (: is this a comment? ::) or an error? :) ::)
(7) (:: pragma with a comment (: what about a partial (:: pragma? :) ::)
(8) (: commenting out a (: comment :) is confusing :)
(9) let $string := "this is just a string :)"
(10) (: let $string := "this is just a string :)" :)
(11) let $another := "this is another string (:"
(12) (: let $another := "this is another string (:" :)

Suggest (a) making clear that comments are not allowed inside pragmas and (b)
removing nesting of comments.

            
Technically answered as resolution from some other LCCs.  But I
suggest we use many of Mary's examples directly in the text as
illustrations as to the behavior.  On the other hand, the group can
always reconsider the decision.

            (1) (: is this a comment? ::)

Answer: yes.

(2) (: can I comment out a (:: pragma ::) like this? :)

Answer: yes.  The inner pragma is seen a a comment in this case.

(3) (: is this a comment? ::) or an error? :)

Answer: error.  ANY unbalanced nesting of "(:"/":)" will result in an error.

(4) (: what about a partial (:: pragma? :)

Answer: ANY unbalanced nesting of "(:"/":)" will result in an error.

(5) (:: pragma with a comment (: is this ok? :) or not ::)

Answer: it's fine, but inner content is not a comment.

(6) (:: pragma with a comment (: is this a comment? ::) or an error? :) ::)

Answer: error, "::)" patterns are not allowed in pragma's and extensions.

(7) (:: pragma with a comment (: what about a partial (:: pragma? :) ::)

Answer: this is fine.

(8) (: commenting out a (: comment :) is confusing :)

Answer: OK.  Trying to comment out a large block with a bunch of other comments in them is even more confusing.

(9) let $string := "this is just a string :)"

Answer: No error.

(10) (: let $string := "this is just a string :)" :)

Answer:  Error.  Yes, this is a limitation of nested comments.

(11) let $another := "this is another string (:"

Answer: No error.

(12) (: let $another := "this is another string (:" :)

Answer:  Error.  Yes, this is a limitation of nested comments.

         

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

         

Appendix A.1 EBNF
Technical

It looks like that we cannot parse an expression of the form:
"1" cast as xs:integer = "1.0" cast as xs:integer.

Which is semantically the same as xs:integer("1") = xs:integer("1.0").

Based on the precedence table, I would assume that cast as binds
stronger than =, and from a composability point of view, I would also
expect to be able to write the above. However, when following the
grammar, it looks like the grammar pops out without consuming the =.

Here is the parse process:
"1" is consumed by
Expr->SingleExpr->OrExpr->AndExpr->InstanceOfExpr->TreatExpr->CastableEx
pr->CastExpr->ComparisonExpr->RangeExpr->AdditiveExpr->MiltiplicativeExp
r->UnaryExpr->UnionExpr->IntersectExpr->ValueExpr->PathExpr->RelativePat
hExpr->StepExpr->FilterStep->PrimaryExpr->Literal->StringLiteral

Which then pops back to CastExpr that consumes "cast as xs:integer"

Then we pop back to the top and realize that we have left overs and
raise a parse error.

This is also a problem for the related treat as, castable as etc.

Hi Michael.  Paul wanted me to give high priority to answering this
particular issue (original mail at [1]).

Since the November document, the WG has agreed to change the precedence of
instance-of, treat, castable, and case (in response to a previous issue
raised [2] by you).  The precedence table is now looking more like:

1       (comma)
2       FLWORExpr, some, every, TypeswitchExpr, IfExpr
3       or
4       and
5       eq, ne, lt, le, gt, ge, =, !=, <, <=, >, >=, is, <<, >>
6       to
7       +, -
8       *, div, idiv, mod
9       unary -, unary +
10      union, |
11      intersect, except
12      instance of
13      treat
14      castable
15      cast
16      ValidateExpr, /, //
17      [ ], ( )

so that these operators bind much more tightly.

In the most recent test parser, your expression parses fine:

Type Expression:
"1" cast as xs:integer = "1.0" cast as xs:integer
|QueryList
|   Module
|      MainModule
|         Prolog
|         QueryBody
|            Expr
|               ComparisonExpr =
|                  CastExpr
|                     PathExpr
|                        StringLiteral "1"
|                     CastAs cast as
|                     SingleType
|                        AtomicType
|                           QNameForAtomicType xs:integer
|                  CastExpr
|                     PathExpr
|                        StringLiteral "1.0"
|                     CastAs cast as
|                     SingleType
|                        AtomicType
|                           QNameForAtomicType xs:integer

Please let me know if this previously decided issue resolves MS-XQ-LC1-146
in your view.  Thanks!

-scott


[1] [XQuery] MS-XQ-LC1-146
 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

			

Yes. This seems to resolve the issue.

Thanks
Mi
			

            
See [436]

         

Section 4.12 Function Declaration
Technical

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

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

         

Section 4.12 Function Declaration
Technical

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

            
Issue closed with xdt:AnyAtomicType as the type to be used.

            
(joint issue)

         

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

         

Section 4.11 Default Collation Declaration
Technical

"If a Prolog specifies more than one default collation,": How can you
specify more than one. We should syntactically only allow one.

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

            
(xquery-only)

         

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

         

Section 4.11 Default Collation Declaration
Technical

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

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

         

Section 4.8 Variable Declaration
Technical

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

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

         

Section 4.8	Variable Declaration
Technical

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

            
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.

         

Sections 4.8/3.8.1
Technical

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

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

         

Section 4.7	Module Import
Technical

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

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

         

Section 4.4	Namespace Declaration
Technical

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

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

         

Section 4.4	Namespace Declaration
Technical

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

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

         

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

--Don Chamberlin

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

--Don Chamberlin

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

         

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

--Don Chamberlin

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

--Don Chamberlin

            
WG Resolution: delete the 2nd paragraph feb 774

         

            
WG Resolution: delete the 2nd paragraph feb 774

         

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

Note that casting a QName into a string is also required by the
Serialization document, as noted in comment IBM-SE-015.

--Don Chamberlin

            
RESOLVED: CLOSED by adoption of the triple proposal

         

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

--Don Chamberlin

(IBM-XQ-019) Section 3.7.1.5, Type of a Constructed Element: This section
says that a direct element constructor adds the name of the constructed
element to the validation context for nested expressions. Does this rule
still apply if the direct element constructor has an xsi:type attribute?
How can validation context (a static property) be affected by the value of
an xsi:type attribute (which can be dynamic)?

Similarly, in Section 3.7.3.1, Computed Element Constructors: If the name
of the constructed element is computed by an expression (which, after all,
is the reason for having a computed element constructor), the validation
context for nested expressions is set to "global". This seems likely to
cause problems. Suppose that I use a computed element constructor to
construct an element named Address, with a nested element named Zipcode.
If Address is a computed name, the validation context for the Zipcode
element will be "global". But it's likely that the Zipcode element is not
defined globally, but only within an Address.

Because of examples like this, I am increasingly skeptical of the concept
of "validation context". I do not believe that it is well understood. I
think we would be well advised to stop trying to validate things that do
not have top-level schema definitions, at least in XQuery Version 1.
Deferring this complex and poorly understood feature until after XQuery
Version 1 would provide us with practical experience that might lead to a
more robust design if this feature is found to be needed in a later
version. It would also allow us to focus our efforts on more important
issues such as defining an update language.

My specific proposal is as follows:

(a) Eliminate "validation context" from the Static Context.

(b) Eliminate ValidationContext (formerly called SchemaContext) from the
grammar.

(c) Replace Section 3.7.1.5, Type of a Constructed Element, with a new
section based closely on
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

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

         

(IBM-XQ-018) Section 3.7.1.3, Direct Element Constructors--Content: This
section says that element nodes that are copied by an element constructor
retain their namespace nodes. This seems to imply that the copied nodes do
not also inherit namespace nodes from their new parent. Is this correct?
If so, the copied node may have fewer namespace nodes than its parent. How
can such a node be serialized? Does this introduce a dependency on
"undeclaration" of namespaces, supported only by Namespaces 1.1?

Similarly, in Section 3.7.4, Namespace Nodes on Constructed Elements:
Suppose that the namespace prefix "a" is defined in the Static Context.
Suppose that a constructed parent element has an attribute named "a:b" but
its constructed child element does not use the prefix "a" in any name.
According to the rules in this section, the parent element will get a
namespace node for "a" but the child will not. Again, how can these
elements be serialized? Is this another dependency on Namespaces 1.1?

--Don Chamberlin

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

         

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

--Don Chamberlin

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

         

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

         

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

--Don Chamberlin

            
Minutes log just says "This issue is closed"

            
(joint issue)

         

            
[[accepted]]

         

SECTION 4.12: Function Declaration

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

- Steve B.

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

         

SECTION 2.1.1 : Static contextt

The static context has no type information for the context item,
consequently it is impossible to do static analysis of expressions
that use the context item.

- Steve B.

            
Item closed pending further discussion on the default type

            
(item?) as proposed by Andrew.

            
Michael Rys to start on e-mail on the default type proposal.

         

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

         

            
Discussion on whether item()? makes sense? Can the expression "."
ever return the empty sequence? MKay believes not.
MRys thinks a static type of "none" would be more appropriate
since this will lead to a static error for the query ".".
Jerome suggests another formulation: by default "it's not in the
context".
Andrew thinks this is equivalent to "none".
RESOLUTION to qt-2004Feb0700-01: Accepted the proposal in
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.

         

SECTION A.2.2: Lexical rules

Today's lexical analyser is a 'two-stage' analyzer.  The bottom
stage, not explicitly mentioned in the Appendix, I will call the
raw tokenizer.  This stage is responsible for detecting things
like NCName and NumericLiteral.  The stage above it is responsible
for discerning when an NCName is a keyword, and for handling
comments, pragmas and must-understand extensions.

The design goals that make lexical analysis for XQuery difficult
are: no reserved words; nested comments; and the context-sensitivity
inherent in supporting direct constructors as a sublanguage with
different whitespace and comment rules from the containing language.

In a lexical analyzer with reserved words, the keywords can be
detected in the raw tokenizer stage. Frequently the raw tokenizer
stage also detects and ignores comments.  For such a language,
a single stage, the raw tokenizer, is sufficient.

In languages that only support unnested comments, it is possible
to recognize comments as regular expressions.  The usual way to
recognize regular expressions is with a finite state automaton.
XQuery has opted to support nested comments, which means that
comments are not a regular expression; instead they constitute
a 'context-free' language.  The usual way to recognize a context-free
language is by adding a stack to a finite state automaton.

The current design of the lexical analyzer is with a raw tokenizer
that recognizes tokens defined as regular expressions.  Since
the raw tokenizer is not powerful enough to handle nested comments,
comment handling has been pushed into a stage above the raw
tokenizer, where there is a stack.  This stage has also been given
the responsibility for deciding when an NCName is a keyword.
However, these two responsibilities are not easily merged in a
single stage.  The solution propounded so far has been to prohibit
comments in those contexts which are necessary to recognize certain
keywords.  However, prohibiting comments between
certain pairs of keywords is a major usability disservice.

I think the solution is that the keyword recognizer needs to be
at a higher stage than the comment recognizer.  There are two
ways to do this:

1. Abandon nested comment support.  Most high level languages
do not support nested comments, so there is ample precedent.
Users are accustomed to this restriction.  In addition, if it
came to a choice between nested comments, and the freedom to
put comments anywhere between keywords, I would gladly
sacrifice the nested comments, and I think most users would too.
Making this decision
would mean that comments would be regular expressions, and could
be recognized and removed in the first stage, the raw tokenizer.
This decision would also simplify the syntax and analysis of
comment-like things (pragmas and must-understand extensions).
Overall, the decision would be that there is no nesting of
comments, pragmas or must-understand extensions in one another.

2. If you really have to have nested comments, then you should go
to a three-stage lexical analyzer.  The bottom stage would be a
raw tokenizer, which would detect (: (:: :) and ::) as tokens.
The second stage above would run the stack to determine the boundaries of
comments, pragmas and must-understand extensions.  Finally, the
top stage would recognize keywords.


- Steve B.

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

         

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

         

SECTION 3.7.3.1: Computed element constructors

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

- Steve B.

SECTION 3.2: Path expressions

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

- Steve B.

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

         

SECTION 3.5.1: Value Comparisons

Bullet 1 says "Atomization is applied to each operand. If the result, called an atomized operand, does not contain exactly one atomic value, a type error is raised.[err:XP0004][err:XP0006]".
The definition of atomization (2.3.2) implies that atomization is done during evaluation phase. The words used here "atomic value" also implies that.
However, [err:XP0004] is a static type error.

Similar statements appear in 3.7.3.1, 3.7.3.2, 3.8.3, and 3.12.3.

- Steve B.

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

         

SECTION 3.7.1.1 : Attributes

In 3.7.1.1, it states that namespace declaration attributes
do not create attribute nodes, and so does 3.7.1.2.
However, it is not clear what node namespace declaration attribute
creates until 3.7.4 section which
states that "A namespace node is created corresponding to
each namespace declared in a namespace declaraction attribute...".

So a namespace declaraction attribute indeed creates a namespace
node. So it would be better if we stated that a namespace
declaration attribute creates a namespace node in 3.7.1.1 and
3.7.1.2 or make a cross reference to 3.7.4 .


- Steve B.

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

            
talk about namespace nodes.

         

SECTION 3.7.3.1: Computed Element Constructors

In 3.7.3.1, the content expression of a computed element constructor:
the element nodes are given type annotation xs:anyType and
attribute nodes are given type annotation xs:anySimpleType.
It would be more precise to give type xdt:untypedAtomic to
attribute nodes and give type xdt:untypedAny to element node.

See previous comments on 3.7.1.3 content for direct element constructor.


- Steve B.

            
Changes earlier resolution

         

SECTION 3.7.1.3: Content

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

However, it seems 1.d. is irrelevant since step 6 performs the
same operation.


- Steve B.

            
Changes earlier resolution

         

SECTION 3.12.2: Typeswitch

Should un-reachable case statements lead to a warning? E.g. case as super-type will make the subsequent case as sub-type unreachable.


- Steve B.

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

         

SECTION 3.1.1:

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


- Steve B.

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

         

SECTION 3.8.3: Order by and Return Clauses

In 3.8.3,  the Xquery spec says "The return clause of a
FLWOR expression is evaluated once for each tuple in the
tuple stream, and the results of these evaluations are
concatenated to form the result of the FLWOR expression".

The usage of the word 'concatenated' is vague here. Since the XQuery
result does not support nested sequences, if a tuple contains
a sequence, all the items of the sequence become the items of the
sequence for the return clause of the FLWOR expression. So in this
sense, the 'concatenation' here really means "Constructing Sequences"
as defined in "3.3.1".  We should define this concatenation process  to be the same as the construction of Sequences specified in 3.3.1.
This also implies that the empty sequence in the tuple is dropped as defined in constuction of Sequences. 'concatenation' does not clarify whether the empty sequence is dropped.

- Steve B.

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

         

SECTION 2.6.6.1: XQuery flagger

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

- Steve B.

			
            
no more flagger.
		
         

SECTION 2.6.6.1: XQuery flagger

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

- Steve B.

			
            
flaggers deleted.
		
         

SECTION 3.2: Path Expressions

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

- Steve B.

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

            
Issue closed with no change to documents

            
(joint issue)

         

SECTION 3.1.2: Variable References

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


- Steve B.

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

SECTION 3.12.2: Typeswitch

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

- Steve B.

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

         

SECTION 2.6.6.1: XQuery Flagger

If the XQuery flagger is enabled, then a static error is raised if the query contains a must-understand extension.
A warning would be more appropriate/useful.

SQL has the (FIPS) flagger which raises only warnings for vendor specific SQL extensions.


- Steve B.

			
            
no flaggers, no must-understands
		
         

SECTION D.2: normative references

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

- Steve B.

            
The references are all there now.

         

SECTION A.2.2: lexical rules

KINDTEST, KINDTESTFORPI, CLOSEKINDTEST, OCCURRENCEINDICATOR and
SCHEMACONTEXT states do not allow comments, pragmas or must-know
extensions.  This seems unnecessarily limiting to forbid these
within kind tests.

- Steve B.

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

         

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

         

SECTION A.2.2: lexical rules

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

- Steve B.

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

         

            


            
Fixed, as per some other LCCs.

         

            
[[accepted]]

         

SECTION A.2.2: lexical rules

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

- Steve B.

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

         

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

SECTION A.2.2: lexical rules

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


- Steve B.

            
Duplicate of 2004Feb0853.

         

SECTION A.2.1: white space rules

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



- Steve B.

Accepted.

            
[[accepted]]

         

SECTION A.2: lexical structure

Some of the rules called "Named Terminals" should have a
/* ws:explicit */ comment attached to indicate that ignorable
whitespace may not be interspersed, namely
Digits, ExcapeQuot, HexDigits, and probably the ones
that are copied in from other recommendations (S, NCName, QName,
Char).  Note that the quantifiers + and *, as in
rule [16] Digits ::= [0-9]+, normally imply the ability to insert
whitespace between the repeated items.  Compare with
rule [42] FLWORExpr ::= (ForClause | LetClause)+ ...
which certainly permits whitespace between consecutive for and
let clauses.

This is almost every rule under "Named Terminals", which made
me wonder whether you intended all of these rules to have
an implicit /* ws:explicit */ comment.  However, that principle
would break down in a couple places: Pragma, MUExtension, and
SchemaGlobalTypeName.

Perhaps the solution is to move Pragma, MUExtension and
SchemaGlobalTypeName into the list of "Non-Terminals".
I think you are trying to list under "Named Terminals"
the kinds of tokens that would be recognized by a lexical
analyzer, and these three things seem more complex than usually
delegated to a lexer.

If you adopt this solution, you can simply state that the
entire category has a /* ws:explicit */ comment.  However,
this would still leave the problem of the duplicates of
these rules in the main body of the text, where they will probably
need to be individually flagged with /* ws:explicit */


- Steve B.

Accepted.

SECTION A.1: EBNF

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

  Varname ::= '$' QName /* ws: explicit */

and eliminate all the places where '$' appears as an operator
sign.

- Steve B.

Accepted (Scott's rejection of the comment).

Jim objects to allowing a variable reference such as "$ x"

SECTION A.1: EBNF

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


- Steve B.

            
See [446].  Excerpt:

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

         

Proposal accepted.

            
[[accepted]]

         

SECTION 4.12: function declaration

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


- Steve B.

Proposal accepted.

            
[[accepted]]

         

SECTION 4.10: xmlspace declaration

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


- Steve B.

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

SECTION 3.8: FLWOR expressions

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

- Steve B.

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

SECTION 3.7.3.1: computed element constructors

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


- Steve B.

            
Already fixed.

         

SECTION 3.7.2: other direct constructors

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

- Steve B.

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

         

            


            
RESOLUTION: accepted, refer to production in XML

         

            
[[accepted]]

         

SECTION 3.7.2: other direct constructors

The XQuery Data Model, section 6.6.3 "Comment information items",
says that "Although the data model is able to represent comments,
it may be unnecessary or even onerous for some applications to do
so.  Applications should construct nodes in the data model to
represent comments. The decision whether or not to represent
comments is considered outside the scope of the data model,
consequently the data model makes no attempt to control or
identify if any or all comments are ignored."

Does this mean that support for direct and computed comment
constructors is optional for an XQuery implementation?

- Steve B.

SECTION 3.7.2: other direct constructors

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



- Steve B.

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

         

            


            
Don and Michael R thought this was already done

            
RESOLUTION: partly accepted already, resolving jan0093, but should

            
also be excluded from the BNF

         

            
[[accepted]]

         

SECTION 3.7.1.3: content

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

- Steve B.

SECTION 3.7.1.3: content

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

- Steve B.

SECTION 3.7.1.3: content

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

- Steve B.

SECTION 3.7.1.3: content

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

- Steve B.

            


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

         

SECTION 3.7.1.3: content

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

- Steve B.

            


            
Rejected, since if rules A and B were reversed, we would be

            
constructing a text node, then looking for entity references, we

            
might create a new entity reference at run-time. We have the right

            
rule in the spec - "whitespace characters generated by character

            
references such as   or by CDATA sections are not considered

            
to be boundary whitespace". We accept that the rules, as given,

            
describe the result of the implementation, and not the algorithm.

         

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

         

SECTION 3.7.1: direct element constructors

Consider the following example:

<a>{attribute b {1}}</a>

Question: is this acceptable syntax, or is it an error because
the }} is interpreted as a literal for right curly brace?
If it is not acceptable, then it would be helpful to say that
if the user has an expression requiring two successive }s, then the
user should put whitespace between them.  If it is acceptable,
then you should qualify that }} is interpreted as a literal for
a right curly brace unless used in a context where two successive
right curly braces would be acceptable.

According to the tables in A.2.2, }} is only recognized in state
ELEMENT_CONTENT.  I simuled the rules in these tables on the
example above and found that it is in state OPERATOR when the }}
is encountered.  The OPERATOR state recognizes } but not }}.
My tentative conclusion is that the example is valid and }} can be used to close two expressions, and not always as a literal for right curly brace.
This appears to be the user-friendly answer, but I worry that
users will find it hard to know when }} is a literal for a
right curly brace and when it is two closing curly braces.

One solution would be to do away with }} as a literal for
curly brace.  Instead, you might define a character reference.

- Steve B.

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

         

            


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

         

            
[[rejected]]

         

SECTION 3.5.3: node comparisons

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

- Steve B.

            


            
Rejected because (1) path expressions that span documents are not

            
well-defined in the absence of document order, and (2) adopting

            
this proposal would frequenty require implementations to determine

            
whether two nodes are in the same document, imposing unnecessary

            
overhead.

         

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

         

SECTION 3.5.2: general comparisons

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


- Steve B.

            


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

         

SECTION 3.1.1 : literals

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



- Steve B.

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

         

            


            
Closed with editorial change by Don.

         

            
[[accepted]]

         

SECTION 3.1.1: literals

May an implementation define additional PredefinedEntityRefs?
For example, could an implementation define € as € ?


- Steve B.

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

SECTION 2.6.6.1: XQuery flagger

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

- Steve B.

			
            
no more flagger.
		
         

SECTION 2.6.6.1: XQuery flagger

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


- Steve B.

			
            
no more flagger
		
         

SECTION 2.6.6: must-know extensions

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

- Steve B.

Accepted.

SECTION 2.6.6.1: XQuery flagger

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

- Steve B.

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

         

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.6.1: XQuery flagger

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



- Steve B.

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

         

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.6: must-understand extensions

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

MUExtensions ::= "{:" QName ExtensionContents* ":}"

MUExtensions ::= "ext" "{" QName ExtensionContents* "}"


- Steve B.

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

         

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.5: pragmas

Can a pragma include a must-understand extension?  For example,

(:: pragma my:pragma (:: extensions my:ext ::) ::)

In this example, is "(:: extension my:ext ::)" to be interpreted as a must-understand extension sitting in a place where ignorable whitespace can go, or is it the value of PragmaContents?

What are the semantics of this ?


- Steve B.

            
Proposal: No.

         

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.5: pragmas

Can a Comment be nested in a Pragma?  Section 3.1.6
"Xquery comments" says that "Comments may be used anywhere
ignorable whitespace is allowed."  In the following example:

(:: (: comment 1 :)
pragma (: comment 2 :)
prefix (: comment 3 :)
: (: comment 4 :)
localname (: comment 5 :)
contents (: comment 6 :)
more contents (: comment 7 :) ::)

which of the comments are acceptable?

- Steve B.

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

         

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.5: pragmas

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

- Steve B.

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

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

            


            
Already Done.  Issue closed.

         

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

         

SECTION 2.6.2: static typing feature

Section 3.7.3.1 "Computed element constructors" gives an
interesting example of a way to construct an element with the
same name as a given element, but with a different content.
The note following the example says that the example is not
portable because it will not work under the Static Typing
Feature.  To me, this example calls into question the utility
of the feature.  The note gives a workaround, using the function
fn:exactly-one, and the F&O has additional functions which will
overcome certain other static typing issues.  The conclusion I
draw is that anyone interested in portable programming will
be required to use these functions as guards to explicitly
disable the static typing feature, in case the application is
ported to such an implementation.  The purpose of the guard
functions is to give the application precisely the behavior it
would have had if the static typing feature were not supported.

I am wondering if the problem is in an overly fastidious
notion of what static typing should do for the user.
To me, a function invocation fct(arg) whose sole parameter is
declared to be item() or item()+ with an argument arg whose static
type is item()? or item()* does not look like a static type error,
because it is possible that the command will succeed at run-time.
I suggest that the static typing feature should raise type
errors when the static type of an actual argument or operand
has empty intersection with the required type in that position.
In such a case it is a certainty that there would be a run-time
error, and therefore a user benefit to provide early detection of
such errors.  I can see this as a user benefit even if the
code is unreachable, because it probably reveals a logic error on
the user's part.  But to raise static errors for situations
that might run successfully on certain inputs seems like a
disservice to the user.

- Steve B.

            49. +qt-2004Feb0593-01 ORA-XQ-092-B: definition of static typing is too
rigorous to be useful
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.

         

            


            
Andrew/Dana  If static type is off then there is no way to tell the

            
level of conformance.

            
Jonathan  Need more user experience. Hesitant to close issue.

            
Comment is too general to be useful.

            
Michael R.  No reason to change rigorosity.

            
(Dana and Andrew agreed)

            
Dana  Better to raise a Formal Semantic issue instead.

            
Issue closed with no further action.

         

SECTION 2.5.2: Handling dynamic errors

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


- Steve B.

            


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

            
which was adopted 4 May.

         

SECTION 2.6.1: Schema import feature

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

- Steve B.

            47. +qt-2004Feb0591-01 ORA-XQ-088-C: enforcement of imported schema
consistency
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.

         

            


            
Don - Imported schemas must be consistent otherwise error is raised.

            
Michael K - Not required to be detected by Query.

            
Jonathan -  Raised error if schemas are inconsistent.

            
Liam two issues as he sees it:

            
Buxton comment correct?

            
Changed how schema import works  Maybe taking to mailing list?

            
Issue closed with no further action.

            
There is no contradiction as suggested by the comment, because

            
these are two different kind of constraints.

         

SECTION 2.2.5 : Consistency constraints

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

- Steve B.

            46. +qt-2004Feb0587-01 ORA-XQ-080-C: Enforcement of consistency constraints
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

         

            


            
Andrew  It may be a duplicate from another comment (????).  Don had an

            
item regarding solution.  Add sentence on top of consistency constraints

            
paragraph.

            
This issue is closed as resolved by ORA-XQ-217-C  No further action required

         

SECTION 2.2.3.2: dynamic evaluation phase

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

- Steve B.

            45. +qt-2004Feb0585-01 ORA-XQ-078-B: XQuery should permit partial
static typing
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.

         

            


            
Jim Melton - yes If implementation does not support static typing it can

            
detect whichever errors it can.

            
Don -  Wording was already changed as per Oracle's suggestion.

            
Dana  If static typing not supported, then type errors must be

            
raised during dynamic evaluation

            
Don  Yes they may.be

            
Issue closed with no further action.

         

SECTION 2.2.3.1 : Static analysis phase

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

- Steve B.

            44. +qt-2004Feb0583-01 ORA-XQ-076-C: Is "let $i = ()" permitted?
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.

         

            


            
There are two issues issues here as viewed by Liam

            
is not a static type error as suggested by Steven Buxton

            
Is the behavior the desired one.

            
Andrew - This Rule may expressed too widely

            
Liam  Proposed closed this issue.

            
It is not a static error, but if "return $i" is added, it

            
becomes one.

            
Andrew to follow up with a question to see is group ok with the current

            
Behavior.

            
Mary: Keeping it open it's a bad idea.

            
Issue closed with no further action.

         

SECTION 2.1.2: dynamic context

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

- Steve B.

            43. +qt-2004Feb0576-01 ORA-XQ-073-C: "available documents is not
constrained by ... statically known documents"
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.

         

            


            
This issue was partly solved under section 2.1.1.

            
Jim Melton - will like a more specific note regarding weather

            
statically  known Documents are available,

            
Don -  This is already specific enough.

            
Andrew  Question is already answered.

            
Jim -  Said he can live with current wording.

            
Issue closed with no further action.

         

SECTION 2.1.1: Static context

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

- Steve B.

            42. +qt-2004Feb0565-01 ORA-XQ-069-E: what is the default type of a
collection?
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()*.

         

            


            
Issue closed with no further action.

            
Default type of a collection should node()*.

         

SECTION 2.1.1: Static context

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

- Steve B.

            
There was a feeling we had already dealt with this issue or others
like it. KK pointed to 2004Feb0990-01, an F+O issue, "Please define
collations", which was accepted and closed in August.
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.

         

SECTION 2.1.1: static context

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

- Steve B.

            


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

            
RESOLVED WITH NO CHANGE.

         

SECTION 2.1.1: static context

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


- Steve B.

            


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

            
RESOLVED WITH NO CHANGE.

         

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

         

SECTION 2: Basics

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

- Steve B.

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

         

            


            
ADOPTED RESOLUTION:

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

            
DONE. See:

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

         

SECTION 2.2.3.1: Static Analysis Phase

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

- Steve B.

            


            
MR and JS explain the way it is done by normalization. It can be done

            
sequentially or not. The formal semantics does it sequentially.

            
MR: Have the pointer to formal semantics, but do not change current

            
wording.

            
DC: pointer is already there.

            
RESOLVED WITH NO CHANGE.

         

SECTION 2.2.5: Consistency Constraints

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

- Steve B.

            


            
DC: Constraints define the circumstances under which XQuery is

            
well-defined. So there is no way to define errors or detect it.

            
This seems true for all except for the one referred to in

            
+qt-2004Feb0548-01 which is only in this category for XPath.

            
PC: Proposal: Make variable one XPath only. Add sentence to explain

            
axiomatic nature.

            
JM: proposed wording :

            
"This specification does not define the results of an XQuery[/XPath]

            
expression under any condition where one or more of these constraints

            
are not satisfied."

            
MR: Just need to make sure that the variable alignment is not removed

            
from XQuery.

            
AE: This is still guaranteed by section on dynamic context.

            
ADOPTED RESOLUTION:

            
Deleting bulleted item in Oracle comment for both.

            
Adding Jim's proposed wording for both.

         

Section 3.13 Validate Expressions
Technical

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

            


            
DC: Corrected in current editor WD.

            
FIXED.

         

Section 3.13 Validate Expressions
Technical

We consider the validate expression (and the implicit validation on
element construction) to be too complex and potentially confusing to
users for the following reasons:
- Validate will validate against all ISSD. Most usecases we come across,
users want to validate against a specific output schema. Since that can
be done outside of the XQuery statement, the validate expression becomes
less useful.
- The schema context part of validate is pretty complex and most users
will not understand it at the beginning. This looks like a good vNext or
optional feature.

Thus we would like to propose:
1. Make default validation mode to be skip
2. Remove Schema context from the spec
3. Make support for validation modes lax and strict and the validate
keyword an optional feature.

(See also MS-XQ-LC1-089).

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

         

Section 3.10 Conditional Expressions
Technical

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

            
Same as qt-2004Jan0378-01

            
PaulC: so, new evidence to make this decision?
anybody that can't live with changes?

            
Yes: at least Don, Robie.


            
So, resolved: rejected.

         

            


            
DC: else is still required.

            
Was done at Mandelieu F2F and REJECTED.

         

            
[[rejected]]

         

Section 3.8.3 Order By and Return Clauses
Technical

Provide an XQuery prolog statement affecting the static context to
define empty sort default.

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

         

Section 3.7.3.7 Computed Namespace Constructor
Technical

How can I declare a default namespace? I always have to provide the
NCName. Can we make the NCName optional and then make it define the
default namespace?

            
this has been subsumed by a response to an earlier comment

         

3.7.3.5 Computed Processing Instructor Constructor
Technical

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

            


            
Some discussion to investigate impact of proposed change. Since

            
xs:NCName is a subtype of xs:string we can just drop xs:QName.

            
ADOPTED.

         

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

         

Section 3.7.3.5 Computed Processing Instructor Constructor
Technical

Also allow an instance of xdt:untypedAtomic as a name value.

            


            
ADOPTED.

         

            
ADOPTED.

         

Section 3.7.3.1 Computed Element Constructor
Technical

"A computed element constructor automatically validates the constructed
node, using the validation mode and validation context from its static
context, as described in 3.7.1.5 Type of a Constructed Element. If the
name of the constructed element is specified by a constant QName, this
QName is added to the validation context for nested expressions. On the
other hand, if the name of the constructed element is specified by a
name expression, the validation context for nested expressions is set to
global.":

The fact that the validation context stays global inside a constructor
that has a name expression will be confusing and hard to explain. Users
will expect that the validation is done at runtime, so the validation
context in this case should be a runtime context. We can solve this by
either not doing implicit validation on element construction (regardless
if literal or computed element constructor), or by saying that the
context will not be known until runtime in this case.

Section 3.7.1.5 Type of a Constructed Element
Technical

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

            


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

            
reword this section.

            
Comment has been RESOLVED, please check new section.

         

Section 3.7.1.5 Type of a Constructed Element
Technical

We believe that implicit validation on element construction (and
validation in general) adds considerable complexity to XQuery. However,
there is still value in having input data typed.

Therefore we propose to decouple validation from the schema import and
either remove validation from XQuery or make it a separate optional
validation feature (that then may also add the validation mode
preserve).

Thus, an implementation would only have to support the semantics of
validation mode = skip in the base conformance.

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

Sections 3.7.1.3/3.7.3.3
Technical

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

            
Accepted and closed by adopting the following proposal:

            
Content of element constructors, computed element constructors, and

            
document node constructors no longer raise errors for document

            
nodes - instead, the contents of the document node are copied into

            
the content of the constructed element or document.

         

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

         

Sections 3.7.1.3/3.7.3.1/3.7.3.3
Technical

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

            
Changes earlier resolution

         

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

         

Section 3.7.1.3 Content
Technical

"Predefined entity references and character references are expanded into
their referenced strings, as described in 3.1.1 Literals.

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

Section 3.7.1.2 Namespace Declaration Attributes
Technical

Namespace declaration attributes should not affect the in-scope
namespace static context for expressions. We think that only the ones in
the prolog should affect the namespace prefixes inside expressions.

We find the following semantics to be confusing:

declare namespace b="uri1"; <a xmlns:b="uri2">{/b:c}</a> will look for
{uri2}:c and not {uri1:c}. "uri2" should only affect the construction
part.

The same should then also hold for the computed constructors.

Thus, we would like to have the following behaviour:

Namespace declaration in prolog: Provides static namespace prefix
bindings for both constructors and expressions

Namespace declaration on construction: Provides static namespace prefix
bindings for constructors only, not for embedded expressions.

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

         

Section 3.7.1.1 Attributes
Technical

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

            


            
>

            
> Status: See Don's request for review:

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

         

Section 3.7.1.1 Attributes
Technical

"Predefined entity references and character references in the attribute
content are expanded into their referenced strings, as described in
3.1.1 Literals.

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

            
This has been already REJECTED and publicly announced in

            
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.

         

Section 3.2.1.2 Node Tests
Editorial

Remove reference to namespace node (there is no way to perform a node
test on it in XQuery)

            
JR:  This has been done.

         

            
The offending text no longer occurs

         

XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003

3.1.6 XQuery Comments

"Comments may be used anywhere ignorable whitespace is allowed. See
A.2 Lexical structure for the exact lexical states where comments are
recognized."

In the followin