Last Call Comments for xpath20.

Section 2.4.4.1 Matching a SequenceType and a Value	
Editorial	

Please replace "value" with "sequence of items".

			
            
Editorial. Not on our list. MK believes it done.
[Liam: done at Florida f2f, 2004-01-23
People note MikeK's text is correct, although redundant
if we adopt Rys'.
So, people approve MikeK's amendment.
And, Srinivas will reply to this public comment.
]
		
         

This comment was originally raised on an internal list just before the Last
Call drafts went out. I am re-raising it here so it can be managed as a
last-call comment.

 

Previously:
http://lists.w3.org/Archives/Member/w3c-xsl-query/2003Nov/0010.html

 

In the function calling rules, when we need to convert a string to a number
under the backwards compatibility rules, we use the number() function.
 
In arithmetic expressions, we also use the number() function (the rules are
defined by reference to the function calling rules).
 
In a general comparison, when we need to do such a conversion, we currently
use the casting rules.
 
The difference is that if the value being converted is say "fred", or "",
the number() function will convert it to NaN, while casting will throw an
error.
 
With XPath 1.0, the comparison ["fred"=3] returned false, because 3 was
converted to a string and compared not-equal to the string "fred". The
comparison ["fred">3] also returned false, because the string "fred" was
converted to the number NaN, and NaN>3 is false. Under the current XPath 2.0
rules, both these comparisons will cause an error.
 
Since this rule is only there for backwards compatibility, we seem to have
got it wrong. I think that for general comparisons, as with the other two
cases, the backwards compatibility behavior should use the number() function
rather than the casting rules.
 
Michael Kay

            
DUPLICATE of qt-2004Feb1011-01
         

SECTION 2.4.4: SequenceType Maching

The note statement
"In this specification, the word "type", when used without modification, represents a type that can be expressed using the SequenceType production. When we refer specifically to W3C XML Schema simple or complex types, appropriate modifiers are used to make this clear."

This is normative and should be moved to the beginning of the document.

Regards,
Mark Scardina
Oracle Corporation

SECTION 2.6: Optional Features

The spec defines "Static Typing Feature" as "XPath 2.0 defines an optional feature called the Static Typing Feature". There is no definition.

Regards,
Mark Scardina
Oracle Corporation

			
            
Done.
		
         

SECTION 2.2.3.2: Dynamic Evaluation Phase

The first sentence states 
"An implementation is free to use any strategy or algorithm whose result conforms to these specifications."

In the 2nd paragragh the statement "The dynamic evaluation phase can occur only if no errors were detected during the static analysis phase." implies that any static errors must cause the whole process to stop. 

Should the implementation processing models be restricted as long as the output is the same.

Regards,
Mark Scardina
Oracle Corporation

This comment builds on one aspect of David Carlisle's XSLT 2.0 comment

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0856.html

David reported:

<dc>

  Less-than and greater-than comparisons between strings have changed
since XPath 1.0

 <xsl:variable name="a" select="mn[1]/text()"/>
 <xsl:variable name="b" select="mn[2]/text()"/>
 <xsl:for-each select="$enum[@fname=$fpname]/v[$a &lt;= @f and @f &lt;=
$b]">

which is checking that three "numbers" obtained from the source files
satisfy a constraint that one lies between the other two.

Is it really necessary for this to break in BC mode?
Is it not possible for the mapping of &lt;= to the underlying F&O
operators is changed in BC mode to more closely match the behaviour in
1.0? While this is annoying it is actually less trouble to fix than the
previous error, especially in this case, where the node sets such as @f
in the expression really are only going to return one node  so I would
just need to add a couple of instances of number() (I hope:-) However if
tehre are cases where the implicit existential quantification are used,
it will be tricky for an end user to get right (easier for the system, I
would have thought).

</dc>


First, an observation which I have made before but which may have been
lost:

Section 3.5.2 currently says:

If XPath 1.0 compatibility mode is true, and at least one of the atomic
values has a numeric type, then both atomic values are cast to to the
type xs:double.

It should say:

If XPath 1.0 compatibility mode is true, and one of the atomic values
has a numeric type and the other does not, then the value that does not
have a numeric type is converted to a double using the fn:number
function.

(There are two changes here. Firstly, a value that is numeric is not
changed, so a decimal comparison remains a decimal comparison. Secondly,
the conversion is done using the number function rather than casting, so
that "abc"<3 gives false rather than an error.)

Second, a proposal to address David's concern about the compatibility
problem.

I suggest that in the case where both operands of <, >, <=, or >= are
untypedAtomic, we should in BCM replicate the 1.0 behavior, but with a
strong encouragement to implementors to issue a warning.

Specifically: change rule 2 of 3.5.2 as follows. (The rules also need to
be arranged so rule 2b takes precedence over the current rule 1):

2. If backwards compatibility mode is true, then:

  2a. If one of the atomic values has a numeric type, and the other does
not, then the value that does not have a numeric type is converted to a
double using the fn:number function.

  2b. If both of the atomic values have the type xdt:untypedAtomic, and
the operator is one of <, >, <=, or >=, then both of the atomic values
are converted to doubles using the fn:number function, and the processor
should output a warning indicating that the comparison would be
performed as a string comparison if backwards compatibility mode were
false. The format and destination of this warning is
implementation-defined. The warning may be output either during the
analysis phase or during the evaluation phase.

(Note: XPath 1.0 would attempt a numeric comparison even if one of the
arguments was a string. So there is still a backwards incompatibility.
However, it is far less likely to arise in practice.) 

I've made the warning a "should" rather than a "must" because there are
environments where there is no way of communicating with the stylesheet
author, and in any case we can't legislate against it being sent to
/dev/null.

Michael Kay

            

The XSL and XQuery working groups, meeting jointly, today looked at comments
concerning XPath backwards compatibility, including

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0298.html

from Martin Duerst, and the XPath-related parts of

http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0856.html

from David Carlisle.

The WGs agreed to accept a change proposal which removes most of the
incompatibilities listed in Appendix H.1: that is, it takes XPath 2.0
running in backwards compatibility mode much closer to XPath 1.0 (and by
implication, further from XPath 2.0 without BCM). If you have access to
member-only areas, the details are at:

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

The main effects of the change can be summarised as:

* comparing anything to a singleton boolean works by converting the other
operand to a boolean

* the comparisons <, <=, >, and >= involving sequences containing any
mixture of strings, untypedAtomic values, and numbers are done by converting
the items in both operands to xs:double

* all arithmetic is double arithmetic

The remaining incompatibilities that we are aware of are:

* the construct A < B < C is now a syntax error; it must be rewritten as (A
< B) < C to achieve the same effect as XPath 1.0.

* Certain strings such as "+INF", "1e5", and "+2" which converted to NaN in
XPath 1.0 now convert to values other than NaN. So for example ("+2" > "-2")
was false, and is now true.

The proposal did not address any residual incompatibilities in the function
library.

I trust that these changes are acceptable.

Michael Kay
for the XSL and XQuery WGs


	 
         

			
            
There is a revision of the proposal in:
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Sep/0079.html
[Andrew] What is the impact of this on XQuery?
[MichaelK] This has no impact, but goes into the joint document.
*** Proposal adopted.
The two corresponding comments qt-2004Feb0298-01 and qt-2004Feb1011-01
are closed.
		
         

Sections 2.5.2 and 2.5.3 of the XPath book talk about "dynamic errors",
but what they say is equally applicable to type errors raised during the
evaluation phase. The examples make this clear: consider "For example,
if a function parameter is never used in the body of the function, an
implementation may choose whether to evaluate the expression bound to
that parameter in a function call." For this example to be correct, the
section must apply to all run-time errors, not only to so-called
"dynamic errors".

(The problem arises because of poor choice of terminology. We tend to
imagine that all run-time errors are dynamic errors, but they are not.)

While we are on the subject, here is a request for clarification.

The expression concat("Title:", //title) raises a type error if the
document contains more than one <title> element. 

Section 2.5.3 says:

"an implementation is not required to search for data whose only
possible effect on the result would be to raise an error"

Assuming that section 2.5.3 applies to type errors as well as to dynamic
errors, does this mean that in the above expression, the implementation
can output the value of the first <title> element in the document, and
avoid searching for any others?

If so, we have reintroduced the first-item semantics of XPath 1.0 (and
the corresponding efficiency) by the back door, and we should make this
explicit, at least by including an example.

Michael Kay

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]

Section 2.2.3.2

The first paragraph following the definition of "the dynamic evaluation 
phase" states, "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."

However, in Formal Semantics Section 2.4.1, the second paragraph following 
the second numbered list states that "Dynamically typed implementations 
are required to find and report type errors during evaluation, but are 
permitted to report them during static analysis."

XPath explicitly prohibits dynamically typed implementations from raising 
type errors during static analysis, while Formal Semantics explicitly 
permits it.  The two specifications need to be made consistent.

Thanks,

Henry
[Speaking on behalf of reviewers from IBM.]
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

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

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 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 2.4.4.3: Matching an Element Test and an element Node

Item 2)b) says "type-matches(TypeName, AT) is true, where AT is 
the type of the given element node.  
However, if the given element node has the 
nilled property, then this rule is satisfied only if TypeName 
is followed by the keyword nillable."   

This paragraph is confusing.  I can come up with two different
interpretations of it. 
There are four cases to consider, in a two-by-two matrix.
One axis of the matrix is whether AT has xsi:nil='true' or not.
The other axis is whether nillable is specified or not.

One interpretation, which I think is the most literal, is to
regard the sentence beginning "However" as an additional 
requirement if At has xsi:nil='true'. That is, to pass the test, the element must satisfy type-matches (TypeName, AT), and, nillable
must be specified.  This produces the following 

AT has xsi:nil='true'     nillable specified         satisfied
AT has xsi:nil='true'     nillable not specified     not satisfied
AT lacks xsi:nil='true'   nillable specified         not satisfied
AT lacks xsi:nil='true'   nillable not specified     not satisfied

The other interpretation I would express using the following
language:

b. type-matches(TypeName, ATT) is true, where AT is obtained 
from the type AT of the given element node by overriding the 
nillability of AT as follows: ATT is nillable if and only if
the keyword nillable is specified. 

The two examples at the end of this section support the latter
interpretation.

- Steve B.

SECTION 2.5.1: Kinds of errors

Fourth para says "However, the fn:error() function must not be 
evaluated during the analysis phase."  What about
if (1 = 1) then fn:error() else fn:error()?  
Perhaps it would be better to say
"fn:error() function must not be evaluated during the analysis
phase, unless the analysis shows that it would inevitably be
evaluated during the evaluation phase."

- Steve B.

Section 3.12.5 Constructor Functions	
Technical	

We do not see a reason to disallow constructor functions for types that
are not associated with a targetnamespace and would like to have them
treated the same as any other constructor functions. Obviously, if the
default function namespace is set to the F&O namespace, you would not be
able to access them, but if I undeclare the default function namespace,
I should have access to them.

Section 3.12.5 Constructor Functions	
Technical	

Have the constructor functions accept () and return () on it. This makes
it more usable on expressions that may return an empty sequence in the
context of static typing such as xs:int(/a/b[1]/@c). Thus, change the
signature to: T($x as xdt:anyAtomicType?) as T?

			
            
MK believes this done, and confirms that the current (July) spec incorporates the change.
Done.
		
         

Section 3.12.5 Constructor Functions	
Technical	 

The signature should request an atomic value and then have the standard
function invocation semantics perform atomization. Thus, replace T($x as
item) as T with T($x as xdt:anyAtomicType) as T and fix the following
sentence.

			
            
MK believes this done, and confirms that the current (July) spec incorporates the change.
Done.
		
         

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.5.2 General Comparisons	
Technical	

Casting from untyped to numeric should be to double only if other type
is not decimal and do decimal otherwise. Reason: double compare is
non-precise.

Section 3.5.1 Value Comparisons	
Technical	

Do the same casting rule for untypedAtomic value as on general compare.
Having two different casting rules is confusing to the user. More so,
than the potential loss of transitivity (which is lost by implicit casts
anyway due to loss of precision).

Section 3.3.1 Constructing Sequences	
Technical	

We should not allow heterogeneous sequences of nodes and atomic values.
This adds lots of complexity and inefficiency with very little user
value.

Section 3.2.2 Predicates	
Technical	

The current dispatch rules for predicates is problematic since one often
has to defer to runtime whether an index or an effective Boolean value
is calculated, even if one does static type inferencing, and since
float/double imprecision can lead to unexpected/wrong results. 

Instead of doing position and fn:boolean() do the following for E[$x]:
 
if $x instance of xs:decimal=> do position as described (note no
float/double due to precision issues), 
if $x instance of node()* then fn:boolean($x), 
if instance of xs:boolean then $x, 
otherwise type error (may also add xs:string as an option).

XQuery: serious limitation


Casting is not permitted from xs:Qname to xs:string.
This is a very serious limitation. This implies that we
cannot create an attribute node whose value is of type
  Qname.

XQuery should allow this operation.

			
            
yes, RESOLVED and CLOSED by the approval of the serialization proposal
(the "triple proposal") in our previous meeting
(cf. http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Aug/0075.html)
		
         

XQuery: request for simplification and symmetry

Sequence type production is supposed to denote a
type. However, in case of processing instructions it
mentions the content of the PI.

The text mentions in a couple of places that a type represented
by a sequence type production helps filtering of items by their
type. This is clearly incorrect for  Pis since in this case it filters 
by content.

Two questions:
(a) what does this extra special case buys  to the language?
(b) how will this type/content be mapped to a Formal Semantics type ?

In the syntax, "$" VarName turns up in various places.
This should be replaced by a non-terminal, e.g. VarRef,
which would be defined as:

    VarRef ::= "$" VarName

Also, the syntax seems to allow a space after the $, but
none of the examples have a space after the $. The above
rule would allow to forbid whitespace with a /* ws: explicit */.
There seems to be no need to allow whitespace after the $,
it will only confuse users.

Regards,   Martin.

			
            
duplicate of issue 646 (rejected at meeting 191)
		
         

			
            
CLOSED (as dup, cf. w3c-query-editors/2004Aug/02138 ),
Scott will reply to this comment in the public.
		
         

The handling of errors in cases such as 'and', 'or', 'some',...
is really dangerous, because it is highly unpredictable, not only
between different implementations but also in a single implementation.

I'm pretty sure that the speed advantages can be obtained with other
methods that don't introduce that much unpredictability.


Regards,    Martin.

2.2.5 says: "Enforcement of these consistency Constraints is
beyond the scope of this specification."

Who/what enforces these constraints? In case they are not enforced,
what are they there for?

Regards,    Martin.

Dear XML Query WG and XSL WG,

Below please find the I18N WGs comments on your last call document
"XML Path Language (XPath) 2.0"
(http://www.w3.org/TR/2003/WD-xpath20-20031112/).

Please note the following:
- These comments have not yet been approved by the I18N WG. Please
   treat them as personal comments (unless and) until they are approved
   by the I18N WG.
- Please address all replies to there comments to the I18N IG mailing
   list (w3c-i18n-ig@w3.org), not just to me.
- The comments are numbered in square brackets [nn].
- Because XQuery in big parts is identical to XPath, many of these
   comments also apply to XQuery. We are confident that you can
   figure this out yourselves.


[1] URIs: Throughout this and other specs, URIs have to be changed
   to IRIs.

[2] Current date and time: It should be made explicit that this has to
     include a timezone.

[3] Implicit time zone: This has to be removed. Using implicit conversions
     between timezoned and non-timezoned dates and times is way too prone
     to all kinds of subtle and not so subtle bugs.

[4] 2.2.3.1 operation tree normalization: There are many different
     normalizations in this series of specifications. These should be
     clearly and carefully separated.

[5] 3.1.1: The Note says that the characters used to delimit the literal
     must be different from the characters that are used to delimit the
     attribute. This is not strictly true, " or so can also be used.

[6] 3.1.5: conversion rules: to what extent can strings, elements
     with string content, and elements allowing mixed content but
     actually only containing a string be mixed? This is important
     for some I18N applications.

[7] 3.2.1.2: How to test for an element that only contains text
     (independent of type)? This is important for some I18N applications.

[8] 3.5.1: What about elements that have more elaborate types (e.g. mixed),
     but that still don't contain anything more than a string?
     This is important for some I18N applications.

[9] 3.10.2: How to cast between complex types?

[10] References: The reference to ISO/IEC 10646 should be updated to
      the newest version.


Regards,    Martin.

The less namespaces, the easier to use. For example,
I don't see any need to have the xdt namespace; these
few types, if they are needed, should be added to XML
Schema, and to that namespace.


Regards,   Martin.

[Speaking on behalf of reviewers from IBM, not just personally.]

Section 2.1.2

The definition of the "Current date and time" component states, "If 
invoked multiple times during the execution of a query or transformation, 
[fn:current-date, fn:current-time, and fn:current-dateTime ] always return 
the same result."

XPath should only impose this requirement for a single expression.  It is 
up to the host language to impose this sort of requirement across multiple 
expressions (like a transformation in XSLT).

In addition, section C.2 indicates that the scope of "Current date and 
time" is "global", which "indicates that the value of the component 
remains constant throughout the XPath expression."  That contradicts the 
statement quoted in 2.1.2.  2.1.2 should be changed to be consistent with 
C.2

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

[Speaking on behalf of reviewers from IBM, not just personally.]

Section 2.1.1

The definition of Statically known collections states, "If the argument to 
fn:collection is not a string literal that is present in statically-known 
collections, then the static type of fn:collection is node()?."  The 
static type in this case should be "node()*" rather than "node()?".

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

Section 2

The second paragraph of this section mentions that a function cannot have 
the same name as certain keywords.

Could there be additional reserved function names in the future?  If so, a 
caveat would be appropriate here.  Also, it should be made clear that 
there is never any danger of conflict of QNames that specify runtime data. 
 In other words, only user functions (or perhaps host language functions) 
are in danger of conflict.

Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

See [449]  RESOLUTION:  use  the  word  "invoked" in the first sentence of A.3
to make  clear  why  there  can  be a conflict. Add note about
additional keywords.  Users  should  not have unprefixed invocations of
functions with  these  names, and if they want to protect themselves from
future changes they should use the prefixed form, or put a distinctive
string in their function names. ACTION: Don to fix.

				
            

				
            
e.g. you can't define don:element() and make "don" your default
				
            
prefix, and then call element()
				
            
RESOLUTION: use the word "invoked" in the first sentence of A.3 to
				
            
make clear why there can be a conflict. Add note about additional
				
            
keywords. Users should not have unprefixed invocations of functions
				
            
with these names, and if they want to protect themselves from future
				
            
changes they should use the prefixed form, or put a distinctive string
				
            
in their function names. ACTION A-SJ04-31: Don to fix.
			
         

Section 1

The first sentence of this section states, "The primary purpose of XPath 
is to address the nodes of [XML 1.0] trees."

This should defer to Data Model on what levels of XML are supported. 
Otherwise, it should include XML 1.1 in some way.


Thanks,

Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

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

A.2.2 Lexical Rules

This section should be deleted, or at least made non-normative.

I have made this point several times before:
http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0002.html
http://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0021.html
http://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0105.html
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0407.html
I've received a few replies, but never a satisfactory justification.
This time, I'll presumably at least get an official WG response.

Here's a summary of my objections to this section:

(1) It's error-prone.

(2) It's poorly defined.

    There's only a vague description of the automaton. There's no
    definition of:
    --- its possible configurations;
    --- how its configuration is changed by each different kind of
        transition;
    --- what its initial and accepting configurations are.

    Moreover, there's no description of how the automaton ascertains
    which pattern (of the currently legal patterns) matches the current
    input. (Note that most automata don't have to deal with this,
    because their "pattern" vocabulary is the same as their input
    vocabulary.)

(3) It favours a particular implementation strategy, making conformance
    more difficult for anyone choosing to use a different strategy.

All of which could be improved or excused if it were actually necessary,
but:

(4) It isn't necessary. It's redundant, given the rest of Appendix A.
    Or, if it actually *does* express a requirement not expressed
    elsewhere, then either it's a mistake, or it *should* be expressed
    explicitly elsewhere. And if you don't understand the implications
    of A.2.2 enough to *know* whether it expresses unique requirements,
    then that lack of knowledge alone should tell you that you can't
    risk making it normative.

-Michael Dyck

			
            
> a) qt-2004Feb0348-01 [XQuery] A.2.2 Lexical Rules: remove
> From:Michael Dyck
> Date:2004-02-14
>
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0348.html
>
> ACTION A-CHINOOK-07: Scott will give a solution to this
>> b) qt-2004Feb0348-01 [XQuery] A.2.2 Lexical Rules: remove
>
>http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0348.html
> DONE. See:
> http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Sep/0113.html
>
> Status: Meeting 211 discussed this item.  If there is no objection by
> email this proposal will be automatically adopted.  The comments
> resolved are list in:
> http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Sep/0113.html
ADOPTED.
ISSUES RESOLVED qt-2004Feb0348-01, qt-2004Jan0396-01.
Scott to reply to the commenters.
		
         

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

Here is a comment from
http://lists.w3.org/Archives/Public/public-qt-comments/2002Jul/0008.html
and
http://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0090.html
that did not receive a response from the WG.

------

Are these queries legal?
     10div 3
     10 div3
     10div3
According to the current spec, I think they're all legal (and mean the
same as '10 div 3').

Re the space between '10' and 'div':
I can't find anything that would require it (with the possible exception
of A.2.1's hopelessly vague paragraph about separating "words", and only
then if you consider "10" a word).

Re the space between 'div' and '3':
I imagine you would claim that A.2's "longest match" rule implies that
when the lexer sees 'div3', it should prefer the 4-character QName over
the 3-character keyword. But that rule selects "the longest possible
match that is valid in the current lexical state", and a QName is not
valid in the OPERATOR state, according to
http://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0363.html

-Michael Dyck

			
            
Covered (accepted) by the solution to qt-2004Feb0853-01 (adopted
at teleconference 193).
		
         

			
            
RESOLVED, CLOSED (moot), this had been already done
		
         

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

Here are some comments from
http://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0002.html
that did not receive a response from the WG.

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

[3] ExprComment

    This seems like a poor name for the symbol, given that it's not a
    kind of expression. (In fact, CompXmlComment would seem to have more
    of a claim to the name, since it actually is a kind of expression.)
    Why not just "Comment"?

    By the way, why did you drop single-line comments (# to line-end)?

    What is the grammatical/lexical effect of a comment? E.g., is
        foo(: comment :)bar
    equivalent to
        foobar
    or
        foo bar
    ?
    (And is the effect the same for Pragmas and MUExtensions?)

--------

[9] DoubleLiteral

    Change ("e" | "E") to [eE]
    Change ("+" | "-") to [+-]

[23] HexDigits

    Change
        ([0-9] | [a-f] | [A-F])
    to
        [0-9a-fA-F]

--------

3.7.1 Direct Element Constructors

"a pair of identical curly brace characters within the content of an
element or attribute are interpreted by XQuery as a single curly brace
character"
[And similarly in A.2.2 ELEMENT_CONTENT.]
    An alternative would be to use character references (e.g., {
    and }).

-Michael Dyck

1) Adapt rename ExprComment to Comment 2) Defer "Does comment act as whitespace?" to whitespace issues.

Approved first third of the email. 
Rest is deferred: it needs to be broken up, creating new separate issues
for this. Scott will do it.

W3C XSL WG Technical Comment on XPath 2.0 Last Call Draft

Comment on 2.4.2:

Referenc to F&O should be added for the fn:data and fn:string
functions. The sentences referring to dm:typed-value and
dm:string-value should be removed.

			
            
Done.
		
         

W3C XSL WG Technical Comment on XPath 2.0 Last Call Draft

Comment on 2.4.1:

XPath claims that the types are from W3C Schema, BUT says, in item 1.,
that some are subtypes of xdt:anyAtomicType (which is NOT in
W3C Schema). If it uses "subtype" as being different from
"derived from" subtype needs to be defined and it pointed out that
"subtype"d things need not be "derived from" in W3C Schema.
Figure 2 needs to say that the lines are "subtype" relationships
and not "derived from" lines.

Also it needs to say:

- For types not in the xdt:-namespace subtype means derived by restriction
  for simple types and derived by restriction or extension for complex
  types.

- For types in xdt:namespace it is as defined by F&O/FS/or the language
  docs.

It needs to be verified that "derived" is only used in the W3C Schema
sense.

The caption for the figure should be changed to be speaking about
"subtype relationships" rather than "type hierarchy" to stress that
it is different from W3C Schema.

			
            
Discussed, and finally
APPROVED (and CLOSED) by accepting Don's proposal:
In all of 2.4.1, substitute "subtype" with "derived from".
Don't change the labels in the diagram
(cf. http://lists.w3.org/Archives/Member/w3c-xsl-query/2004Aug/0094.html )
		
         

W3C XSL WG Technical Comment on XPath 2.0 Last Call Draft

Comment on 2.2.4, 2nd paragraph:

The phrase "based on this framework." needs to be removed.
It can easily be read to say that all host languages provide
serialization and just some are based on this framework.

W3C XSL WG Technical Comment on XPath 2.0 Last Call Draft

Comment on 2.2.3.2, 1st paragraph:

The text is not a definition of "dynamic evaluation phase";
it says WHEN it occurs, not WHAT it is...

			
            
 Substitute this with
 "The dynamic evaluation phase is the phase during which the value of the
 expression is computed."
		
         

I'm quite frightened by the long list of incompatibilities
(even despite a special compatibility switch) between XPath 1.0
and XPath 2.0. Each of these items seems to be small, but overall,
this has a large potential for confusion, subtle errors, and so on.
Not a big problem for a spec, but a potential nightmare for deployment.

My guess is that to avoid this, implementations will probably
implement both XPath 1.0 and XPath 2.0. If that's the case,
it would be easier to make the compatibility switch switch
all features, rather than just part of them. Bringing
XPath 1.0 and 2.0 closer together would be even better.


Regards,   Martin.

			
            
There is a revision of the proposal in:
http://lists.w3.org/Archives/Member/w3c-xml-query-wg/2004Sep/0079.html
[Andrew] What is the impact of this on XQuery?
[MichaelK] This has no impact, but goes into the joint document.
*** Proposal adopted.
The two corresponding comments qt-2004Feb0298-01 and qt-2004Feb1011-01
are closed.
		
         

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

3.8.1. For and Let Clauses

"A for clause may also contain multiple variables, each with an
associated expression. In this case, the for clause iterates each
variable over the items that result from evaluating its expression.
The resulting tuple stream contains one tuple for each combination of
values in the Cartesian product of the sequences resulting from
evaluating the given expressions."

The second sentence only makes sense if the expressions are independent.

Consider a case where they are not:
  for $x in (10,20),
      $y in ($x + 1, $x + 2)
  return 2 * $y

In the two For clauses, the first expression yields (10,20),
and the second expression yields (11,12) and (21,22) in turn.
So "the sequences resulting from evaluating the given expressions"
are (10,20), (11,12), and (21,22). Their Cartesian product is
this set of combinations:
    [10,11,21]
    [10,11,22]
    [10,12,21]
    [10,12,22]
    [20,11,21]
    [20,11,22]
    [20,12,21]
    [20,12,22]
which is not at all what you intended.  Of course, this is a willful
misinterpretation. My claim is that, when the expressions are not
independent, it is the only interpretation available.  Presumably,
the intent is that [$x,$y] take on the values:
    [10,11]
    [10,12]
    [20,21]
    [20,22]
but this is not a Cartesian product.

I made much the same comment almost three years ago in:
http://lists.w3.org/Archives/Public/www-xml-query-comments/2001Apr/0009.html

(Personally, I think the whole "tuple stream" model of explaining
FLWOR expressions is an unnecessary complication, but I doubt that
I could convince you to abandon it.)

----

3.11 Quantified Expressions

This section has a similar sentence involving the term "Cartesian
product", which is similarly flawed.

-Michael Dyck

(IBM-XQ-014) Appendix A: The definitions of QName and NCName contain 
references to Namespaces 1.0. These should be replaced by a statement that 
it is implementation-defined whether QName and NCName are defined by 
Namespaces 1.0 or by Namespaces 1.1.

--Don Chamberlin

(IBM-XQ-007) Section 3.2 (Path Expressions): The definition of a path 
expression should be revised to remove the restriction that the expression 
on the right side of "/" must return a sequence of nodes. The restriction 
should be retained for the expression on the left side of "/". In effect, 
this would permit the last step in a path to return one or more atomic 
values. This feature has recently been requested by Sarah Wilkin (
http://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0100.html) 
who proposes the following rule: When evaluating E1/E2, if each evaluation 
of E2 returns a sequence of nodes, they are combined in document order, 
removing duplicates; if each evaluation of E2 returns a sequence of atomic 
values, the sequences are concatenated in the order generated; otherwise a 
type error is raised. Like all type errors, this error can be raised 
either statically or dynamically, depending on the implementation. This 
rule provides well-defined static and dynamic semantics for path 
expressions.

To illustrate the usability advantages of this proposal, consider a 
document containing "employee" elements, each of which has child elements 
"dept", "salary", and "bonus". To find the largest total pay (salary + 
bonus) of all the employees in the Toy department, here is what I think 
many users will write:

max( //employee[dept = "Toy"]/(salary + bonus) )

Unfortunately in our current language this is an error because the final 
step in the path does not return a sequence of nodes. The user is forced 
to write the following:

max( for $e in //employee[dept = "Toy"] return ($e/salary + $e/bonus) )

This expression is complex and error-prone (users will forget the 
parentheses or will forget to use the bound variables inside the return 
clause). There is no reason why this query cannot be expressed in a more 
straightforward way. Users will try to write it as a path expression and 
will not understand why it fails.

Another very common example is the use of data() to extract the typed 
value from the last step in a path, as in this case: 
//book[isbn="1234567"]/price/data().  This very reasonable expression is 
also an error and the user is forced to write 
data(//book[isbn="1234567"]/price).

Note that I am NOT asking for a general-purpose mapping operator, which I 
think is not in general needed since we already have a for-expression. 
Instead, I think we should simply relax the unnatural and unnecessary 
restriction that is currently placed on path expressions. This will remove 
a frequent source of errors and will improve the usefulness of path 
expressions, without precluding us from introducing a general-purpose 
mapping operator later if a consensus emerges to do so.

--Don Chamberlin

			
            
> ACTION A-CHINOOK-05 on DonC to start a thread by providing
>  a detailed proposal solving qt-2004Feb0214-01 and qt-2004Feb0074-01 RE:
[Don] This is a long standing issue. It relates to the rules for
processing
the '/' operator in a path expression. It currently requires the right
hand
side to return a sequence of nodes. The proposal is to relax that rule to
allow the last step to return atomic values. I also posted some usecases
for
this.
[Andrew] MichaelK has posted a correction that the error should be a type
error.
[Don] This is correct and Michael Rys agreed.
*** Proposal accepted, with M