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

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

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

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

A.2.1 White Space Rules

You should probably define what you mean by "white space", since it
isn't defined in the EBNF.

"White space is tolerated before the first token and after the last
token."
    The word "tolerated" is odd here. Perhaps change to "allowed".

    At the end of the sentence, append "of a module".

"White space is optional between terminals, except a few cases where
white space is needed"
    You must specify which cases.

    Also, after "except", I think you need to insert "for" or "in".

"to disambiguate the token."
    This is a misuse of the term "disambiguate" in its technical sense.
    Ambiguity (or the lack thereof) is a property of a grammar.
    Change "token" to "grammar".

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

"Special white space notation is specified with the EBNF productions,
when it is different from the default rules,"
    It's not clear what the default rules are. I think they started at
    "White space is optional". I believe it would increase clarity if
    you created a "Whitespace: default" subsection, and put the
    "default rules" under it.

"'ws: significant' means that white space is significant as value
content."
    As I understand it, this has nothing to do with specifying where
    white space is allowed: you could replace every "ws: significant"
    with "ws: explicit" and the set of legal queries would be the same.
    Specifying what is "significant as value content" is out of place
    here. (For instance, whether boundary whitespace is significant is
    controlled by the xmlspace declaration.)

I don't think the white space rules are precise enough to tell me
whether white space is allowed/disallowed/required between two terminals
that are derived from productions with different ws annotations (e.g.,
one "ws: explicit", one default).

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

"For XQuery,"
    Delete.

"White space is not freely allowed in the non-computed Constructor
productions, but is specified explicitly in the grammar ..."
    Change "non-computed" to "direct".

    This sentence is unnecessary, since the corresponding productions
    have the appropriate "ws" annotations. (It's a holdover from the
    days before "ws" annotations.)

"The lexical states where white space must have explicit specification
are as follows: ..."
    If you're talking about the states that have an explicit transition
    on white space (or on a symbol that can derive a whitespace
    character), then:

    --- The use of "must" is inappropriate, since it's not the
        implementor's job to ensure that you specify these transitions.

    --- Why is PROCESSING_INSTRUCTION included in the list?

    --- Why is EXPR_COMMENT excluded?

    If you're talking about something else, does it affect the
    interpretation of A.2.2?

    In either case, the sentence should probably be moved to A.2.2, or
    else deleted.

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

"For other usage of white space,"
    Other than what? Aren't all uses of white space covered by either
    "the default rules", "ws: explicit", or "ws: significant"?

"one or more white space characters are required to separate 'words'."
    What constitute "words"?

"Zero or more white space characters may optionally be used"
    Given "zero or more", "optionally" is redundant.

"around punctuation and non-word symbols."
    What constitues "punctuation"? or "non-word symbols"?

In sum, this paragraph is vague and unhelpful, and could probably be
construed to conflict with other requirements. Either delete it or make
it more precise and better related to the rest of the section.

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

Presumably, white space is disallowed anywhere that this section doesn't
say it *is* allowed. (If that's the case, it would probably be good to
mention it.) In particular, it would appear that white space is
disallowed *within* terminals (or at least, those that are derived from
a production without a "ws" annotation). Normally, this is sensible, but
it has some odd (and probably unintended) consequences:

    --- Because SchemaGlobalTypeName is a terminal, constructs such as
            type( schedule )
        or
            type (schedule)
        are illegal.

    --- Because Pragma and MUExtension are terminals, the spaces that
        appear around "pragma" and "extension" in the spec's examples
        of these constructs are illegal.

    --- All four "ws: explicit" annotations in the "Named Terminals"
        section are redundant.

There are various ways to deal with these cases, but I think the root
of the problem is defining the allowed locations for white space in
terms of "terminals" (or "tokens"), which I think is unnecessary.

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

The spec is inconsistent: "white space" or "whitespace"?

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

Also, the following sections:
    2.6.5 Pragmas
    2.6.6 Must-Understand Extensions
    3.1.6 XQuery Comments
    A.1.1 Grammar Notes (grammar-note: comments)
    E Glossary (must understand)
all refer to "ignorable whitespace", but this term is never defined.

-Michael Dyck

Proposal accepted.

				
[[accepted]]
			

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

Jonathan

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

Jonathan

Section 3.7.3.3 of the XQuery specification says that for
document constructors, "No schema validation is performed on the
constructed document." This seems inconsistent with implicit  
validation of elements. Consider the following element
constructor.

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

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

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

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

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

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

The status quo does not seem reasonable.

Jonathan

				
Already resolved in prior meetings.
			

"2.6.6.1 XQuery Flagger" says: "If the XQuery Flagger is
enabled, a static error [err:XQ0015] is raised if the query
contains a must-understand extension." This implies that the
XQuery Flagger must be available in the static context.

Jonathan

Currently the order of nodes constructed in a path is undefined for 
many cases. For example:

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

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

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

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

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

--Sarah

Forwarding to public comments list.

All the best, Ashok

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

Dear Ashok Malhotra,

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

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

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

Many thanks,
Kien

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

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

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

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

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

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

The following issue was identified during formal definition of
SequenceType matching.  Resolution of this issue is necessary to
complete closure of Issue 559 (New Sequence Type needs to be fully
implemented in Formal Semantics).

Current status: 

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

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

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

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

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

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

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

Problem 1: 

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

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

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

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

  An element person of type Person: 

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

   A type Company: 

     define type Company { 
       element ticker of type xs:string
     }
  
  and consider the sequence type:

    element(person, Company)

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

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

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

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

Possible solution 2: treat element(person,Company) as the following
local XML Schema element:
  
  <xs:element name="person" type="Company"/>

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


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

In Section 3.2 on Path Expressions, the XQuery draft says (twice):

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

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

Thanks,
Priscilla Walmsley

L.S.,

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

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

always

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

or can it also be

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

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

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

-- Jan Hidders

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

This is a badly lacking feature in XQuery:
AFAIK, there is no way to recover/catch a dynamic error after it happens.

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

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

Two possible solutions:

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

2) at the very least, consider modifying some functions like doc()
  so that they return a conventional value (eg the empty sequence)
  instead of raising an error

				

				
2. File exists.
				
RESOLUTION: rejected, closed
			

				
2. File exists.
RESOLUTION: rejected, closed
			

Hi Folks,

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

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

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

And ExprSingle is defined as follows:

 ExprSingle ::= ForExpr
              | QuantifiedExpr
              | IfExpr
              | OrExpr

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

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

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

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

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

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

				
Hi Roger.  I may be misunderstanding your question, but I think the answer 
is that OrExpr recurses down PathExpr.  You can follow the recursion 
basically by clicking on the first member of the right hand side of the 
BNF productions.  This particular cascade is what implements the built-in 
precedence.  Anyway, I believe the BNF to be correct, and the structure, 
dumped from the diagnostics of the test parser, is:

|XPath
|   Expr
|      QuantifiedExpr
|         Every every $
|         VarName part
|         In in
|         PathExpr
|            RootDescendants //
|            StepExpr
|               NodeTest
|                  NameTest
|                     QName part
|         Satisfies satisfies
|         PathExpr
|            VarName part
|            StepExpr
|               At @
|               NodeTest
|                  NameTest
|                     QName discounted

Note that the test parser reduces many of the unneeded steps, for instance 
for ExprSingle to PathExpr, as I think you would for most ASTs.

-scott
			

				
Hi Scott,

Hmm, I am not sure where you are getting that expansion - where does it say
the value of a quantifier's satisfies expression is a "PathExpr"?  I am
looking at section 3.9 of the latest XPath 2.0 spec and it says that the value
of a quantifier's satisfies expression is "ExprSingle", not "PathExpr", i.e.,

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

Note the use of "ExprSingle" in three places.

That said, PathExpr makes good sense.  So, I believe that section 3.9 needs to
be corrected to:

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

Agree?  /Roger
			

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

Best regards
Michael
			

				
To try and amplify Scott's response, note that OrExpr is an expression
that *might* contain an "or" operator, not an expression that *must*
contain an "or" operator. To simplify the grammar, when you have a
series of rules such as:

OrExpr ::= AndExpr ("or" AndExpr)*
AndExpr ::= ArithExpr (("+"|"-") ArithExpr)*
ArithExpr ::= PathExpr

then every PathExpr is an ArithExpr, and every ArithExpr is an AndExpr,
and every AndExpr is an OrExpr, and therefore you can use a PathExpr
everywhere an OrExpr is allowed, which means you can use it in the
"satisfies" clause of a quantified expression.

Michael Kay
			

Hi,

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

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

Thanks!

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

There seems to be a missing S between PITarget and Char* in the rule for 
XmlPI in the spec:

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

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

-scott

				
Hi Scott.  Your last call comment in [1] has been given the ID 
qt-2004Jan0360-01.  This is the official response from the XQuery and XSLT 
working groups.

Your issue pertaining to the error in the XmlPI has been accepted, and the 
WGs have approved the fix you suggested.  The production will read:

[110]           XmlPI      ::=          "<?" PITarget (S Char*)? "?>"   /* 
ws: explicit */

(Since I am writing this to myself, this mail should also provide the 
confirmation that this fix is satisfactory!)

-Scott Boag

[1]
					http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0360.html
				
			

I am raising this comment because I have seen several XQuery users make
mistakes as a result of the syntactic inconsistency between global
variable declarations and local variables, and there seems to be no good
reason why they are so different.

For global variables we write:

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

while for local variables we write:

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

I suggest changing the global variable syntax to:

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

An external variable would be:

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

Michael Kay

In section A.2.2 Lexical Rules, "<!--", "<?" and "<![CDATA[" go to 
XML_COMMENT, PROCESSING_INSTRUCTION, and CDATA_SECTION respectively 
with pushState(). The direct element constructor "<" goes to START_TAG 
with pushState(OPERATOR)

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

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

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

--Sarah

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

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

A.2.2 Lexical Rules

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

Specifically:

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

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

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

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

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

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

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

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

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

Query:   processing-instruction {x} {x}

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

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

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

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

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

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

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

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

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

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

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

-Michael Dyck

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

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

A.2.2 Lexical Rules

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

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

DEFAULT
    "]"
    ","
    "["

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

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

KINDTEST
    "@"
    StringLiteral

SCHEMACONTEXTSTEP
    "@"

START_TAG
    "{"

END_TAG
    "{"

-Michael Dyck

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

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

A.2.2 Lexical Rules

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

Specifically:

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

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

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

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

-Michael Dyck

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

I posted a comment to the XQuery WG last year that was moved to become a
last call. The mail is located at
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2003Oct/0046.html 

 

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

 

This mail proposes an improvement to the query prolog syntax to address
the ordering issues that several of my implementers have raised and that
I have reported previously. Currently the grammar allows a function
declaration before the default collation declaration, and a schema
import can syntactically occur after a function declaration that refers
to the type name imported. Since this arbitrary ordering complicates the
prolog processing and the specification of such, we would like to
propose a certain order in the prolog. We first have the version, then a
group of context setters, then a group of namespace declarations and
imports and then the variable and function declarations.
 
I propose two syntactic varieties that distinguish for variable and
function declarations and present the choice between two semantic
varieties for the variable reference case. Note that I assume that we
continue to allow a function declaration to refer to a function that is
syntactically declared later at the same module level.
 
Syntax A:
=========
 
Prolog ::= (Version Separator)?
           (Setter Separator)*
           (Decl Separator)*
           (VarDecl Separator)*
           (FunctionDecl Separator)*
 
Setter ::= XMLSpaceDecl     ; each setter occurs at most once
         | DefaultCollationDecl
         | BaseURIDecl
         | ValidationDecl
 
Decl   ::= NamespaceDecl    ; each decl appears any number of times
         | DefaultNamespaceDecl
         | SchemaImport
         | ModuleImport
 
Syntax B:
=========
 
Prolog ::= (Version Separator)?
           (Setter Separator)*
           (Decl Separator)*
           (VFDecl Separator)*
 
Setter ::= XMLSpaceDecl     ; each setter occurs at most once
         | DefaultCollationDecl
         | BaseURIDecl
         | ValidationDecl
 
Decl   ::= NamespaceDecl    ; each decl appears any number of times
         | DefaultNamespaceDecl
         | SchemaImport
         | ModuleImport
 
VFDecl ::= VarDecl | FunctionDecl
 
Semantic Interpretation I:
--------------------------
 
Example 1:
 
declare variable $a as xs:integer { $b + 42 } 
declare variable $b as xs:integer { 0 }
 
Example 2 (only for Syntax B):
 
declare function foo($x as xs:integer) as xs:integer {
  $x + $const
}
declare variable $const as xs:integer
 
Both examples work without error.
 
Semantic Interpretation II:
---------------------------
Neither of the two examples works. The declaration of $a in Example 1
would raise an error about not having $b declared yet, and the function
body in example 2 would raise an error that the $const has not been
declared yet.
 
Which would you prefer?
A.I., A.II., B.I., or B.II?
 
We have a slight preference of A over B and interpretation II over I,
but can live with the others.
 
Best regards
Michael

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

Section 3.1.1 Literals	
Technical	

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

				
Resolved, this is rejected.
			

Sections 2.6.6.1/2.6.7.1		
Technical	

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

Section 2.6.5/6		
Technical	

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

Sections 2.6.5/6	
Technical	

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

Sections 2.6.5/6		
Technical	

Provide static contexts for pragma/extension information

Section 2.6.3 Full Axis Feature	
Editorial	

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

Section 2.6.1 Schema Import Feature	
Editorial/Conformance	

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

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

Section 2.5. Error Handling	
Technical	

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

Section 2.4.2 Typed Value and String Value	
Technical	

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

Section 2.4.2 Typed Value and String Value	
Editorial/Technical	

Remove references to "namespace nodes" since they are not exposed in
XQuery.

				
Subsumed by qt-2004Feb0207-01
			

Section 2.4.1 Predefined Types
Technical

"xdt:untypedAny is .." See problem raised in MS-DM-LC2-038 (see
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0098.html
). xdt:untypedAny should only cover the untyped not and skip validated
cases.

				
Already resolved in prior meetings.
			

Section 2.2.5 Consistency Constraints	
Editorial/Technical	

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

XQuery currently lacks a mechanism to return metadata describing the 
persistent objects of interest to its users. While this capability could 
be added to each of the APIs that are designed for XQuery, we suggest that 
it would be better for XQuery to provide this metadata.

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



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

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


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

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

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

A user might issue the following query:

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

This query might return the following:

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


                                                        -- Andrew

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

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

Section 2.2.3.2 Dynamic Analysis Phase	
Editorial/Technical	

"If the Static Typing Feature is not in effect, an implementation is
allowed to raise type-related warnings during the static analysis phase,
but it must proceed with the dynamic evaluation phase despite these
warnings. In this case, type errors must be detected and raised during
the dynamic evaluation phase.": This is too strong. If I know for sure
that I always will have a dynamic type error (e.g., the expected type is
xs:string and the passed value is always an instance of xs:int, I should
be able to raise this type error during the static phase even if the
static typing feature is not employed).

Section 2.2.3.1 Static Analysis Phase	
Technical	

"During the static analysis phase, if the Static Typing Feature is in
effect and the static type assigned to an expression other than () is
empty, a static error is raised.": We also need to exempt fn:data(())
which is used by atomization since we atomize () in an expression such
as foo(()).

Section 2.1.1 Static Context	
Editorial	

How does module import affect the static context items?

Section 2 Basics	
Technical	

For XPath 1.0 backwards compatibility, the string value of a node should
be of type xdt:untypedAtomic.

Neither form of comment constructor gives any indication of what is to
happen if (after atomization/casting) the string contains the sequence "--"
or ends in "-" neither of which are allowed in an XML comment.

3.7.2 Other Direct Constructors
3.7.3.6 Computed Comment Constructors


<!-- abc -- xyz -->

comment { "-123-"}

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

By contrast, the xslt2 draft says,

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

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


David

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

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

				

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

I am having trouble understanding the meaning of the validation context
which may be specified in a validate expression (and equally, the
implicit validation context used when validating element constructors)

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

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

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

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

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

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

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

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

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

Michael Kay

On an internal list, I raised the following comment:

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

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

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

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

I suggest that this should say:

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

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

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

Michael Kay

On an internal list, I raised the following comment:

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

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

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

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

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

See Last Call issue reference qt-2003Dec0288-01

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

Michael Kay

Reading the working draft (W3C Working Draft 12 November 2003) and
testing some XQuery tools left the impression that the axis features are
sort of neglected by leaving features optional, which is not acceptable.

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

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

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

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

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

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

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

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

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

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

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

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

Thorsten

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

I asked this before, but even the latest drafts don't seem to have
a clear answer for whether there can be multiple library modules
with the same namespace.

Assume mod1.xql:

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

and mod2.xql:

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

Is the following main module allowed?

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

How about this?

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

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

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

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

I would like to enter this as a last call comment from DataDirect.

Jonathan


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

				
> I was rather surprised by this comment, but looking at the way the spec 
is
> written, I can see how you came to this conclusion. 

So you see the issue being that "or" is at the same level as FLWORExpr, 
some, every, TypeswitchExpr, and IfExpr "Precedence Order" table? 

> I'm pretty sure the
> intent was that
> 
> some x in y satisfies a or b
> 
> should parse as
> 
> some x in y satisfies (a or b)

Yep.  As extra enforcement to this fact, here is the diagnositic results 
from the test parser.

some $x in y satisfies a or b
|QueryList
|   Module
|      MainModule
|         Prolog
|         QueryBody
|            Expr
|               QuantifiedExpr
|                  Some some $
|                  VarName x
|                  In in
|                  PathExpr
|                     StepExpr
|                        NodeTest
|                           NameTest
|                              QName y
|                  Satisfies satisfies
|                  OrExpr or
|                     PathExpr
|                        StepExpr
|                           NodeTest
|                              NameTest
|                                 QName a
|                     PathExpr
|                        StepExpr
|                           NodeTest
|                              NameTest
|                                 QName b


Quiz time:

for $x in baz return $x or for $z in yada return $z

What does this expression do, in terms of parsing?

Answer: it is a syntax error.

for $x in baz return for $z in yada return $z or $x

What does this expression do, in terms of parsing?

Answer: it parses just fine.

This is a resolved issue, and I think is goodness, but is a little 
confusing when looking at precedence issues.

-scott
			

Proposal accepted.

				
[[accepted]]
			

SAG-XQ-004 Unordered

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

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

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

Michael Kay
for Software AG

SAG-XQ-003 Run-time access to static namespace context

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

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

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

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

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

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

(the latter also affects XPath)

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

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

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

Michael Kay
for Software AG

SAG-XQ-002 Input collection

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

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

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

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

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

Michael Kay
for Software AG

The semantics of computed namespace constructors is unclear:

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

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

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

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

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

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

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

I suggest a separate concept of "active namespaces" consisting of
anmespaces declared in namespace attributes and namespace constructors.
This could be part of the dynamic environment, but not the static
environment.
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

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

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

There do not appear to be any rules saying that line endings in XQuery text
are normalized.

This means that the query:

<a>
  gotcha!
</a>

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

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

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

Michael Kay
Software AG

In section 2.4.3, the XQuery language draft says:

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

and

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


But the error description for XP0008 reads:

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

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

Thanks,
Priscilla

What is the rationale for the full axis feature?

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

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

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


David

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

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

Kind regards,

-- Jan Hidders

Why are the union, intersect, and except operations limited to working 
on sequences of nodes? It seems to me that they are perfectly well 
defined operations for sequences of arbitrary types, and that these 
three operators should be declared to work on sequences of item type. If 
there's no good reason for limiting them to node()*, I would ask that 
the signatures of these operators be revised to item()* instead.

--
Elliotte Rusty Harold

Section 4.8 "Variable Declaration" of the XQuery November specification
says that:
   A variable may appear in the expression part of a variable declaration
   only if that variable is declared or imported earlier in the Prolog
   than the declaration in which it is used.
This is presumably to prevent indeterminacies and cycles.
However, section 4.7 "Module Import" says that:
   Two modules may import each other.

So is there anything to prohibit the following?

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

module namespace m2 = "M2";
import module namespace m1 = "M1";
declare variable $m2:v { $m1:v }
-- 
	--Per Bothner
per@bothner.com   http://per.bothner.com/

Consider the following query:

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

The output I expect is:

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

Saxon 7.8 emits:

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

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

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

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

It seems for every direct constructor there is a computed constructor 
-- except for CDATA sections. Since the WG has allowed CDATA direct 
constructors at all, there should be full support including computed 
constructors. I can understand if the CDATA sections were only to ease 
creating/viewing files that would otherwise require many entities, but 
since they also may be serialized by implementors it is limiting to not 
to have this functionality.

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

--Sarah

Hi Sarah,

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

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

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

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

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

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

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

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

We believe this improves our specification by making it more
consistent with the semantics of our data model, and thank you for
your input.
		
Please let us know if this response is satisfactory for you,

Jonathan

Jonathan,

This is quite satisfactory, thanks.

--Sarah

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

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

[minor editorial]

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

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

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

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

Thanks,

Liam

-- 
Liam Quin, W3C XML Activity Lead, http://www.w3.org/People/Quin/
http://www.holoweb.net/~liam/

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-017 Section B.2 Operator Mapping

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

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


  A - B xs:datetime xs:datetime               fn:subtract-dateTimes-yielding-dayTimeDuration(A, B) xdt:dayTimeDuration
  A - B xs:datetime xdt:yearMonthDuration     op:subtract-yearMonthDuration-from-dateTime(A, B) xs:dateTime
  A - B xs:datetime xdt:dayTimeDuration       op:subtract-dayTimeDuration-from-dateTime(A, B) xs:dateTime

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-013 Section 3.7.3.1 Computed Element Constructors

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

    1. For each node ...

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

Suggest adding the phrase:

    "by concatenating their contents, with no intervening blanks"

to be precise as bullet 4 in "3.7.1.3 Content".

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-012 Section 3.7.2 Other Direct Constructors

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

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

    A CDATA section constructor constructs a text node whose content is the
    sequence of characters placed between starting and ending delimiters of 
    the CDATA section constructor.

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-011 Section 3.7.1 Direct Element Constructors

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

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

and later

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

This contradiction could be remedied by modifying the first definition as
    
    One form of a direct element constructor is where the name, attributes, 
    and content are all constants in standard XML notation.

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-010 Section 3.5.3 Node comparison.

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

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

Seems better to use more usual and neutral "left and right operands" 
instead of "first and second" since the natural ordering while reading 
not always is "left-to-right".

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-009 Section 3.4 Arithmetic Expression

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

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

[2] http://lists.w3.org/Archives/Member/member-query-specs/2003Dec/att-0001/xpath-functions.html#func-numeric-divide

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-008 Section 3.2.2 Predicates.

A left-to-right order of applying of predicates is not specified but 
such order is implied by samples and other definition in the section. 
Explicit wording about order of applying of predicates would avoid 
misreading.

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

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

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

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

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

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

4.8 Variable Declaration
   "type error" in second paragraph isn't an anchor.

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-006 Section 2.4.4 SequenceType Matching

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

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-005 Section 2.4.4 SequenceType Matching

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

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

might be better stated as

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

instead of

       "derived by one or more steps of restriction or extension 
       from ET"

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

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

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

This description is not complete: it should also mention that the 
presence of "xsi:type" in the constructed element can also be used.  
Further, that "xsi:type" will take precedence over in-scope element 
declarations.

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-003 Section 3.7.3.2 Computed Attribute Constructors

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

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

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

Note that the term prefix is not used.

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

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

[2] http://www.w3.org/TR/2003/PR-xml-names11-20031105/#ns-decl

Dear Colleagues,

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

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

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

[1] http://www.w3.org/TR/2003/WD-xquery-20031112/

XSCH-QL-001 Section 2 Basics

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

It can be made more precise by saying something like:

  "All nodes have typed values and string values, some of which can be
  extracted from the node.  Some kinds of nodes also have names, 
  which can be extracted from the node.  For details on how these values
  are determined and on their availability for various node types
  please see section 2.4.2."

XQuery:  editorial


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

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

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

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

Best regards,
Dana

SECTION A.2.2: lexical rules

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


- Steve B.

Accepted.

				
We looked at Scott's modified text.
			

				
[[accepted]]
			

SECTION 2.1.1: Static context

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


- Steve B.

SECTION 3.7.1.4: whitespace in element content

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

- Steve B.

SECTION A.2.1: white space rules

Whereas:

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

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

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

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

- Steve B.

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

SECTION 2.6.2: static typing feature

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

- Steve B.

SECTION 2.6.2: static typing feature

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

- Steve B.

SECTION A.1.1: grammar notes

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

- Steve B.

SECTION A.2.1: white space rules

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

- Steve B.

We looked at Scott's modified text. 

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

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

Accepted.

				
We looked at Scott's modified text.
			

				
[[accepted]]
			

SECTION 3.7.3.1: computed element constructor

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

- Steve B.

SECTION A.1: EBNF

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



- Steve B.

				
See [435]
			

				

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

				
[[accepted]]
			

SECTION 3.7.1.4: whitespace in element content

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

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

- Steve B.

SECTION 3.7.1.2: namespace declaration attributes

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

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

- Steve B.

SECTION 3.7.1.1: Attributes

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


- Steve B.

SECTION 3.1.6: Comments

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

- Steve B.

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

SECTION 3: Expressions

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


- Steve B.

SECTION 2.6.6 : must-understand extensions

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


- Steve B.

SECTION 2.6.5: pragmas

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

- Steve B.

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

				

				
Proposals:
				
(1) amend the text up front to explain what the comments are
				
(2) put the comments only in the section that's already prefaced with
				
a comment that explains them.
				
ACTION A-SJ04-28 on Don and Scott to choose and implement one of these.
			

				
[[accepted]]
			

SECTION 2.4.4.3 : Matching an ElementTest and an Element Node

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

- Steve B.

SECTION 2.2.5 : Consistency constraints

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

- Steve B.

SECTION no specific location

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

- Steve B.

SECTION no specific locaton: none

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

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

- Steve B.

Appendices		
Editorial	

Some appendices seem to be explicitly marked as non-normative. Some that
are not marked should be marked so as well: E.g. the precedence table,
the glossary etc.

Appendix A.1 EBNF	
Editorial	

Is there a reason why "$" is outside of the production of VarName? We
can still use something like <"for" VarName> to indicate the necessary
token lookahead and define VarName as "$" QName.

				
RESOLUTION: closed, rejected.  See [450]
			

				

				
RESOLUTION: closed, rejected
			

				
[[rejected]]
			

Section 4.12 Function Declaration	
Editorial	

Non-normative [120]: Why is it (")" | (")" "as" SequenceType))  and not
")" ( "as" SequenceType)?

				
See [432], excerpt:
				
Because  the  long  token  has  to transit to lexical
state ITEMTYPE. Can he live with it?
   RESOLUTION: qt-2004Feb0797-01 closed with no action Microsoft can
live with not making the change.
			

				

				
RESOLUTION: qt-2004Feb0797-01 closed with no action Microsoft can live
				
with not making the change.
			

				
[[rejected]]
			

Section 4.10 xmlspace declaration	
Editorial/Technical	

"The xmlspace declaration in a Prolog controls whether boundary
whitespace is preserved by element and attribute constructors during
execution of the query" -> "The xmlspace declaration in a Prolog
controls whether boundary whitespace is preserved by element and
attribute constructors during parsing of the query"

Also: renaming this property to boundary space or xquery whitespace is
acceptable (see Oracle comment).

Section 4.8	Variable Declaration	
Editorial	

"All variable names declared in a library module must be explicitly
qualified by the namespace prefix of the module's target
namespace.[err:XQ0048] ": It should be the namespace URI and not prefix
that drives this.

Section 4.6	Schema Import	
Editorial	

The Note on static typing and DTD is a bit unmotivated. Why do we need
to say this here? We have not mentioned DTDs before. Please either
remove or make the context more relevant.

Section 4.5	Default Namespace Declaration	
Editorial	

"The effect of declaring a default function namespace is that all
functions in the default function namespace, including
implicitly-declared constructor functions, are aliased with a name that
has the original local name, but no namespace URI. ": This is a weird
way of explaining that the syntactic name resolver will add the
namespace URI given as the default if no prefix is specified. Please
reword this sentence.