XQuery 1.0: An XML Query Language

Section 3.1.5 Function Calls	
Editorial	

Please reword: " parameteror " with " parameter or "

Section 2.1.1 Static Context	
Editorial	

"environmentor" => "environment or"

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.
			

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/

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/

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

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

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.

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.

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.

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.

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.

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.

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.

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.

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/

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

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.

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.

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.

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/

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.

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.

Query Lang [2.1.1, C.1] Default function namespace

   "[Definition: Default function namespace. This is a namespace URI. This
   namespace URI is used for any unprefixed QName appearing as the function name
   in a function call. The initial default function namespace may be provided by
   the external environmentor by a declaration in the Prolog of a module.]"
                           
But the table in appendix C.1 says that the default function namespace is fn.

By 2.1.1, the spec does not make clear that the default function namespace is
"http://www.w3.org/2003/11/xpath-functions" and appears to license
implementations to not have a default function namespace at all, or have it
bound to something else by default. For portability and overall simplicity, the
default function namespace in a main module should simply be set.

Solution: Replace the definition in 2.1.1 quoted above to:
   "The initial default function namespace is set to
   'http://www.w3.org/2003/11/xpath-functions' but may be overridden by a
   declaration in the Prolog of a module."

Query Lang [Appendix B] xs:string/xs:anyURI

Given the lack of a formal derivation relation between xs:string and xs:anyURI, 
there is a serious usability issue for any function (such as the fn:doc
function) that expects a URI as an argument. If the argument is declared as
xs:string, users will get type errors if they pass data that happens to be
xs:anyURI. Conversely, if the argument is declared as xs:anyURI, users will get
type errors if they pass string literals. Either situation is likely to occur
in practice. We therefore request that xs:anyURI and xs:string be subject to
special promotion rules, such as those applying to xs:float and xs:double to
avoid this problem.

Specifically: A function that expects a parameter $p of type xs:string can be
invoked with a value of type xs:anyURI and a function that expects a parameter
$p of type xs:anyURI can be invoked with a value of type xs:string.

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.

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.

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

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.
			

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.
			

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.

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.

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.

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.

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.

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?

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.

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.

(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

(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

(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

(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

(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

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

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.
			

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.
			

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.

SECTION 3.2: Path expressions

It says that "//" at the beginning of a path expression is an 
abbreviation for fn:root(self::node()) treat as document-node()/
descendent-or-self::node().  As noted, this will cause an exception
if the root is not a document node.  This seems arbitrary.  Why
not permit // when the root of a node is just an element node, 
for example?


- Steve B.

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.

SECTION 2.5.3: Errors and Optimization

In 2.5.2 and 2.5.3, it is clear from the spec that if an expression raises a dynamic error, than an implementation may choose to return a value or raise the dynamic error. 

However, the spec needs to clarify the rules when there 
are no errors in an exhaustive implementation.

In general, we should state the following regarding Errors and Optimizations:
An exhaustive mode XQuery evaluation evaluates every expression of an XQuery except for the case
of conditional and typeswitch expressions in which only the actually selected
branch can potentially raise dynamic errors.

A non-exhaustive mode XQuery evaluation is an optimized mode XQuery
evaluation which
may NOT evaluate every subexpression of an expression so as to achieve optimal
performance.

Rule1: Non-determinism  in the presense of error.
If the exhaustive mode XQuery evaluation raises dynamic errors, then an optimized
mode XQuery evalution is permitted to either  raise dynamic errors or
return a value. 

Rule2: Determinism in the absense of error.
If the exhaustive mode XQuery evaluation raises NO dynamic error,
then an optimized
mode XQuery evalution is NOT permitted to raise any dynamic errors and should
return the same value as the exhaustive mode XQuery expression. 

- Steve B.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.
			

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.

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.

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.

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.

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.

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.

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.
			

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.
			

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.
			

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.
			

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.
			

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.
			

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.

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.
			

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

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.

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.

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
			

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.

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.
			

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
			

Section 3.6	Logical Expressions (and 2.3.3 Effective Boolean Value)
Technical

We should simplify the rules for the implicit effective Boolean values
to allow dispatch of most checks based on static information:

EBV(X) should be true if:

X is a non-empty sequence of nodes
X is the atomic value xs:boolean(true)

EBV(x) should be false if:

X is an empty sequence
X is the atomic value xs:boolean(false)

EBV(x) should be a type error if:
X contains an atomic value other than Boolean
X is a sequence of Boolean values

Note that this means that:
A zero-length value of type xs:string or xdt:untypedAtomic
A numeric value that is equal to zero
The xs:double or xs:float value NaN

All return a type error.

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)

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

3.1.6 XQuery Comments

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

In the following queries, a comment is placed where ignorable
whitespace would appear to be allowed, but where the A.2.2 machine
has no transition on "(:".  So which is correct? Does the comment
cause a syntax error or not?

    node( (:test:) )

    processing-instruction( xml-stylesheet (:test:) )

    element( person (:test:) )

    element( hospital / (:test:) staff / person )

    <shoe (:test:) size="7"/>

    <fact>I saw 8 cats.</fact (:test:) >

    9 cast (:test:) as hatsize

-Michael Dyck

Proposal accepted.

				
[[accepted]]
			

XQuery: specification unclear

Section: 3.7.1.2 paragraph two says:

"A namespace declaration attribute is used inside a direct element 
constructor, and serves to add a namespace to the in-scope namespaces 
for the constructed element, or to specify the default element/type 
namespace within the scope of the constructed element."

What does it mean "within the scope of the constructed element"? Does 
the scope refer to the
XML forest rooted at the given element constructor or the XQuery 
expressions that are lexically placed
within the "{" and the "}" ? Or both ?

This a very important point and the notion of "scope" is too fuzzy.

XQuery:  syntax simplification request

Why is the Expr optional on the production [105] ?

If the expression is not present the entire text constructor
returns the empty sequence, so why support this syntax ?

				
Adapt the proposal
			

XQuery: incomplete specification

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

XQuery: (potentially) editorial

Section 3.1.5 (Function calls) when it describes the
function conversion rules, it says that in case of
a function invocation from a different module the
type test has to be true in both modules.

This  is surprising. Does this mean that we are allowed
to write in a library module:

define function f($x as ns:shoeSize?)
(: ns:shoeSize derives from xs:integer here :)
{()}

while the importing module contains:

declare external variable $y as ns:shoeSize?;
(: ns:shoeSize derives from String here :)

f($y)

and have the call f($y) succeed  if $y is bound to the
empty sequence ?

This is surprising. Did I misunderstand something?
Is this is not allowed, where is the text that forbids this case?(maybe)

XQuery: incomplete specification, request for clarification

The XQuery specification does not seem to require that all the in-scope
schema definitions that are referred in a variable type declaration
or a function signature of an imported library module have to also
be in scope in the importing module.

Moreover, the XQuery specification does seem to impose any consistency 
constraints
between in scope schema definitions in the static context of a main 
module
that imports a library module and the in scope schema definitions with 
the
same names in the library module.

Both should be required as consistency constraints, and stated in 
section 2.2.5.

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

Regards,    Martin.

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

Regards,    Martin.

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


Regards,   Martin.

Proposal accepted.

				
[[accepted]]
			

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

It is not too difficult to predict that typing will be a headache
for many people for XQuery and XSLT2. Please do anything and everything
that you can to reduce the problems.

The different concepts around types, the different types, the different
rules for conversion,... will make typing very difficult to use. It would
be very good to have some section (maybe an appendix) summarizing all
the rules, and giving people a chance to get an overall grasp. Giving
parallels e.g. to well-known programming languages (if and where they
exist) may also help.

Another issue is that it is not completely predictable, and not
completely interoperable, which XML Schemas will be taken into
account and which not. XQuery Schema Import does a lot to make this
more predictable, but this should be completely predictable.
'augmentable by implementation' does not lead to interoperability.

A typical example of this is the "implementation-dependent mechanism
for determining whether an unknown type is compatible..." in
2.4.4 of XPath.


Regards,    Martin.

For many applications, namespace node preservation is overweight. For
others, it is needed. The current definition of XQuery can easily
result in large numbers of superfluous namespace nodes, especially
when querying documents that use several namespaces.

Consider the following data, taken from the DOM Issues List:

<issues xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns="http://www.w3.org/2003/10/issues"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">

  <header>
    <title>DOM Level 3 Core Issues List</title>
    <!-- SNIP -->
  </header>
</issues>

Now consider the following query, applied to this data:

<out>
{
 doc("dom-issues.xml")/issues/header/title
}
</out>

Here is the result, according to our current spec:

<out>
 <title xmlns:xlink="http://www.w3.org/1999/xlink"
  xmlns:xi="http://www.w3.org/2001/XInclude"
  xmlns="http://www.w3.org/2003/10/issues"
  xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
  >DOM Level 3 Core Issues List</title>
</out>

Although none of these namespaces are actually used in the title
element that was retrieved, our current specification require that all
namespaces in scope in the original document must be in scope for the
copied element in the constructed element. Now suppose that we create
several namespace-decorated documents like this one, and perform an
XQuery that copies from each of these to create a new document with
even more namespaces...

Naturally, we do need to ensure that namespaces are preserved if they
are used in element names, attribute names, or QNames. Consider the
following query:

doc("dom-issues.xml")/issues//originator

The result must preserve the above-mentioned namespaces to allow
correct interpretation:

<originator xlink:type='simple'
xmlns:xlink="http://www.w3.org/1999/xlink"
xlink:id="2004Feb/mailto:caillon@netscape.com">Christopher Aillon</originator>

There are also XML vocabularies, such as XML Schema or XSLT, that use
QNames in content, and for these, all QNames really must be
preserved.

I think we should provide two modes of operation:

1. Namespace preserving copy keeps all namespace nodes

2. Normal copy keeps only namespace nodes used in element names,
   attribute names, or instances of xs:QName.

One possibility would be to declare this at a global level:

  declare namespace-preserving = "true";

Another possibility would be to declare namespace preservation for
specific namespaces:

  declare namespace-preserving = "http://www.w3.org/2001/XMLSchema",
     "http://www.w3.org/1999/XSL/Transform";

Either of these would reduce the overhead associated with copying
elements significantly in some implementation environments.

Jonathan

(IBM-XQ-015) XQuery currently defines three validation modes: strict, lax, 
and skip, based on the three validation modes of XML Schema. In skip mode, 
no validation is applied to a newly-constructed element. Instead, the new 
element node (and each of its descendant elements) is given the annotation 
xdt:untyped, and its attributes (and the attributes of its descendants) 
are given the annotation xdt:untypedAtomic. If the content of the new 
element is copied from existing nodes, the types of these existing nodes 
are lost.

An XQuery implementation that does not support Schema Import will probably 
run in skip-validation mode, since validation is meaningful only if a 
schema is present. Nevertheless, such an implementation may wish to 
preserve the type annotations on nodes in input documents, since these 
type annotations may affect the processing of a query (for example, 17 > 5 
is true for the xs:decimal type but not for the xdt:untypedAtomic type). 

The loss of type information during skip validation causes a serious 
problem for applications that need to "wrap" an element in a higher-level 
"envelope" element. The wrapping is done by referencing the "content" 
element inside a constructor for the "envelope" element, causing the 
content element to be copied and validated. It is quite possible that the 
"content" element may not be defined in the in-scope element declarations. 
This may happen if the current application is a generic message-routing 
application that does not find it practical to import the schemas for all 
possible contents. It will also happen in systems that do not implement 
the Schema Import feature. In these cases, skip-validation causes the loss 
of the type information on the "content" element. 

Here are some examples of this problem (assuming skip validation in each 
case):

(a) Copy a set of "customer" elements into newly-constructed 
"rated-customer" elements, pairing each customer with a rating. Now order 
all the rated-customers by balance-due. Balance-due was originally 
decimal, but now its type has been lost and 5 is sorted as greater than 
17.

(b) Write an application to extract data from an XML document and wrap it 
in <row> and <col> tags for interfacing to a relational database. By 
wrapping the data in <row> and <col> tags, its original types are 
destroyed and all the data appears to be text. Again, data that was 
originally decimal will be sorted incorrectly.

(c) If a query-rewrite pushes a predicate inside a constructor, the effect 
of the predicate is changed because the expression inside the constructor 
is typed but outside the constructor it is not. This limits the ability of 
the system to do query optimization and to merge queries with view 
definitions.

The solution to these problems is to introduce a new validation mode 
called "skip preserve", or simply "preserve". In this mode, no validation 
is attempted, and the type annotation of the subject element remains 
unchanged rather than being set to xdt:untyped. Adding this validation 
mode would not affect the definitions of the existing three modes. 

The following changes would be made to the XQuery specification by this 
proposal:

(a) In Section 2.1.1, Static Context: In definition of Validation Mode, 
add "preserve"  or "skip preserve" to the list of modes.

(b) In the grammar production for ValidationMode, add the a keyword for 
the new option. 

(c) In Section 3.7.1.3, Direct Element Constructors--Content: Rule (1d) 
should be changed as follows: "If the validation mode is "preserve", 
copied element and attribute nodes retain their original type annotations; 
otherwise, copied element nodes are given the type annotation xdt:untyped, 
and copied attribute nodes are given the type annotation 
xdt:untypedAtomic."

(d) In Section 3.7.1.5, Direct Element Constructors--Type of a Constructed 
Element: Add the following initial sentence:
"A direct element constructor assigns the initial type annotation 
xdt:untyped to the newly constructed element node. It then validates the 
new node, using the schema validation process defined in XML Schema."
Also in Section 3.7.1.5, change the first bullet as follows: "If 
validation mode = skip or preserve, no validation is attempted. The 
constructed element retains its type annotation of xdt:untyped, and its 
attributes and descendants retain the type annotations assigned to them 
during construction."

(e) In Section 3.14, Validate Expressions: Add the following bullet to the 
three bullets that define strict, lax, and skip validation: 
"preserve indicates that no validation is to be attempted, but that 
element nodes and attribute nodes are to retain their original type 
annotations."

(f) In Section 4.6, Validation Declaration: Add "preserve" to the list of 
validation modes.

Note that these changes will align XQuery with XSLT 2.0, which has already 
introduced the concept validation="preserve" as documented in 
http://www.w3.org/TR/xslt20/#validating-constructed-nodes. The XSLT 2.0 
definition of validation="preserve" is consistent with the definition 
above, and these definitions should be kept consistent.

--Don Chamberlin

(IBM-XQ-011) Section 3.14 (Validate Expression) states that validating a 
node destroys its identity. I believe that this issue needs more thought. 
The reason for giving a new identity to a validated node is that some of 
its contents may change (for example, default attributes may appear). But 
consider the following:

(a) The validated note has the same parent as the original node, right? 
Doesn't this mean that the content of the parent node has changed? If the 
parent node can retain its identity, why can't the validated node retain 
its identity?

(b) The working group expects to define update operators that can change 
the state of a node while preserving its identity. But presumably the 
updated node will need to be revalidated for type-safety. If validation 
destroys node identity, how can updates preserve node identity? This seems 
to violate our XQuery Requirement (3.2.5) that XQuery must be defined in a 
way that does not preclude the later introduction of update operators. 

(c) Requiring validation to generate new node identities also raises 
questions about Requirement (3.4.13) that queries must be able to preserve 
the identity of items in the Data Model.

(d) Requiring validation to generate new node identities also may place an 
unnecessary burden on implementations that perform incremental validation 
on the data model rather than serializing it and revalidating the whole 
tree from scratch.

(e) Suppose $n is bound to an element node.
Is "$n is validate{$n}" true?
Is "$n/.. is validate{$n}/.." true?
If the answers are not the same, why not?

--Don Chamberlin

(IBM-XQ-009) Section 3.7.1.5 (Type of a Constructed Element) uses the 
following example:
<a xsi:type="xs:integer">47</a>
But Section 3.7.4 (Namespace Nodes on Constructed Elements) says that a 
similar example is not valid:
<p xsi:type="xs:integer">3</p>

This illustrates an error that many users will make. The namespace "xs" 
that contains all the built-in schema types is not in scope for a 
constructed element unless it is explicitly declared.

We need to correct the inconsistency between the two sections noted above. 
This can be done in either of the following ways:

(a) We can make a rule that the "xs" namespace, like the "xml" namespace, 
is automatically in scope for all constructed elements. I recommend this 
approach, because I believe that the justification for "xs" is at least as 
good as for "xml". This will remove a common source of errors and 
frustration.

(b) We can replace the example in Section 3.7.1.5 with the following ugly 
but correct example:
<a xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:integer>47</a>
(along with an embarrassing explanation about why it this is necessary and 
an apology to users).

--Don Chamberlin

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

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

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

The language documents should state that the value comparison operators 
are transitive except in cases where precision is lost in type-casting of 
operands.

--Don Chamberlin

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

--Don Chamberlin

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

--Don Chamberlin

The XQuery document notes that the following element constructor fails
with a validation error:
   
    <p xsi:type="xs:integer">3</p>

This is an unpleasant surprise for users - and there is a simple
solution. The specification already requires implementations to create
a namespace node for each namespace used in an element or attribute
name:

   A namespace node is created corresponding to each namespace
   declared in a namespace declaration attribute of this (or any
   enclosing) direct element constructor, each computed namespace
   within this (or any enclosing) computed element constructor, and
   the xml namespace. These namespace nodes use the same prefixes and
   URIs as the namespace declarations from which they are derived (the
   prefix becomes the name of the namespace node, and the URI becomes
   the string value of the namespace node).

   A namespace node is created corresponding to any namespace used in
   the name of the element or in the names of its attributes. However,
   a namespace node need not be created if there is already a
   namespace node for a given namespace URI on a given element. The
   string value of the created namespace node is the namespace URI of
   the element or attribute name. The name of the namespace node
   (which represents the namespace prefix) is  implementation-dependent;
   it must not conflict with the name of any  other namespace node
   for the same element.

A similar rule should be added to create a namespace node
for each namespace used in an instance of the xs:QName type.

Jonathan