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:
https://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
https://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
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0298.html
from Martin Duerst, and the XPath-related parts of
https://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:
https://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:
https://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
"https://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
   'https://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. https://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"
(https://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:
https://lists.w3.org/Archives/Public/www-xml-query-comments/2002Jan/0002.html
https://lists.w3.org/Archives/Public/public-qt-comments/2002Aug/0021.html
https://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0105.html
https://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
>
https://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
>
>https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0348.html
> DONE. See:
> https://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:
> https://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
https://lists.w3.org/Archives/Public/public-qt-comments/2002Jul/0008.html
and
https://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
https://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
https://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. https://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:
https://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:
https://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 (
https://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 Michael Kay's correction.
This item is closed. This closes two comments: qt-2004Feb0214-01 and qt-2004Feb0074-01.
Don will respond to the public comments.
		
         

(IBM-XQ-004) In the XQuery document, there should be no reference to 
"namespace nodes". Since XQuery does not support the namespace axis, there 
is no way for an expression to return a namespace node. All references to 
namespace nodes should be replaced by references to the "in-scope 
namespaces" of an element, a term that is already widely used in both the 
Data Model and the Functions and Operators documents. Nodes are needed 
only to preserve identity and to represent a position on an axis. Since 
namespace-prefix-bindings in XQuery have neither identity nor position, 
there is no need in XQuery for the concept of a "namespace node". See 
IBM-DM-031 for a related Data Model comment, but note that this proposal 
can be adopted independently of IBM-DM-031 (
https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0207.html)
--Don Chamberlin

IBM-DM-031: No need for namespace nodes
(related: IBM-DM-021 (Feb0027-01) [preserving namespace prefixes)
Don: element nodes are all of the concept that we need.
PaulC: there are lot of specs that currently reference namespace
nodes currently...
Sharon: this impacts XSLT a lot
Jonathan: I'd like the xquery language to never mention
namespace nodes, and to make them deprecated.
Don: element nodes have a property called inscope namespaces
If you'd like to have those namespace nodes, then you can
take those things and make them namespaces nodes.
So, we can make namespace access a deprecated feature of XPath2.0.
PaulC: concerned about other people on the table that think these
are not deprecated (they might not use the *access*, but the
data model). 
Sharon: any decision we take here, I please ask this to be
contingent to the decision of the full XSL wg, as this impacts
XSL a lot.
Norm: sympathetic, but this doesn't seem to help the DM, as we'll
need them anyway in the DM (the output of the namespace accessors).
Don: my major concern is not to have the namespace nodes mentioned
in the XQuery language book. I could live with this, and keeping
the namespace nodes in the DM if really needed.
PaulC: So, DM can maintain those nodes for those people who need to use them.
Don: change property of elementnodes: the accessor should not return a set
of namespace nodes, which is not helpful; instead, the language doc
needs the inscope namespaces. 
A property like "namespace prefix binding".
Karun: eg, F&O currently doesn't make references to the namespace
nodes, but uses broader terms.
***
* ACTION A-MAND-04
* on Norm
* to expose the concept of namespace accessors in a formal way in the DM
***
***
* ACTION A-MAND-05
* on Don
* to build a proposal on how to get rid of the wording "namespace node" in the
* XQuery document (coordinating with Norm)
***
Note MikeK should be anyway consulted on this whole issue (A-MAND-04/A-MAND-05)

(IBM-XQ-003) At present, our documents are inconsistent in their use of 
the term "in-scope namespaces". In the XPath and XQuery documents, 
"in-scope namespaces" is part of the Static Context and is a property of 
an expression. On the other hand, in the Data Model and Functions and 
Operators documents, "in-scope namespaces" is a property of an element and 
has another meaning entirely. The term "in-scope namespaces" appears 13 
times in the Data Model document and 10 times in F&O document. I think we 
should fix this inconsistency by changing the term "in-scope namespaces" 
in the Static Context to "declared namespaces" and using this term 
throughout the XQuery and XPath documents. The term "declared namespaces" 
suggests where the information comes from: either a namespace declaration 
in the Prolog, or a namespace declaration attribute. In this solution, no 
changes are needed to the Data Model and F&O documents.
--Don Chamberlin

			
            
(Unnumbered): Clearly distinguish the following concepts in the
language documents: "statically known namespaces" (a static property
of an expression, found in the static context), vs. "in-scope
namespaces" (a dynamic property of an element node).
This change resolves comments/2004Feb/0210.  Fixed throughout, using defined
terms "in-scope namespaces" and "statically-known namespaces"
This DISCHARGES the Unnumbered action.  [...]
AGREED to change to use "variable declarations" and "function
declarations" for the static side.
AGREED to keep 'in-scope' for schema definitions, "statically known" for
document and collection.
ACTION A-SJ04-24: Language Doc editor to change "In-scope variables"
to "Variable declarations", "In-scope functions" to "Function
declarations", "In-scope collations" to "Statically known collations",
"Dynamic variables" to "Variable values" and "Function ..." to "Function
implementations".
		
         

(IBM-DM-031) The Data Model document lists namespace nodes as one of the 
seven kinds of node. But a node is needed only to preserve identity and to 
represent a position on an axis. The identity of a namespace node is never 
used, and the namespace axis is deprecated in XPath 2.0 and not supported 
in XQuery. Neither XPath nor XQuery provides a way to construct a 
namespace node independently of an element node. Therefore there is no 
reason to retain the concept of a namespace node in XPath 2.0. It should 
be replaced by the concept of "in-scope namespaces" as a property of an 
element node. The term "in-scope namespaces" is already widely used (13 
times in the Data Model document and 10 times in the Functions and 
Operators document). We should make "in-scope namespaces" one of the 
properties of an element node, supported by two accessors 
(get-namespace-uri-for-prefix() and get-in-scope-prefixes(), which are 
already documented in Functions and Operators). We should leave it up to 
the implementation how to support these accessors. Various strategies are 
possible, including storing all the in-scope prefixes in each element 
node, or only storing the "new" prefixes that are introduced by each node 
(different from its parent). 
Replacing namespace nodes with the existing concept of "in-scope 
namespaces" will shorten and simplify the Data Model document, removing 
various accessors on namespace nodes which XQuery does not provide any way 
to invoke. Implementations that choose to support the (deprecated) 
namespace axis can synthesize "namespace nodes" from the "in-scope 
namespaces" property of an element node. Implementations that do not 
support this deprecated axis need not be aware of namespace nodes at all. 
All references to "namespace nodes" in XPath and XQuery-related documents 
(such as the Serialization document) can be rephrased in terms of the more 
abstract concept of "in-scope namespaces" for an element; this provides 
greater implementation flexibility and in many cases simplifies the 
documents.
--Don Chamberlin

			
            
    (A-MAND-05): Revise the XQuery document to remove all references to "namespace nodes", using instead the term "in-scope namespaces", a property of an element node. The concept of namespace nodes (and the deprecated namespace axis) remain in the XPath document but are optional for host languages. These changes resolve comments/2004Feb/0207. The following parts of the XQuery document are affected by this item:
    2. (Basics) Last paragraph and note.
    3.7.1.2 (Namespace Declaration Attributes)
    3.7.3.1 (Computed Element Constructors), local namespace declarations
    3.7.4 (In-scope Namespaces of Constructed Elements)
    Corresponding changes to the Data Model document (defining "in-scope namespaces" as a property of an element node) are still pending (Norm's action item A-MAND-04).
Done.
		
         

In XQuery, "2.4.4 SequenceType Matching" says:
    In this case, an implementation is allowed (but is not
    required) to provide an implementation-dependent
    mechanism for determining whether the unknown
    type is compatible with the expected type".
This should be implementation-defined. An implementation
should document whether it provides such a mechanism, and the
mechanism it uses (generally, to rely on information in the
PSVI).
Jonathan

			
            
RESOLVED (CLOSED/MOOT) by the current document.
		
         

Looking at appendix F of the XPath language book:
Errors XP0001 and XP0002 between them do not cover all cases, because
evaluation of an expression may depend on a value in the static context
(e.g. the base URI).
Error XP0008 includes XP0017 as a subset (and XP0017 starts "It is It
is")
XP0002 includes XP0018 as a subset
XP0007 would appear to belong in F+O
XP0006 includes XP0019 as a subset
XP0055 applies to attribute tests as well as to element tests
Using the namespace axis with a processor that doesn't support it raises
error XP0021, but this is described in appendix F as an casting error.
The error text for XP0019 says that it's an error if the result of a
step expression is not a sequence of nodes. But 17 and "london" are both
step expressions. The context where this error is introduced (in 3.2)
makes it clear that it's referring to both operands of the "/" operator.
But it's not clear why this isn't just a generic type error (XP0006).
There seem to be a number of errors that don't have codes allocated:
- target type of a cast is not atomic
- violation of the consistency constraints in section 2.2.5
- no entry in operator table for the actual types of the operands
There seem to be cases where more specialized error codes would be
useful:
- "unknown types" in sequence type matching (2.4.4) should not give the
same error as an incorrect but known type
The description of casting in the XPath book duplicates the description
of casting in F+O. The two descriptions allocate different error codes
to the same error conditions. Which text is normative?
The distinction between the two casting errors XP0021 and XP0029 isn't
clear. Reading the descriptions in the appendix and the descriptions in
the body of the document gives different impressions as to the
difference between the two cases. In any event, it seems odd to have two
different codes for these two subtly-different cases when other error
codes are much less specialized. 
Note also typo in 3.2.1.1:
"XPath defines a set of full set of axes"
Michael Kay

The following sentence occurs at the end of section H.2:
<quote>
It is not the case that these differences will always result in XPath
2.0 raising an error. In some cases, XPath 2.0 will return different
results for the same expression. For example, the expression "4" <
"4.0". This returns false in XPath 1.0, and true in XPath 2.0.
</quote>
I believe this statement is true of the incompatibilities listed in
section H.1 (with backwards compatibility mode on) but is not true of
the incompatibilities listed in section H.2 (further incompatiblities
when BCM=off). The incompatibilities in section H.2 will always result
in XPath 2.0 raising a type error for constructs that succeeded in XPath
1.0.
Also, the example given relates to one of the incompatibilities listed
in H.1.
I think the sentence should simply be moved from H.2 to H.1.
Michael Kay

			
            
RESOLVED (and CLOSED): ACCEPTED, MikeK will take care of this.
		
         

Hi,
  I suggest to extend Primary expressions in XPath 2.0 to allow a subset
of the an+b expression as defined in
  https://www.w3.org/TR/css3-selectors/#nth-child-pseudo
for simplified grouping. It is basically possible to express the same
functionality using count(...), the following-/preceding-sibling axes
and the mod operator but this is typically rather unconvenient and hard
to understand for beginners. It should for example be possible to use
  tr[2n]
to select all even tr children of the context node.
regards.

			
            
done at meeting 166:
ACCEPTED, Don to make the change and reply to the public comment.
		
         

The current rules for backwards compatibility in general comparisons
reads:
<old>
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.
</old>
[Note also the typo: "to to"]
This means that if both the values are xs:decimal values, they must both
be converted to xs:double values for comparison. This seems
unreasonable, given that two xs:decimal values can be unequal when
compared as decimals, but equal when converted to doubles. 
Since it's entirely OK to compare two numeric values of different atomic
type, there doesn't seem to be a good reason for converting both
operands to double, rather than only converting one; nor is there a good
reason for converting to xs:double if the value is already numeric. I
suggest changing the rule to:
<new>
If XPath 1.0 compatibility mode is true, and if one of the atomic values
has a numeric type and the other does not, then the value that is not
numeric is cast to the type xs:double.
</new>
Michael Kay

			
            
CLOSED (as DUPLICATE of qt-2004Feb1011-01)
		
         

In Section 3.1.5, the function conversion rules in XPath 1.0 Compatibility
Mode don't cover the number() function itself, which expects
xdt:anyAtomicType?. If you pass number() a sequence of multiple values, in
XPath 1.0 Compatibility Mode, you would want only the first value to be
used.  Perhaps another bullet point should added to the list, saying:
If the expected type is xdt:anyAtomicType or xdt:anyAtomicType?, then the
given value V is effectively replaced by V[1].
 
Thanks,
Priscilla Walmsley

				
            

				
            
Some question: is anyAtomicType covered by item()? A: yes, in the
				
            
sense that if item() is expected, then atomics are accepted.
				
            
MH proposes change: under xpath 1.0 compatibioity mode, insert a prior
				
            
rule: if the expected type is singleton or optional, and V is a
				
            
sequence, take V[1]. Then apply existing rules (n.b. rule 3 becomes
				
            
irrelevant and rules 1 and 2 can lose their subscript -- details left
				
            
to Don).
				
            
ACTION A-SJ04-44: Don to make these chagnes
				
            
ACTION A-SJ04-45: Jonathan to update issues list marking issue ... as
				
            
accepted.
				
            
ACTION A-SJ04-46: Don C to reply to Priscilla.
			
         

In Section 3.1.5, it says:
"2. If the expected type is a numeric type, then the given value V is
effectively replaced by fn:number(V[1])."
This should apply only when it is expecting up to one numeric value.  If it
is expecting a sequence of (possibly several) numeric values, you wouldn't
want it to use just the first one.  
For example, the expected type of the codepoints-to-string argument is
xs:integer*. codepoints-to-string( (97, 98, 99) ) should return "abc", not
just "a", regardless of XPath 1.0 compatibility mode.
I realize that codepoints-to-string is not part of XPath 1.0, but it still
seems that you wouldn't want its behavior to change because of XPath 1.0
compatibility mode. 
Thanks,
Priscilla Walmsley

				
            

				
            
Discussoin of what Priscilla is worried about. We notice a difference
				
            
in wording between the language document adn f/o: the language
				
            
document talks about "a numeric type" while f and o talks about float
				
            
and double.
				
            
Priscilla's quetion, however, is answered differently: integer* does
				
            
not get treated as she fears, because xs:integer* is not "a numeric
				
            
type" within the meaning of bullet item 2 of the compatibility-mode
				
            
rule.
				
            
ACTION A-SJ04-42: AM to reply to PW.
				
            
ACTION A-SJ04-43: am to make F and O rules compatible with language book.
			
         

3.2 Path Expressions
"Each evaluation of E2 must result in a (possibly empty) sequences of 
nodes; otherwise a type error is raised. [err:XP0019]"
We feel XQuery is limited by its focus on nodes. The evaluation of E2 
should be able to contain nodes or atomic values.
The main purpose of this is to allow for a function at the end of a 
path. Generally this saves writing a loop. For example:
let $root := <b><a>   foo  bar</a><a>baz     faz</a></b>
return $root/a/normalize-space(.)
instead of
let $root := <b><a>   foo  bar</a><a>baz     faz</a></b>
let $seq := $root/a
let $result := for $item in $seq
	return normalize-space($item)
return $result
In addition, without this functionality ugly workarounds are required 
to obtain the value of context functions. For example:
("a", "b", "c" )/text{ position() }
instead of the straightforward:
("a", "b", "c" )/position()
--Sarah

			
            
> 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 Michael Kay's correction.
This item is closed. This closes two comments: qt-2004Feb0214-01 and qt-2004Feb0074-01.
Don will respond to the public comments.
		
         

It is worth noting that the serialization process depends on the ability 
to cast a QName into a string (for example, when it is found in the value 
of an attribute such as xsi:type="xs:decimal"). Casting a QName into a 
string is currently not defined in the Functions and Operators document. 
This inconsistency between documents should be fixed.
--Don Chamberlin

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

Hi
The tables are _not_ a declarative way to specify behaviour. They are
a highly imperative imposition of a solution that then has to be disclaimed
except in so far as it still has to be observed.
The declarative approach is to specify that the preceding BNF when
interpreted
at a lexical level maximising the length of tokens such as QName and then
in the conventional LALR(1) shift-reduce fashion has exactly one
shift-reduce
conflict on a leading "/" that is to be resolved as per
grammar-note:leading-lone-slash.
All other <> grouping annotations and lexical tables should be a
non-normative
guide that may be of assistance to those pursuing an LL approach.
	Regards
			
		Ed Willink
------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@iee.org
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          https://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------

Scott: inclined to keep the tables but putting them in non-normative
section; and do the other appropriate modifications (eg as normative
grammar notes, or constraints on the grammar).
MaryH: yes, please don't force my implementation to behave in a specific
way, do it in a neutral grammar.
Don: however, we have this way an existence proof that the language is
parseable
PaulC: but, that's code, why should it be normative?
Anybody wants to remove the tables? [none]
So, options are either to stick with status quo (normative),
or keep them but non-normative (Accept the comment).
This still stays pending, we'll try to solve the other grammar issues
first.

			
            
editorial, so CLOSED, and Scott will reply
as per w3c-query-editors/2004Aug/02138
		
         

			
            
> a) qt-2004Feb0348-01 [XQuery] A.2.2 Lexical Rules: remove
> From:Michael Dyck
> Date:2004-02-14
>
https://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
>
>https://lists.w3.org/Archives/Public/public-qt-comments/2004Feb/0348.html
> DONE. See:
> https://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:
> https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Sep/0113.html
		
         

Kindly reconsider to amend production [54] to allow for an
optional else clause.
[54]   IfExpr   ::=   <"if" "("> Expr ")" "then" ExprSingle ("else"
ExprSingle)?
with nested if-then-else tied through parentheses as
suggested below
https://lists.w3.org/Archives/Public/www-ql/2004JanMar/0017.html

			
            
No action required. This change was rejected in Cannes-Mandelieu.
		
         

The OCCURRENCEINDICATOR State contains: input_stream.backup(1), which is 
undocumented.
(Formal comment for a known (since a few days after release of the draft) 
bug.  The input_stream.backup(1) action has to back the lexer up by one 
character in the OCCURRENCEINDICATOR state for anything that is not an 
occurance indicator, so that other operators besides "+" and "*" can be 
recognized as operators.  Another option for this is to reproduce all 
operator transitions in the OCCURRENCEINDICATOR state.)
-scott

			
            
duplicate of Feb662-01 (accepted at the San Jose' F2F)
		
         

			
            
Scott thinks he has solved this. So:
RESOLVED, and CLOSED, unless people come back to this in the
next two days.
		
         

Section 3.2 Path Expressions	
Technical	
fn:root(self::node()) treat as document-node() is not precise enough for
meaningful static typing of path expressions of the form /a/b/c. We
should use a type that is given via the static context as a new property
such as the static type of a built-in context root item (similar to the
notion of a context item).

				
            

				
            
Should we force recommend to implementations to always infer the given
				
            
type in treat as? 10 yes. 1 no (DF: it will kill a lot of
				
            
optimizations.)
				
            
In favor: 7.
				
            
Opposed: 0.
				
            
Carries.
				
            
ACTION A-SJ04-39: Don C to make appropriate change to language document.
				
            
This provides the loophole necessary to deal with the normalization of
				
            
slash, and thus CLOSES this issue.
				
            
ACTION: mr to respond publicly to this issue (once he gets the text).
				
            
ACTION A-SJ04-40: Don C to respond publicly to this issue.
			
         

Section 3.1.6 XQuery Comments	
Editorial/Technical	
The grammar production rule: 
[3]    ExprComment    ::=    ""(:"" (ExprCommentContent | ExprComment)*
"":)"" 
to denote the comment nesting is strange. Since ExprCommentContent
already allows (: and :) you never get to the nested ExprComment. Please
use 
[3]    ExprComment    ::=    ""(:"" ExprCommentContent* "":)"" 
Noting in text that nesting is ok should suffice.

Visibility of nested comments are necessary to do nesting counting.
Closed: 
Scott will add a note on how to do the matchup (a footnote called
nested comment, explaining how they are done).

Section 3.1.5 Function Calls	
Technical	
>From a usability point of view, we should also define promotion rules
between xs:string and xs:anyURI and viceversa. This would allow us to
pass a value of either type to a function such as fn:doc().

Section 2.4.4.3 & 2.4.4.4 & 3.2.1.2		
Technical	
Users expect that the sequence type expression element(name) means
element(name,*). Please redefine element(name) to be the same as
element(name,*) and introduce a special syntax for ISSD lookup and
substitution group inclusion. An example would be to use / in the schema
context path such as element(/name)

				
            

				
            
Pending discussion of schema context paths in 27 April meeting.
				
            
(Or was this decided yesterday?)
				
            
Has been accepted.
				
            
ACTION A-SJ04-38: MR to respond saying accepted.
			
         

				
            
Pending discussion of schema context paths in 27 April meeting.
(Or was this decided yesterday?)
Has been accepted.
ACTION A-SJ04-38: MR to respond saying accepted.
			
         

Sections 2.4.3 & 2.4.4.3 & 3.2.1.2 
Editorial	
"element(po:shipto, po:address) refers to an element that has the name
po:shipto (or is in the substitution group of that element), and has the
type annotation po:address (or a subtype of that type)": We assume that
this will be fixed to not include substitution groups.

Section 2.4.3 SequenceType Syntax	
Technical	
Schema context overhead is too large for the benefit to be able to refer
to elements of anonymous types in instance of/function signatures. We
recommend to cut this feature from XQuery 1.0/XPath 2.0.

			
            
Done: schema context is long gone. (Was this a dup?)
		
         

Section 2.3.4 Input Sources	
Technical	
fn:collection should be dropped or made optional since it has only
limited use in certain implementation contexts that understand the
notion of a collection.

			
            
[XQuery] MS-XQ-LC1-025
RESOLVED:  Close with no action.
		
         

Section 2.3.2 Atomization	
Technical	
fn:data() on mixed complex content statically needs to always raise a
type error since an instance could be of a non-mixed complex content
derived from the static type. Are we ok with a static error? Or should
we allow atomization on all complex content.
See also comment MS-DM-LC2-055
(https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0125.htm
l)

				
            

				
            
MR: resolved by decision in Mandelieu to make type value of mixed
				
            
content an error.
			
         

			
            
The atomization of a mixed content element in a static typing implementation
will raise a static error, so Michael Rys is satisfied that the comment
can remain closed.
		
         

Some members of NCITS H2, including IBM, are planning to propose the 
embedding of XQuery expressions within SQL statements in the next version 
of SQL/XML. This feature is made possible by the addition of an XML data 
type in SQL/XML:2003. In adding this feature, errors in the evaluation of 
an XQuery expression will need to be reflected in SQLSTATE values, which 
have the following description:
The character string value returned in an SQLSTATE parameter comprises a 
2-character class value followed by a 3-character subclass value, each 
with an implementation-defined character set that has a one-octet 
character encoding form and is restricted to <digit>s and <simple Latin 
upper case letter>s.
We suggest a small number of changes to XQuery to more easily support the 
reflection of XQuery errors in SQL. We believe that these changes will be 
helpful in the embedding of XQuery within other environments as well.
1. Ensure that the local part of QNames that are defined in XQuery use 
only 5 characters
Add a statement such as the following:
2.5.x Identifying Errors
The errors that are defined by this specification (indicated by "an error 
is raised: [...]") will use QNames with local parts that have the form 
XXYYY, where XX is one of "XP" or "XQ" and YYY consists of exactly 3 
characters that are digits.
2. Change the existing error QNames
Replace XP0xxx with XPxxx and XQ0xxx with XQxxx.
3. Define the "err:" namespace prefix
Choose a namespace URI that does not change from one version of XQuery to 
another.
4. Disallow error values that are the empty sequence
The evaluation of fn:error() and fn:error($arg), where $arg is the empty 
sequence, should have the effect of raising err:XQnnn (specific value to 
be assigned by the XQuery editors). This error would be defined as 
follows:
        XQnnn
        Unspecified dynamic error.
 
5. Make error values more regular
The fn:error function accepts an argument of type item()?. We suggest that 
all errors should be identified by QNames, possibly with an associated 
non-QName value. The means by which the non-QName value is provided to a 
host environment is implementation-dependent.
Specifically, when $arg is a value with a type other than xs:QName, then 
the evaluation of fn:error should have the effect of raising err:XQmmm. 
This error would be defined as follows:
        XQmmm 
        Unspecified dynamic error with non-QName value.
6. More clearly identify errors that are defined by implementations and 
users
We suggest that all errors reported to a host environment be defined in 
this specification. Errors raised by an implementation or a user with 
QName values would be identified by a standard error with an associated 
QName value. The means by which the QName value is provided to a host 
environment is implementation-dependent.
Specifically, when $arg is a value with type xs:QName, but it is not a 
QName defined by this specification, then the evaluation of fn:error 
should have the effect of raising err:XQrrr. This error would be defined 
as follows: 
        XQrrr 
        Implementation-defined or user-defined error.
7. Change the error QNames defined in F&O
Replace all of the QNames in Annex D, Error Summary (Non-Normative), with 
QNames of the form err:XFxxx.
8. Make the error QNames Normative in F&O
Change the title of Annex D from " Error Summary (Non-Normative)" to just 
" Error Summary".
Add the following sentence to the beginning of this annex:
        The error text provided with these errors is non-normative.
8. Define error QNames in Serialization
Serialization states in numerous places, starting with Section 2, 
Serializing Arbitrary Data Models, bullet 2, "It is a serialization error 
if ..."
Like XQuery and F&O, QNames should be associated with these errors. These 
QNames should have the form err:XSxxx.
                                                        -- Andrew
--------------------
Andrew Eisenberg
IBM
5 Technology Park Drive
Westford, MA  01886
andrew.eisenberg@us.ibm.com
Phone: 978-399-5158    Fax: 978-399-5117

			
            
6. qt-2004Jan0091-01: [XQuery]  IBM-XQ-001 - changes to error QNames
> We suggest a small number of changes to XQuery to more easily support
> the reflection of XQuery errors in SQL. We believe that these changes
> will be helpful in the embedding of XQuery within other environments
> as well.
This was the IBM comment that lead to the proposal that we accepted.
		
         

			
            
d) [XQuery] IBM-XQ-001 - changes to error QNames, Don c
https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0091.html
[AndrewE made a presentation on this]
XQuery WG decided to change the language book to say that QNames for
errors are not normative, following F&O. Originally this was because
there was English text describing the errors, and because of
internationalization concern.  The question of whether the codes
themselves are normative is undecided, but as Mike Kay pointed out,
they are not testable within our spec, so possibly should not be
normative.
JimMelton noted that XQ had already adopted 8-character local parts.
The err: prefix is a stylesheet error and Norm has already said he
will fix it.  It should be (said Jim) xdt:
PaulCotton: Michael said the errors should be in no namespace.
Mike Kay: I was under the impression that namespaces were there
only for user-defined namespaces
Norm: I think we couldn't decide and said we'd come back to it.
Jim: it's orthogonal to this proposal.
Jim: Andrew's argument stems from what I consider to be a very
reasonable source -- that an important use of XQ is likely to be
in conjunction with SQL.  Unfortunately I disagree that we should
make the XQ error space have the same space as the SQL error space.
I think another approach would be better for SQL as well as for us.
SQL has specifically set aside a range of error codes for SQL use
and a range for implementors.  The latter range includes all
errors starting with X, so we can't use it.
PaulC: the SQL standard also has a mechanism to get a message text,
Andrew: we're thinking that if XQ had XQxxx, we'd use a lower range,
such as AAxxx.
PaulC: why can't you return the existing XQ error codes in the
diagnostic area message text field, instead of doing a mapping
in SQL?
Jim: I think Andrew is trying to make XQ a first class citizen in SQL,
but another approach might be to define a mapping between each of the
XQ error codes and the appropriate subclass codes in SQL.
I'd like to see the QNames of these error codes [in XQ] be normative.
I belive there willbe more interfaces than just SQL.  I'd prefer not
to make all the others suffer simply because a desire to make it
trivial for SQL.
Liam: decouple specs, I'd prefer xq-xml-query-... i.e.
include the W3C shortnames in the qname.
Mike Kay: I hate short names too.  They're things from the 1970s.
XSLT uses 6 characters now, and it'd be an enormous pain to cut it
down to five, and I wouldn't want to change it because stability in
them is important.
On the motivation, I'm very wary of trying to run 2 sets of unique
values owned by distinct authorities into the same value space.
The implication that we don't have freedom to use the other half
of the value space in our next draft is abhorrent.
MichaelR: if we go with the qname, I think the qname should be not
human-readable because it's just an identifier.  But I'm worried
about making them normative, because some APIs might expose errors
just as qnames.  In SQL we don't have qnames, so a [SQL] mapping
table is appropriate,  We should keep the existing 8 character
naming and have SQL/XML define a mapping, and the APIs also
define a mapping, exposing it as a qname or just a string value.
It'd be better not to use the prefixes on error codes, because
prefixes aren't supposed to be significant, do people have to
use the URI to look them up?
on (4) in the proposal, I think it's OK, but a bit vacuous.
on (5) I'd like to restrict the fn:error() argument to something
less than item, but not allow more than one argument.  I'd like a URI,
so people can get more resources about the error.
on (6) I think if we have a qname or a URI, ths is possible, but
there's not a big difference between host and user defined functions.
on (7) this should be done at an API level.  We need to be explicit
that the error text is not normative.
So we should make clear that our error codes are not normative from
a testing point of view, but we should tell implementors to provide
a mapping to these codes.
JonathanR: Andrew is proposing that we change our errors so they map
clearly to SQL.  straw poll, how many people feel that's something
we should do? I.e. adopt part 1
adopt part1: 3 [all from IBM]
not adopt: 6
abstains: 4
IBM can live with 8-character codes.
Resolved: we have already decided 8-character error codes, with
a specified breakdown.
***
* ACTION A-TAMPA-26
* on Jim Melton
* to find the email summarising the 8-char error codes
* (cf. error qnames issue, https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0091.html )
* and send it to the WG list.  Include a proposal for prefixes (XP,
* XQ or whatever) if the decision didn't include one.
***
(Don will then need to change the query book)
[much more discussion followed]
		
         

The ability to deal with null values (that translate into the XML data 
model
very often as empty sequences as result of path expressions) is a clear
necessity for most real world applications.
Unfortunately in the current specification the value predicates (e.g. 
eq, lt, gt)
raise dynamic errors when one of their arguments is an empty sequence 
and this
poses significant problems while querying data with null values.
In order to solve this problem the value comparisons should simply 
return the empty
sequence when one  of their arguments is an empty sequences.
Please remark that the other form of comparisons (the general 
comparsion "=" and its
family) do deal properly with the empty sequence, but have other 
properties that make
them unsuitable for processing large volumes of data (e.g. they are non 
transitive).
Thanks for your attention, best regards,
Dana Florescu

			
            
c) [XQuery] value comparisons and empty sequences, Dana F
https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0088.html
Status: Both WGs have adopted a solution to this problem.  We simply
need to assign responsibility for providing a description in response to
this comment.
Resolution: this change (3rd paragraph) has already been adopted.
***
* ACTION A-TAMPA-25
* on Michael Rys
* to respond to the public comment on value comparisons and empty sequences
* (cf. https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0088.html)
***
		
         

Hi.  This is a comment on the last call XQuery WD.
The subject was previously discussed on public-qt-comments, but due to
an oversight on my part, wasn't concluded.  That discussion can be
found here;
https://lists.w3.org/Archives/Public/public-qt-comments/2003Oct/0096.html
Mark.
-- 
Mark Baker.   Ottawa, Ontario, CANADA.        https://www.markbaker.ca

			
            
b) XQuery and URIs, Mark B
https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0031.html
(reading "query" instead of "document" in the comment)
Mike Kay: A URI quoting scheme for queries is already defined.  You can
use escape-uri or see the RFC 2396 for how to encode a query in a URI.
***
* ACTION A-TAMPA-24:
* on Liam
* to respond to the public comment on "XQuery and URIs"
* (cf. https://lists.w3.org/Archives/Public/public-qt-comments/2004Jan/0031.html )
***
		
         

I think there is probably a need, in both XSLT 2.0 and XQuery 1.0, to place
constraints on the use of xs:redefine in imported schemas.
The specifications generally assume that schema components are identified
uniquely by their expanded QName. However, if one query module imports
schema1.xsd, and another query module imports schema2.xsd, and schema1.xsd
redefines schema2.xsd, then the two query modules are using different
definitions of the same named types. This means that when a node is
annotated with a QName, we don't know whether it was validated against the
original type or the redefined type.
There don't appear to be any existing rules that cover this.
In XSLT 2.0, I think it's reasonably easy to fix, because (a) the set of
imported types is the same in all stylesheet modules, and (b) we define the
semantics of xsl:import-schema in terms of importing a single composite
schema, which means that the redefined definitions are used throughout. The
only problem that arises is when source documents arrive that have been
validated against an "unredefined" version of the schema; these may carry
type annotations that are inconistent with the redefined types. This is
essentially the same problem as occurs when different versions of a schema
are used in xsl:import-schema and in source document validation, and we can
disallow it under the same provision.
In XQuery 1.0 it's a little more difficult, because each query module has
its own static context, but it can still be done under the rule that all
versions of a single type definition must be consistent. This amounts to
saying (a) it's not allowed for one module to import schema1.xsd and for
another module to import a schema that redefines schema1.xsd, and (b) the
implementation must (?) detect when this happens. But is this restriction
acceptable?
Michael Kay

			
            
This issue is confirmed as closed.
		
         

I'm submitting this as a last-call comment because I keep hearing discontent
about it, mainly from the XSLT user community. There have been many informal
discussions on this in the XSL WG, with a fair amount of sentiment in
favour, but I think it needs to go on the formal joint XPath agenda for a
decision one way or the other. 
This is a personal rather than a Software AG comment.
I believe that there is a clear need for a simple mapping operator in XPath
2.0. I will use the symbol "!" to represent this operator. The semantics are
that:
E1 ! E2 evaluates E2 for each item in E1, and returns the concatenation of
the results, retaining order. E2 is evaluated with the context item set to
the relevant item in the result of evaluating E1.
For example:
  string-join(*!name(), ",")
returns a list of names of the child elements of the context node
  sum(item!(@price*@qty))
returns the sum of price*quantity over all items
  (1 to 10)!(.*2)
returns the numbers 2,4,6,...
  $emps!@date-of-birth
returns the dates of birth of the employees in $emps, retaining the original
sequence order.  
Why is this needed?
Basically because the "for" expression is too heavyweight for the task. The
"for" expression introduces range variables, which are only really needed
when doing joins, and joins in XPath expressions are actually extremely
unusual. The vast majority of "for" expressions actually used in XPath are
not nested. By requiring users to use "for" expressions as the only mapping
construct in the language, (a) they are forced to use a syntax that is
unlike the rest of XPath, and (b) they have to switch idioms to use
variables, instead of using the context item in the way that comes naturally
- which is a very common source of errors.
There has been some sentiment that a simple mapping operator would remove
the need for "for" expressions in XPath entirely. I'm not arguing for that
here (I think there is some merit in XPath being relationally complete). But
for a language so heavily based on sequences, I think the simple mapping
operator is really needed.
Michael Kay

			
            
done at the Redmond f2f:
RESOLVED and CLOSED (REJECTED). See qt-2003Dec0061-01.
		
         

The attached ps file contains an example of an XML document and an
information need which uses an "until" like path (that is, a descendant
path such that all nodes on the path  have a certain attribute-value
true  at them).
I could prove that this query is not expressible in Core XPath (the
"logical core of XPath 1.0" defined by Gottlob et al). 
It is unclear to me if I can express it in XPath 2.0. 
Any help welcome.
Maarten Marx
-- 
***************************************************************************
Maarten Marx 	    marx@science.uva.nl     https://www.science.uva.nl/~marx
 Language and Inference Technology Group, ILLC, Universiteit van  Amsterdam
        Nieuwe Achtergracht 166, 1018 WV  Amsterdam, The Netherlands. 
      Phone: +31 20 525 2888 Mobile: 06 400 16 120 Fax: +31 20 525  2800
***************************************************************************

			
            
> f) 2003Nov/0302 DM expressing until-like queries in XPath 2.0
> https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0302.html
>
> Example in PDF is attached to:
> https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0312.html
>
> David Carlisle's answer:
> https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0309.html
> Summary: I think we only need to get confirmation from the commenter
> that they are happy.
[there is now a reply at message 0313]
JonathanR, MikeK: this isn't a request to change the language; it's an
assertion that some queries require recursion, and can't be done
just in XPath.
***
* ACTION A-TAMPA-21
* on Mike Kay
* to respond to te public comment
* https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0313.html
* saying thank you for the response,
* and to explain it's an 80/20 decision.
***
		
         

XQuery 1.0: An XML Query Language 
states (section 4.12: Function Declaration):
"In XQuery 1.0, user-declared functions may not be overloaded. 
A user-declared function is uniquely identified by its expanded QName. 
...
Note:
If a future version of XQuery supports overloading of user-declared functions, 
an ambiguity may arise between a function that takes a node as parameter and
a function with the same name that takes an atomic value as parameter (since a
function call automatically extracts the atomic value of a node when necessary). "
Would it be possible to relax this rule and allow for function overloading based 
on the arity of the function parameters? (in other words, allow for ns:fn(a), ns:fn(a,b),
ns:fn(a,b,c)). Such an approach would not lead to ambiguities, as a function
would be uniquely identified by its expanded QName and the number of its 
arguments. At the same time some of the flexibility provided by overloading 
would remain at the hands of the users.
Cheers,
Panagiotis

				
            

				
            
The request is to do the easy part of overloading now, based on
				
            
arity. KK In XSLT this is allowed.
				
            
AE: what's driving this? KK Action TAMPA-19 DF to write a proposal for
				
            
arity-based.
				
            
Open, pending completion of Tampa 19.
				
            
Later revisited; various people's notes say this was decided on, and
				
            
the onus is now on the editors. It's in Don's work list, no action
				
            
number needed.
			
         

The XQuery language draft says:
"Each operation E1/E2 is evaluated as follows: Expression E1 is evaluated,
and if the result is not a sequence of nodes, a type error is
raised.[err:XP0019]"
Shouldn't E1 be allowed to be the empty sequence?  Can it be reworded "...if
the result is not a (possibly empty) sequence of nodes..."
Thanks,
Priscilla

			
            
done at the Redmond f2f:
RESOLVED (CLOSED as MOOT): this has been already taken care of in the Jul draft.
		
         

I would like to make a proposal to change the rules affecting the focus when
evaluating a path expression in the form E1/E2. Specifically, I propose that
when evaluating E2, the context position and context size should both be set
to 1 (one), not to the position of the context node in the list of nodes
selected by E1 and the size of this list.
There are very few expressions that will be affected by this difference.
Because E2 must return a sequence of nodes, you need to find an expression
that uses position() or last() but still returns nodes. It's not enough to
use position() or last() within a predicate, because a predicate changes the
context. You need to find expressions such as
  a/b/remove($c, position())
or
  a/b/subsequence($c, position())
or 
  a/b/(for $i in 1 to last() return $c[$i])
I have not found any expression in this category that is actually useful, or
that cannot be written in a more natural way.
But why change the rules? The reason is that the current rule makes the "/"
operator non-associative. The result of (a/b)/remove($c, position()) is not
the same as a/(b/remove($c, position()). Rewriting a/b/c as a/(b/c) can be
an important rewrite for optimizers as it often reduces the need to perform
a sort.
To be fair, I should point out that
(a) it's not difficult to detect path expressions that use position() or
last() on the right hand side of "/", and
(b) there are other situations that can make "/" non-associative:
specifically, when one of the operands creates new nodes with distinct
identity by means of a function call (or in XQuery, a node constructor) 
However, I think it's not reasonable to ask implementations to do a lot of
extra work for the sake of constructs that will only ever be found in
conformance tests. The rule that position() and last() should both be set to
1 is just as good as the present rule from a user perspective (there are
plently of cases in XSLT where these values are always set to 1 already,
e.g. when evaluating keys) and a lot easier from an implementor's
perspective.
There are no backwards compatibility implications, because XPath 1.0
restricted the rhs of "/" to be a step, which could not contain calls on
position() or last() except in a predicate.
Michael Kay

			
            
The request was for position() and last() to be undefined (or illegal)
on the right of "/"
Don pointed out that all our XPath operators are defined independently
of each other, and this would change that.
MK pointed out that / and [] set position() and last() in 2.0 (in 1.0
there was no way to use these functions to the right of /)
Dana pointed out that there are other things that destroy associativity
of the / operator; MK felt that node construction was another.
Karun: if the compiler is smart enough to re-order, it's smart enough
to test for the use of position() and last().
Scott: it's another special case rule users have to remember.
MKay: I'm hearing a lack of support for this proposal
Resolution: We'd prefer to keep the status quo so that / and predicates
have the same behaviour
***
* ACTION A-TAMPA-18
* on Jonathan Robie
* to reply to the public comment
* https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0223.html
* ([XPath] Focus for evaluating E1/E2)
***
		
         

			
            
RESOLVED as this was already CLOSED in the San Jose' f2f (A-TAMPA-18)
		
         

I have a question about the interaction between the PSVI and XPath 2.0.
If I understand things correctly, a schema-aware XSLT processor is supposed
to respect the PSVI annotations on the original XML tree.  Leaving aside
questions as to how those annotations are to be transmitted, I think this
will prevent a serious performance hurdle to XSLT transformers, especially
highly optimizing transformers.
Let's use an example stylesheet with only one template:
	<xsl:template match="top">
		<xsl:value-of select="a+b"/>
	</xsl:template>
Now, assume that it is fed this input doc.  I'm using xsi:type attributes
to indicate the PSVI typing information, though of course it could have
come from a schema or some other source:
	<top>
		<a xsi:type="xs:integer">22</a>
		<b xsi:type="xs:integer">44</b>
	</top>
I would assume the output of this execution is '66'.  On the other hand,
if we fed it this input document:
	<top>
		<!-- Note: I can't remember the syntax for schema dates
		and durations off the top of my head, so forgive my informal
		notation here -->
		<a xsi:type="xs:gDate">Mar 20, 2003</a>
		<b xsi:type="xs:duration">1 month</b>
	</top>
Am I correct that we would expect the output to be "Apr 20, 2003" (or
something similar, I forget the details of duration+date addition)?
If so, that's a real drag.  It used to be possible to determine statically
the types of almost every expression in a stylesheet.  The only exception
were parameters, where it was possible to pass parameters of two different
types to a single template.
For a highly optimizing XSLT engine, that allowed you to avoid the overhead
of dynamic typing in places where it wasn't needed.  In my experience, this
can be a very big deal.
I understand that the committee is committed to schema typing in XSLT 2.0.
I would suggest, however, that it not be the default behavior, but that the
user specifically request that PSVI annotations be respected.  At a minimum,
you could have an attribute that specifically stated that PSVI annotations
be disregarded, which would allow the engine to optimize more aggressively.
I know that the working group has gone to great pains to ensure that all
expressions behave naturally when no typing information is available, but
I'm not sure that you've considered the ramifications to performance of
making schema annotations enabled by default.
Thanks,
Niko Matsakis
DataPower Technology

				
            
RESOLUTION: Rejected, closed. ACTION A-SJ04-35: Mary Holstage to respond.
			
         

Dear Niko,
This is a response to the following message, which you posted to the XML
Query Working Group's comments list:
        https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0053.html
The XML Query Working Group considered your comment and decided to make no
change.
First note that the data model defines mappings both from the PSVI and
from the vanilla Infoset, and given that the PSVI is an extension of
the Infoset, an implementation is perfectly free to provide only the
Infoset mapping. An implementation of XSLT is further free to provide
provide facilities for handling documents as if there were no schema
information available.  So the part of your comments regarding
allowing PSVI annotation to be disregarded is already an option
available to implementors.
With respect to dynamic versus static dispatch of operators such as
"+", you don't need to bring date-time types into play to run into the
issue. Since there is more than one numeric type, dynamic dispatch
will still be necessary, given that integer addition and floating
point addition are not the same.  Type polymorphism requires late
binding even for numeric types. The WG is not prepared to abandon
polymorphism for arithmetic operators for different numeric types, nor
to abandon those different numeric types.
We appreciate your feedback on the XML Query specifications. Please
let us know if this response is satisfactory. If not, please respond
to this message, explaining your concerns.
Mary Holstege

| I would add one remark that's specific to XSLT, which is that we are
| indeed adding a construct to the language to allow users to specify
| that a stylesheet should treat the source document as untyped,
| effectively discarding any type annotations that are present.
I am glad to hear that; in general, while it is good that the option to 
ignore schema information is available to implementors, I think it is 
far superior to include a standard way to specify most things users 
will commonly want to do.  Otherwise, each implementor is forced to add 
their own specific knob and cross-compatibility becomes a huge pain.
The node-set function in XSLT 1.0 is a good example: each product had 
their own node-set function, and as a result you see stylesheets with 
many different versions, each specific to a particular vendor.
Anyway, I appreciate the replies.
Niko

				
            

				
            
RESOLUTION: Rejected, closed. ACTION A-SJ04-35: Mary Holstage to respond.
			
         

				
            
[[rejected]]
			
         

			
            
> b) 2003Nov/0053 [XSLT2.0] PSVI, XPath and optimization
> https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0053.html
> Michael Kay's reply:
> https://lists.w3.org/Archives/Public/public-qt-comments/2003Nov/0058.html
(discussion of static typing; the commentator's example has an input
document that uses xs:type on instances)
(xsi:type in the absence of validation is just an attribute)
Resolution: XSL WG to discuss the building of the data model and PSVI
annotations in the original input document with Niko, and also to
consider schema-awareness declarations or flags, and to respond.
[later in the same meeting...]
MikeK gives a presentation on "Simplifying Durations".
DataPower public comment (XSLT) in public-qt-comments/2003Nov/0053
People note making + less overloaded doesn't quite solve the
associativity problem (eg, for floats).
Dana: core that is as simple as possible, and then allow libraries to
extend this
Rys: people/vendors can define their own extension functions for this,
so I am in favour of MikeK's proposal.
Straw poll:
people in favour of MikeK's proposal: 5
people not in favour of MikeK's proposal: 6
abstain: 5
So, we go to the "status quo prevail" line:
can live with status quo: 12
can't live with status quo: 1
abstain: 3
So, resolved, status quo prevails.
		
         

Hello,
  I am feeling the need of a built-in function, any()
in XSLT..
please look, at the following e.g.
<xsl:for-each select="x-path">
  <xsl:if test="./@a='1' = any()/@='1'">
  </xsl:if>
</xsl:for-each>
any() function, would match to any node in the
preceding-sibling::, and following-sibling::  *axis*
any() function, would be equivalant to 
(preceding-sibling:: or self:: or following-sibling::
) 
I am wondering, if this might be appropriate ??
Regards,
Mukul
__________________________________
Do you Yahoo!?
Protect your identity with Yahoo! Mail AddressGuard
https://antispam.yahoo.com/whatsnewfree

				
            
RESOLUTION: comment was withdrawn, closed, no action, issues list
    needs to point to message in the same thread in which the commnter
    says "I'm happy".
			
         

Thank you for your responses. I am happy with the
answers.. 
Thanks Jeni, Thanks David
Regards,
Mukul

				
            

				
            
RESOLUTION: comment was withdrawn, closed, no action, issues list
				
            
needs to point to message in the same thread in which the commnter
				
            
says "I'm happy".
			
         

				
            
Section 2.3.2 Typed Value and
				String Value, bullet 3d states: "If
				the type annotation denotes a complex
				type with non-mixed complex content,
				then the typed value of the node is
				undefined. " Since non-mixed complex
				content includes a content type of
				"empty", and bullet c covers empty
				content, we think this text should
				instead say "If the type annotation
				denotes a complex type whose content
				type is elementOnly, then the typed
				value of the node is undefined."
			
         

				
            
Note: it's now section 2.4.2 4d. 
    RESOLUTION: qt-2003Nov0014-06 closed:
    this change has already been made.
    ACTION A-SJ04-33: Michael Sperberg-McQueen to respond to Schema WG
    to confirm the resolution.
			
         

				
            

				
            
Note: it's now section 2.4.2 4d.
				
            
RESOLUTION: qt-2003Nov0014-06 closed:
				
            
this change has already been made
				
            
ACTION A-SJ04-33: Michael Sperberg-McQueen to respond to Schema WG to confirm the resolution.
			
         

SECTION 2.4.3: SequenceType Syntax
The first definition:
"[Definition: When it is necessary to refer to a type in an XPath expression, the SequenceType syntax is used. The name SequenceType suggests that this syntax is used to describe the type of an XPath value, which is always a sequence.]"
While this describes the use of SequenceType it does not define it as it purports.
Regards,
Mark Scardina
Oracle Corporation

SECTION 2.4.4: SequenceType Maching
"Module" is used in the 3rd paragragh and is an XQuery construct. Also the 2nd note refers to an XQuery function syntax.
Regards,
Mark Scardina
Oracle Corporation

			
            
Done.
		
         

SECTION 2.3: Documents
In the first sentence it would be more precise to say "XPath is used in the processing of documents."
Regards,
Mark Scardina
Oracle Corporation

			
            
Overtaken by events. This section has changed.
		
         

SECTION H.1: Incompatibilities when Compatibility Mode is true
Number 8. states "In XPath 1.0, the < and > operators, when applied to two strings, attempted to convert both the strings to numbers and then made a numeric comparison between the results. In XPath 2.0, these operators perform a string comparison using the default collating sequence. (If either value is numeric, however, the results are compatible with XPath 1.0)"
The last sentence in #8 is not true for special cases defined in #6 as this would result in 5e0>4 becoming NaN>4.
Regards,
Mark Scardina
Oracle Corporation

SECTION 3.1.2: Variable Reference
Shouldn't the the first sentence "A variable reference is a QName preceded by a $-sign" be a defintion?
Regards,
Mark Scardina
Oracle Corporation

			
            
Done.
		
         

SECTION 3.1.1: Literals
The 2nd note states: "If a string literal is used in an XPath expression contained within the value of an XML attribute, the characters used to delimit the literal must be different from the characters that are used to delimit the attribute."
Aren't the only characters this pertains to are ' and "? If so shouldn't the spec be explicit?
Regards,
Mark Scardina
Oracle Corporation

Delete this note from XQuery but not from XPath (because it's common to
          embed XPath in XML). And within XPath qualify it with respect to its use.

			
            
AE: Is this legal: <element a='{'b'}'/>?
DC: I believe that we decided this isn't legal: because people wanted
    to be able to use existing XML parsers to parse element
    constructors that might have things like this in them.
AE: It's not a problem to process it, but a parser would find it
problematic.
MK: Does this note appear in XQuery as well as XPath? We allow all sorts
of things in attributes in XQuery that aren't allowed in XML. I was
under the impression that we allowed all sorts of stuff in an attribute
constructor on the XQuery side.
DC: I'll try to put a band-aid on the hole by saying we shouldn't have
different rules in XQuery and XPath.
 MK: If we're trying to restrict what you can put in an attribute
    constructor in XQuery, then we've got to do a lot more work than
    this.
HZ: It appears in XPath and it is explicitly talking about a value
within an XML attribute.
AE: Putting this in a note makes it non-normative. So I don't know
    what to do with this.
MK: I suggest we remove this note from the XQuery document.
HZ: There's a note in 3.5 of XPath about the "<" symbol, so we have a
precedent. That doesn't appear in XQuery.
MK: Embedding in XML is a design requirement for XPath but not for
XQuery.
Proposal: Delete this note from XQuery but not from XPath (because it's
common to embed XPath in XML). And within XPath qualify it with respect
to its use.
Accepted.
		
         

SECTION 2.4.4.2 : Matching an ItemType and an Item
Shouldn't the 2nd sentence:
"An AtomicType AtomicType matches an atomic value whose actual type is AT if type-matches(AtomicType, AT) is true."
actually be
"An atomic type, AtomicType matches an atomic value whose actual type is AT if type-matches(AtomicType, AT) is true."
Regards,
Mark Scardina
Oracle Corporation

			
            
Recommend to reject.
Italics and underscores are used to distinguish the different uses of
AtomicType (one of them is a reference to the name of a production).
		
         

SECTION 2.2.3.2: Dynamic Evaluation Phase
Should there be a definition of dynamic types here as they derive from the DM which exists prior to the Static or Dynamic Analysis phase?
Regards,
Mark Scardina
Oracle Corporation

			
            
Overtaken by events. The definition of dynamic type has been
moved to "Data Model Generation" which occurs before the suggested
location.
		
         

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]
Hello,
     Following are comments on XPath that we believe to be editorial in 
nature.
------------------------------------------------------------------
Section 2
In the lead-in to the bulleted list, "prefixes(these" should be "prefixes 
(these".
------------------------------------------------------------------
Section 2.1.1
The definition of the default collation needs to indicate that there must 
be a (URI, collation) pair in the in-scope collations for which the 
collation is the default collation.  The definition of 
fn:default-collation requires it.
------------------------------------------------------------------
Section 2.1.1
To avoid confusion, it might be better to rename the "Statically-known 
documents" component to "Statically-known document types" or something 
similar.  That would avoid any need for a note to clarify the meaning. 
Even if the note is kept, the component would benefit from the name 
change.
Similarly, "Statically-known collections" could be renamed "Statically 
known collection types".
------------------------------------------------------------------
Section 2.2.1
The second paragraph following the numbered list, states "For example, if 
the data model was derived from an input XML document, the dynamic types 
of the elements and attributes are derived from schema validation."
The words "are derived" should be "might be derived", or something 
similarly vague.
------------------------------------------------------------------
Section 2.2.5
The first paragraph of this section states, "Enforcement of these 
consistency constraints is beyond the scope of this specification." 
Suggest replacing this sentence with, "An implementation is not required 
to detect whether the data model, static context and dynamic context obey 
these consistency constraints.  The behavior of an implementation if a 
consistency constraint is violated is implementation-dependent."
------------------------------------------------------------------
Section 2.3.2
In the second bulleted list, the meaning of the term "function returns" 
isn't necessarily clear.  The entire list might be better rephrased in 
terms of the parts of the relevant expressions that are atomized: 
"arithmetic operands", "function arguments", etc.
At the very least, "and returns" should probably be removed from the list.
------------------------------------------------------------------
Section 3.2.1.1
In the paragraph following the bulleted list, the definitions of "forward 
axis" and "reverse axis" are phrased so that the self axis is both a 
forward and a reverse axis.  Perhaps this paragraph should be made into 
explanatory material, with the normative definitions of forward and 
reverse axes being the explicit lists of axes in the paragraph that 
follows this one.
------------------------------------------------------------------
Section 3.2.3
In the bulleted list, the example "parent::node()" states that "If the 
context node is an attribute node, this expression returns the element 
node (if any) to which the attribute node is attached."  The same should 
also be stated for namespace nodes.
------------------------------------------------------------------
Section 3.2.4
The last example in this section is "E/.".  Although this is an 
interesting example, it doesn't belong in a section on abbreviated syntax.
------------------------------------------------------------------
Section 3.4
The second item in the numbered list indicates that the result of applying 
an arithmetic operator on an empty sequence is an empty sequence.  Some 
rationale for this behaviour (as opposed to a dynamic error being 
reported) would be desirable.
------------------------------------------------------------------
Section 3.5.1
The third item in the numbered list states, "If the value of the first 
atomized operand is not comparable with the value of the second. . . ." 
This should be "If the type of the first atomized operand is not 
comparable with the type of the second. . . ."
------------------------------------------------------------------
Appendix B
The "op" pseudo-prefix is used in this section, but its meaning is never 
explained.
------------------------------------------------------------------
Appendix G
It would be helpful if this listed the implementation-defined and 
implementation-dependent features.  This same comment applies to other 
specifications in this set.
------------------------------------------------------------------
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

			
            
Done.
		
         

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]
Sections 2.4.4 and 3.1.5
In section 2.4.4, the second paragraph beneath the first note refers to 
"the module in which the given type is encountered."  In addition, in 
section 3.1.5, the third bullet under the definition of "function 
conversion rules" speaks of the module in which a function call takes 
place, and the module in which a function is defined.
The term "module" is only defined for XQuery, not for XPath, and must not 
be used in these two places.
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

			
            
Done.
		
         

[My apologies that these comments are coming in after the end of the Last 
Call comment period.]
Section 2.4.2
The second example in list item 3 refers to "xs:IDREFS, which is a list 
datatype derived from the atomic datatype xs:IDREF."  In the terminology 
of XML Schema, xs:IDREFS is derived by restriction from xs:anySimpleType. 
This should instead say, "xs:IDREFS, which is a list datatype whose item 
type is the atomic datatype xs:IDREF."
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

			
            
Done.
		
         

SECTION 3.2.4: Abbreviated Syntax
3.2.4, bullet 3, gives an explanation of // as
being effectively replaced by /descendant-or-self::node()/
However, this is only true for // used in non-initial positions.
If // is used at the beginning of a path expression, it is 
effectively replaced by 
fn:root(self:node()) treat as document-node()/descendant-or-self::node()
as explained in 3.2 Path Expressions.
So we need to make it clear here. Or repeat the abbreviation of
the initial '/' and '//'  here in 3.2.4 as well.
- Steve B.

			
            
Done.
		
         

SECTION 3.2.1.1: Axes
In 3.2.1.1 Axes, it defines the parent and descendant axis using
'transitive closure'. But it does not give the exact defintion
of 'transitive closure'. Should it be defined ?
- Steve B.

SECTION 3.2: Path Expressions
3.2 Path expressions, it gives an exact defintion of initial /
and // (used a the beginning of a path expression), which is
different from / or // used in the subsequent path expressions
as a step separator. I recommend moving the 3 paragraphs explaining
the initial / and // before the paragraph explaining the /
and // used in non-initial positions. 
Also the sentence "Each occurrence of // in a path expression "
should be replaced by "Each non-initial occurence of // in a path expression"
- Steve B.

			
            
Done.
		
         

Appendix B2 Operator Mapping	
Editorial	
ge, le for xs:boolean are missing their return type.

			
            
Done.
		
         

It is great that XPath/XQuery allow node tests of the form *:NCName.
I have been asking for this long ago (or did I ask CSS?). It helps
dealing with same/similar elements in different namespaces and will
take off some pressure of future namespace discussions. CSS should
make sure that they have a similar feature; I'm copying them.
[see https://www.w3.org/TR/2003/WD-xpath20-20031112/, 3.2.1.2]
As an important detail, the text in the spec should make clear
that *:NCName also applies to the default namespace.
Regards,   Martin.

			
            
Done.
		
         

"XPath allows functions to be called" sounds totally redundant.
Please remove or improve wording.
Regards,   Martin.

			
            
Done.
		
         

2.5.3 in XPath should make it very clear that if the spec defines an
error, that error has to be reported, and processing has to stop.
Regards,    Martin.

			
            
Overtaken by events. The term "schema path" has been dropped.
		
         

The term 'schema path' should be better defined and added to the
glossary.
regards,    Martin.

The hierarchy shown in Fig. 2 has a box saying 'specific list and union
types such as xs:IDREFS'.
What about other, e.g. user-constructed, list and union types?
Regards,   Martin.

			
            
Recomment to reject. Figure gives an example of a list type
but is not intended to be exhaustive.
		
         

2.3.1, last paragraph, uses a rather clumsy way to constrain the order
of nodes in different trees. This should be worded so that it is
easy to understand directly: All nodes of a tree are ordered together,
the order of the trees is implementation-dependent.
Regards,   Martin.

			
            
Recommend to reject. Suggests revising the definition of
document order, but it has been debated extensively and is now consistent
in all our documents.
		
         

XPath 2.2.3.2 explains static and dynamic errors. It could
be nice to have a table showing cases that are
- static but not dynamic errors
- dynamic but not static errors
- static and dynamic errors
- neither static nor dynamic errors
Also, renaming the 'static typing feature' to 'strict typing feature'
may make things easier to understand.
Regards,    Martin.

The purpose of known documents/collections (both static and
dynamic) needs to be better explained. For example, in the
general case, is 'dynamic available documents' equivalent
to all the documents on the Web?
Regards,    Martin.

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 3.2.3
The twenty-sixth through the twenty-eighth bullets (which contain 
predicates of the form [attribute::type="warning"]) all indicate that they 
test whether the context node "has a type attribute with value warning." 
However, if the attribute is of a list type, the general comparison is 
true if at least one value in the atomized sequence has the value 
"warning".  For instance, the string value of the attribute might be "info 
warning error", and the typed value might be the sequence of xs:string 
values ("info", "warning", "error").
Suggest changing "has a type attribute with value warning" to "has a type 
attribute, and the result of the equality general comparison between the 
attribute and "warning" is true."
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 3.2.2
The paragraph between the two bulleted lists (which defines the terms 
"reverse axis" and "reverse document order") states, "By contrast, 
(preceding::foo)[1] returns the first foo element in document order, 
because the axis that applies to the [1] predicate is the child axis."
This reference to the child axis applying to the predicate is carried over 
from how this was described in XPath 1.0.  In XPath 2.0, this should state 
that, as described in 3.2.1, the items from a FilterStep are returned in 
the same order as the primary expression, which is document order in the 
case of an axis step.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

			
            
Done.
		
         

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 2.4.4
The second paragraph beneath the first note uses the adjectives "known" 
and "unknown" to describe types.  The term "unknown types" might confuse 
the reader, as the same term is used in Data Model with a different 
meaning.  Suggest replacing "known types" with "types in the in-scope 
schema definitions" and "unknown types" with "types that are not in the 
in-scope schema definitions", respectively.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

			
            
Recommend to reject. The paragraph defines its terms and
uses them consistently.
		
         

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 2.3.4
The last sentence of this section states that references to fn:doc and 
fn:collection with the same absolute URI must return the same result.
The term "same result" should be "same sequences of nodes", or something 
similar, to make clear the depth of the requirement.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

			
            
Done.
		
         

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 2.3.1
The second paragraph states, "document order is the order returned by an 
in-order, depth-first traversal. . . ."  In fact, it's defined by a 
pre-order, depth-first traversal.
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

			
            
Overtaken by events. Definition of document order has
changed.
		
         

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 2.1.2
The definition of "focus" in the fourth paragraph states that "The focus 
enables the processor to keep track of which nodes are being processed by 
the expression."  However, the context item might not be a 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

			
            
Done.
		
         

[Speaking on behalf of reviewers from IBM, not just personally.]
Section 2.1.1
Some components of the static context are described as sets of pairs, in 
particular, the in-scope namespaces, in-scope variables, and in-scope 
collations.  In each case, there is an implicit constraint on the 
component - namely, that the first item in any pair in each set is not 
associated with more than one value in the set.  For instance, the 
in-scope namespaces must not be the set:
  {(pre,https://ex.org), (pre,https://ex.net)}
Those consistency constraints should be stated explicitly.
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.1.1
In the definition of Default element/type namespace, it is stated that 
this "namespace may be provided by the external environment."  "External 
environment" is an XQuery term; this should say "host language".
Thanks,
Henry
------------------------------------------------------------------
Henry Zongaro      Xalan development
IBM SWS Toronto Lab   T/L 969-6044;  Phone +1 905 413-6044
mailto:zongaro@ca.ibm.com

			
            
Done.
		
         

Dear Colleagues,
This comment pertains to the Nov. 12 2003 version of XPath 2.0 [1].
[1] https://www.w3.org/TR/xpath20/
Lisa Martin, on behalf of the XML Schema Working Group
----------------------------------------------------
Section 2.4.4.3 Matching an ElementTest and an Element Node
      Bullet 2 states:
         2. element(ElementName, TypeName) matches a given element node if:
               a. ... , and:
               b. type-matches(TypeName, AT) is true, where AT is the type
   of
                  the given element node.   ...
      The first example is:
         Example: element(person, surgeon) matches an non-nilled element
   node
         whose name is person and whose type annotation is surgeon.
 Given the rules for type-matches (ET, AT), shouldn't the example instead
say " ... and whose type annotation is surgeon, or is a type derived
 from surgeon"?    This comment applies to many examples in this, and
following sections.

Dear Colleagues,
This 2-part comment pertains to the Nov. 12 2003 version of XPath 2.0 [1].
[1] https://www.w3.org/TR/xpath20/
Lisa Martin, on behalf of the XML Schema Working Group
----------------------------------------------------
Section 2.1.1 Static Context
   [Definition:  In-scope type definitions.    Each named type definition
   is identified either by a QName (for a named type) or by an
   implementation-dependent type identifier for an anonymous type.  ... ]
   a.  The use of "Each named type definition is identified either..."
implies that anonymous types are considered "named type definitions"  in
this specification.   Is this correct?   If so, then constructor functions
are defined for anonymous types - was that intended?   If not, the first
use of "named" in the definition should be dropped.
b. WRT implementation-dependent type ids for anonymous types, we note that
elsewhere (schema context path) QT defines names for anonymous types. Would
it be appropriate to mandate their use in this case? We also note that
discussions are ongoing between two WGs about harmonizing schema context
paths and SCDs.

			
            
First part done; second part overtaken by events
(no more schema context paths).
		
         

XQuery 1.0: An XML Query Language
W3C Working Draft 12 November 2003
3.8 FLWOR Expressions
(1)
You should clarify how the "tuple stream" relates (or doesn't) to the
dynamic environment.
(2)
Given the example "tuples" in 3.8.1, such as
   ($i = 1, $j = 3)
it seems clear that they're not really tuples (or certainly not best
described as tuples). For instance,
   ($j = 3, $i = 1)
would (properly speaking) be a different tuple, and yet it would appear
to have exactly the same effect as far as XQuery is concerned.
So in fact, these things are best described as *mappings* (from
variables to values), not tuples.
-Michael Dyck

			
            
Recommend to reject. Commentor doesn't like the term
"tuples," wants to change it to "mappings".
		
         

W3C XSL WG Editorial Comment on XPath 2.0 Last Call Draft
Comment on 2.4.2:
The data-model accessors do not belong in this section. It would
be more useful if they were introduced in the "datamodel" section
(second half of 2.2.1).

			
            
Recommend to reject. Suggests that we move the input
functions from "Concepts" to "Data Model Generation".
		
         

W3C XSL WG Editorial Comment on XPath 2.0 Last Call Draft
Comment on 2.3.4:
It would be useful to refer to "available documents" and "available
collections" in the dynamic context.

			
            
Done.
		
         

W3C XSL WG Editorial Comment on XPath 2.0 Last Call Draft
Comment on 2.3.3, note at the end of the section:
It would make the note much clearer if the following was added
at the end:
   e.g. in explicit casts, in function calls for arguments that are
   expected to be boolean.

			
            
Done.
		
         

W3C XSL WG Editorial Comment on XPath 2.0 Last Call Draft
Comment on 2.3.2, 1st paragraph:
The first two sentences of the current definition should be outside
the "definition markup". The third sentence is the REAL definition.

			
            
Done.
		
         

It is okay that XQuery copies parts of XPath. But it's very
annoying for reviewers, implementers, and users that these
sections are not clearly marked. Please mark them.
Regards,   Martin.

			
            
Recommend to reject.
Commentor wants the parts of the XQuery document that are in common with
XPath to be "marked". This comprises more than half of the document.
		
         

Comment on 2.2.3.2, 4th paragraph, definition of "dynamic type":
The "definition" of "dynamic type" is inconsistent with the use
of the term elsewhere. It DEFINES it to be "associated with each
value as it is computed" in the DYNAMIC PHASE. The term is
also used in 2.2.1 where it is stated that "Each atomic value,
element node, and attribute node in the data model is annotated
with its dynamic type." in the data model.
A similar term (is it intended to be the same?) "dynamic (run-time) type"
is used in 2.4.2; also referring to type annotations of nodes in the
data model. Both these uses have nothing to do with values computed
during the dynamic phase.
The inconsistency can be solved by removing the first sentence of
the definition and adding a sentence or two really defining the term.
The removed sentence could be retained outside the definition.

			
            
Done.
		
         

XPath section 2.4.4 contains the sentence:
An unknown type might be encountered, for example, if the module in
which the given type is encountered does not import the schema in which
the given type is defined.
Modules, of course, are an XQuery concept. I suggest changing the
example to:
An unknown type might be encountered if a source document has been
validated using a schema that was not imported into the static context.
(It might also be useful to add this example to the XQuery spec).
There is another reference to modules in 3.1.5:
If the function call takes place in a module other than the module in
which the function is defined, this rule must be satisfied in both the
module where the function is called and the module where the function is
defined (the test is repeated because the two modules may have different
in-scope schema definitions.) 
I suggest deleting this sentence from the XPath version of the document.
Michael Kay

			
            
Done.
		
         

In Section 3.2.1.1, the last bullet refers to the functions
get-in-scope-namespaces and get-namespace-uri-for-prefix.  "namespaces"
should be changed to "prefixes", and the get- prefix should be removed (if
it hasn't been already).
Thanks,
Priscilla Walmsley

			
            
Done.
		
         

Minor nit:
In Section 3.8, the example shows a book title as "Advanced Unix
Programming".   Two examples later (supposedly in the results of a query on
the first example), the title has changed to "Advanced Programming in the
Unix environment".  
I think the name of the book is actually "Advanced Programming in the Unix
environment".
Thanks,
Priscilla Walmsley

			
            
Done.
		
         

In Section 3.1.5, it says:
"3. The function is evaluated using the converted argument values. The
result is a value of the function's declared return type."
As I understand it, the return value of a function is not always the
declared return type.  distinct-values( (1,2,3) ) would not return 3 values
of type xdt:anyAtomicType.  
The XQuery draft contains a paragraph of clarification that includes "the
value returned by a function retains its most specific type, which may be a
subtype of the declared return type of the function.".  I think this
paragraph should be included in XPath as well.  
Also, the paragraph in the XQuery draft implies that it is only for
user-defined functions. I think it should apply to both built-in and
user-defined functions in XQuery, right?
 
Thanks,
Priscilla Walmsley

			
            
Done.
		
         

Hi
Section A.1.1 and A.2.1 provide helpful grammar notes that are clearly
visible in the preceding BNF.
Section A.3 provides equally significant clarification that does not.
For no very obvious reason gratuitous ElementName and AttributeName
aliases for QName are provided, yet there is no FunctionName to which the
A.3 text should be annotated.
Therefore please replace QName by FunctionName in FunctionCall and
add e.g.
FunctionName ::= QName /* A.3 reserved names */ 
	Regards
			
		Ed Willink
------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@iee.org
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          https://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------

			
            
Accepted
		
         

Hi
The signature example should more clearly indicate that this is not
XPath syntax, since "as" must be preceded by "cast", "castable" or "treat"
according to Appendix A.
	Regards
			
		Ed Willink
------------------------------------------------------------------------
E.D.Willink,                             Email: mailto:EdWillink@iee.org
Thales Research and Technology (UK) Ltd, Tel:  +44 118 923 8278 (direct)
Worton Drive,                            or  +44 118 986 8601 (ext 8278)
Worton Grange Business Park,             Fax:  +44 118 923 8399
Reading,   RG2 0SB
ENGLAND          https://www.computing.surrey.ac.uk/personal/pg/E.Willink
------------------------------------------------------------------------

			
            
Recommend to reject. The function signature is presented
in the standard notation used in the Functions & Operators document.
		
         

Section 3.2.1.1 Axes	
Editorial	
Either always use () in grammar (as in forwardstep) or do not as in
reverse step.

				
            
See [447] RESOLUTION: closed, fixed.  see https://www.w3.org/XML/Group/xsl-query-specs/proposals/grammar-lc-response/xpath.html#doc-xpath-ReverseAxis
            
			
         

				
            

				
            
RESOLUTION: closed, fixed.
			
         

Section 3.2.1.1 Axes	
Editorial	
Add node to parent that an attribute may have an element as a parent
even though it is not a child of the element.

			
            
Done.
		
         

Section 3.2	Path Expressions	
Editorial	
"A "//" at the beginning of a path expression is an abbreviation for the
initial steps fn:root(self::node()) treat as
document-node()/descendant-or-self::node().": 
Please reword to make clear that it need to be followed by relative path
expression and that it extends to fn:root(self::node()) treat as
document-node()/descendant-or-self::node()/ (note the final /).

			
            
Done.
		
         

Section 3.2.1 Steps	
Editorial	
Please remove "The result of the filter step consists of all the items returned by the primary expression for which all the predicates are true. If no predicates are specified, the result is simply the result of the primary expression.": This has been said in paragraph before and is also falsely implying that you can use a naïve conjunction of all the predicates. Also rewrite beginning of following sentence.

Section 3.1.5 Function Calls	
Editorial	
Please reword: "The result is a value of the function's declared return
type." to "The result is an instance of the function's declared return
type."

			
            
Done.
		
         

Section 2.4.4.2 Matching an ItemType and a Value	
Editorial	
"document-node(E)": Note that PI, Comments and element may be
interleaved.

Section 2.4.4.2 Matching an ItemType and a Value	
Editorial	
Please replace "xs:IDREF*." with "xs:IDREF+." Xs:IDREFS is a sequence of
at least one.

			
            
Done.
		
         

Section 2.4.4 SequenceType Matching	
Editorial	
Please qualify ET in first two rules as known type.

			
            
Done.
		
         

Section 2.4.4 SequenceType Matching	
Editorial	
Add a better example for a case of unknown types. For example, instance
of myInt is being passed to a function from a module that checks for an
instance of xs:integer inside the function but does not know the type
myInt.

			
            
Recommend to reject. I believe unknown types are clearly explained.
		
         

Section 2.4.4 SequenceType Matching	
Editorial	
Please reword: "actual type of a given value " -> "actual type of a
given sequence of items" (see item MS-XQ-LC1-001)

			
            
Recommend to reject. Another complaint about the word "value".
		
         

Section 2.4	Types	
Editorial	
Please reword: "XQuery is a strongly typed language with a type system
based on [XML Schema]. " -> "XQuery's type system is based on [XML
Schema]. " Note that we have both strongly (e.g., xs:string) and weakly
(e.g., xdt:untypedAtomic) typed components in XQuery.

https://www.w3.org/TR/2003/WD-xpath20-20031112/#doc-xpath-ForwardAxis
https://www.w3.org/TR/2003/WD-xpath20-20031112/#doc-xpath-ReverseAxis
3.2.1 Steps
Editorial (esthetical)
The production [52] uses additional parentheses around each pair
"axis name" "::", whereas the production [53] doesn't.
Please use a consistent notation.
Kind regards,
Oliver Becker
/-------------------------------------------------------------------\
|  ob|do        Dipl.Inf. Oliver Becker                             |
|  --+--        E-Mail: obecker@informatik.hu-berlin.de             |
|  op|qo        WWW:    https://www.informatik.hu-berlin.de/~obecker |
\-------------------------------------------------------------------/

				
            
See [447] RESOLUTION: closed, fixed.  see https://www.w3.org/XML/Group/xsl-query-specs/proposals/grammar-lc-response/xpath.html#doc-xpath-ReverseAxis
            
			
         

A small inaccuracy in     3.2.2 Predicates
it reads:
By contrast, |(preceding::foo)[1]| returns the first |foo| element in 
document order,
 -> correct
...because the axis that applies to the |[1]| predicate is the |child| axis.
-> I dont see any child axis here
    If I am not mistaken, it should read something like "because the
   expression that applies to the |[1]| predicate is itself in document 
order"
  (being a whole path expression, and not a simple reverse step)

			
            
Done.
		
         

"2.4 Predicates
An axis is either a forward axis or a reverse axis. An axis that only ever
contains the context node or nodes that are after the context node in
document order is a forward axis. An axis that only ever contains the
context node or nodes that are before the context node in document order
is a reverse axis. Thus, the ancestor, ancestor-or-self, preceding, and
preceding-sibling axes are reverse axes; all other axes are forward axes.
Since the self axis always contains at most one node, it makes no
difference whether it is a forward or reverse axis. The proximity position
of a member of a node-set with respect to an axis is defined to be the
position of the node in the node-set ordered in document order if the axis
is a forward axis and ordered in reverse document order if the axis is a
reverse axis. The first position is 1."
This is the first paragraph of section 2.4 Predicates. It deals
exclusively with axes and its place is in section 2.2 Axes.
Thanks,
Dimitre Novatchev.
__________________________________
Do you Yahoo!?
Free Pop-Up Blocker - Get it now
https://companion.yahoo.com/

			
            
Done.
		
         

2.2 Processing Model
contains an arrow labelled "SQ3 process query prolog" which should not
be in the Xpath version.
Also references to this diagram could be hyperlinks, eg 
Serialization is the process of converting a set of nodes from the data
model into a sequence of octets (step DM4 in Figure 1.) 
                                 ^^^^^^^^^^^^^^^^^^^^^
in appendix E.
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:
https://www.star.net.uk
________________________________________________________________________

			
            
Partly done. The incorrect reference to Prolog has been removed.
Hyperlinks have not been added (I don't think this is necessary.)
		
         

I commented on an earlier draft see Mike kay's response here
https://lists.w3.org/Archives/Public/public-qt-comments/2002Nov/0087.html
that the spec was unclear on the order returned by single step path
expressions.
The document does now say (in 3.2.1)
  <p>The result of an <b>axis step</b> is always a sequence of zero or more
  nodes, and these nodes are always returned in document order.
which clarifies the result order, however the phrase
  <p>In a sequence of nodes selected by an axis step, each node is assigned a
  context position that corresponds to its position in the sequence. If the
  axis is a forward axis, context positions are assigned to the nodes in
  document order, starting with 1. If the axis is a reverse axis, context
  positions are assigned to the nodes in reverse document order, starting with
  1. This makes it possible to select a node from the sequence by specifying
  its position.</p>
which appears a little later ought to have a clarifying note.
In Xpath 1 this was clear enough as it was specifying the current node
list which was the only ordered construct and was always a transient
thing not a first class object, however in Xpath2 where the result of
the expression is itself ordered I think that most readers will
miss the distinction between
"The result of an <b>axis step</b>" in the first quote (document order)
and
"In a sequence of nodes selected by an axis step" in the second (reverse order)
In particular there should be an explicit example somewhere close to
this point that points out that
ancestor-or-self::*[1] is the root of the current document and
(ancestor-or-self::*)[1] is the current node.
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:
https://www.star.net.uk
________________________________________________________________________

			
            
Done. The requested example of numeric predicates on
reverse axes is found in the Predicates section.
		
         

Hello XPath 2.0 Working Group,
In Section 3.7 of the XPath 2.0 draft of 22 August 2003 the following
example is included.
	for $a in distinct-values(//author)
	return ($a,
        	for $b in //book[author = $a]
        	return $b/title)
I think it can be replaced by the following sniplet.
	for $a in distinct-values(//author)
	return ($a, //book[author = $a]/title)
Is this correct? Why is chosen for the first version (if the second
version is correct) instead of the second? Thank you in advance,
	Bernard van Gastel
	- Student Computer Science,
		University of Nijmegen,
		The Netherlands

			
            
Done.
		
         

In Xpath 1, a reader does not have to read far in to the document (5
pages out of 35 in my "print preview") before seeing examples of the
fundamental "path" nature of Xpath:
child::para selects the para element children of the context node
In the Xpath 2 document, I fear the majority of readers will have given
up in despair before ever seeing a Path. The description of steps comes
after mountains of dense only marginally interesting on facts on typing
syntax, diagrams of possible processing models, etc. Error handling
(2.5) and Optional features (2.6) come before the reader has even seen
any basic expression syntax. This all seems to be backwards.
I now have to wait until page 47 of 89 (ie over half way in) before
seeing the example 
child::para selects the para element children of the context node
I suspect that you are not going to want to completely re-structure the
document this late in the process (although that would be worthwhile I
think) but if you don't do that, could you at least expand section 2
Basics to have some usable (to an end-user) description of what a simple
Xpath expression looks like?
Sorry that this isn't a particularly constructive comment, but it's hard
to suggest specific re-organisation without following the details of
your document build process, whether reordering sections for example
could be purely a stylesheet matter or would require re-writing the
source xml, also I realise that the sources are shared with the Xquery
doc, although probably these comments apply equally to that.
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:
https://www.star.net.uk
________________________________________________________________________

				
            
There are many places in the spec where
                            terminology from XML Schema is used,
                            without references or links. For example,
                            bullet 4.c of section 3.10.2 contains the
                            following sentence: "The input value is
                            first converted to a value in the lexical
                            space of the target type by applying the
                            whitespace normalization rules for the
                            target type; a dynamic error is raised if
                            the resulting lexical value does not
                            satisfy the pattern facet of the target
                            type." We suggest you add links where you
                            use XML-Schema-specific terminology.
			
         

				
            
The specification contains lots of
                            technical terms. We feel that a glossary
                            section would be very useful.
			
         

			
            
Done.
		
         

				
            
Section 2.1.1 Static Context: In-scope
                            Type definitions In-scope type definitions
                            are the type definitions that are in scope
                            during processing of an expression. These
                            include XML Schema built-in type
                            definitions, some pre-defined XPath type
                            definitions and possibly user-defined type
                            definitions as well. From the XPath spec:
				
            
					
               
"[Definition: In-scope type
                            definitions. The in-scope type definitions
                            always include the predefined types listed
                            in 2.1.1.1 Predefined Types. Additional
                            type definitions may be provided by the
                            host language
                            environment.]"
					
               
XML Schema distinguishes named types,
                            which are given a QName by the schema
                            designer, must be declared at the top
                            level of a schema, and are uniquely
                            identified by their QName, from anonymous
                            types, which are not given a name by the
                            schema designer, must be local, and are
                            identified in an implementation-dependent
                            way. Both named types and anonymous types
                            can be present in the in-scope type
                            definitions."
				
            
				
            

					
               
(in general) 'QName' (in the sense of identifiers in
	  the * lexical space of xsd:QName) and 'expanded QName' (in
	  the sense of members of the value space of xsd:QName) do not
	  seem to be distinguished consistently. (Cf. definition of
	  in-scope functions in 2.1.1)
					
               

						
                  
We think there needs to be more explicit text
	  (similar to what is in the Schema Rec for QName resolution)
	  on
						
                  

							
                     
mapping from lexical QNames to expanded QNames
             and,
							
                     
mapping from expanded QNames to types (and other
	      things, like functions).
						
                  
					
               
					
               
For "must be declared at the top level of a schema",
          we suggest recasting to something like "are top level". Also
          "must be local" to "are local". (that is, you do NOT want
          RFC 2116. wording here)
				
            
			
         

			
            
Partly done, and partly overtaken by events.
		
         

				
            
Section 2.1.1 Static Context:
				In-scope Element Declarations. The
				paragraph includes "An element
				declaration includes information about
				the substitution groups to which this
				element belongs." What does
				"substitution groups" refer to? Is
				this different from the {substitution
				group affiliation} of an XML Schema
				element declaration? In particular,
				note that {substitution group
				affiliation} names a single element;
				from your mention of 'substitution
				groups' in the plural we believe you
				may have in mind (a) the {substitution
				group affiliation} property itself
				[i.e. the plural is a typo], (b) the
				transitive closure of {substitution
				group affiliation}, or (c) its inverse
				(the list of elements which are in the
				substitution group headed by this
				element.)
				
            
Note also (just in case) that the
                                ability to substitute an element A for
                                an element B depends not only on the
                                {substitution group affiliation}
                                property of A's declaration (and those
                                of other possibly intermediate
                                elements) but also on the {block}
                                property of B's declaration. We think
                                you may wish to describe the relevant
                                information in terms of the "effective
                                substitution group" headed by B, with
                                a reference to the XML Schema spec.
			
         

				
            
The phrase needed is,
        the effective substitution group headed by the element.
    The last paragraph in the comment has the appropriate wording.
    RESOLUTION: qt-2003Nov0014-04 closed, Don to change wording. ACTION
    A-SJ04-32: Don to respond to Schema WG to confirm the resolution.
    Note: "effective substitution group" is defined in Schema 2nd Edition
    Part 1 Note: subsequently, Henry and Michael discovered that the
    correct term is actually from 'substitution group' to 'substitution
    group headed by E', and there's no such term as effective substitution
    group.
			
         

				
            

				
            
The phrase needed is,
				
            
the effective substitution group headed by the element.
				
            
The last paragraph in the comment has the appropriate wording.
				
            
RESOLUTION: qt-2003Nov0014-04 closed, Don to change wording. ACTION
				
            
A-SJ04-32: Don to respond to Schema WG to confirm the resolution.
				
            
Note: "effective substitution group" is defined in Schema 2nd Edition
				
            
Part 1 Note: subsequently, Henry and Michael discovered that the
				
            
correct term is actually from 'substitution group' to 'substitution
				
            
group headed by E', and there's no such term as effective substitution
				
            
group.
			
         

				
            
Section 2.3.2 Typed Value and
				String Value, bullet 2 states: "The
				typed value of an attribute node with
				the type annotation xdt:untypedAtomic
				is the same as its string value, as an
				instance of xdt:untypedAtomic. The
				typed value of an attribute node with
				any other type annotation is derived
				from its string value and type
				annotation in a way that is consistent
				with schema validation."
				
            
We think this may be clearer if you
                                replace "in a way that is consistent
                                with schema validation" with "using
                                the lexical-to-value-space mapping
                                described in XML Schema Part 2 for the
                                relevant type."
			
         

			
            
Done.
		
         

				
            
Section 2.4.1 Sequence Type: this
				section introduces a path language to
				designate some schema components. This
				appears to duplicate a subset of the
				functionality of SCDs. The XML Schema
				WG is chartered to produce a
				specification of SCDs. From the
				charter [1]: "the definition of a
				free-standing specification describing
				how to name or refer to arbitrary
				components in an XML Schema; in
				existing discussions these are
				sometimes referred to as normalized
				universal names or NUNs".
				
            
Schema context paths as defined
                                here and in the Formal Semantics
                                appear to us broadly consistent with
                                our existing SCD design. We wish to
                                make SCDs as useful as possible; we
                                note that you haven't used the
                                existing SCD syntax, and we would like
                                to know if the existing SCD syntax
                                could be changed to make it more
                                usable in the Query context. We
                                believe discussion is needed on this
                                topic.
			
         

***** XML Schema WG - ACTION (2004-01-21): AV and MH to work with Scott Boag
to clarify possibilities for and issues surrounding possible alignment
between XML Schema SCPs and QT SCPs.
***** XML Query WG - A-TAMPA-14 on Scott and Asir to see whether Schema's
SCDs could be integrated with query or adapted to Query in a reasonable way.
Scott and I have been working on this for some time. We have put together a
paper that describes two proposals for using schema component path (from
SCDs) in XQuery and XPath expressions. We request the XML Schema, XML Query
and XSL WGs to consider them. Special thanks are due to Mary Holstege (Mark
Logic) for reviewing this paper and providing us with detailed comments.
Paper is at,
https://www.w3.org/XML/Group/2004/03/scp-in-qt/
Note that we have read the discussion titled "ACTION A-MAND-12: element(N)
and friends" [1], but our proposal is not currently informed by it.  We
*think* that one of our proposals (we have two) and Michael Rys' proposal
are very similar, except that our proposal makes use of a subset of Schema
Component Designators.  Chalk this up to "great minds think alike", and, the
very least our proposal together with Michael's may be some validation that
the approach of dividing up simple element tests from potentially complex
schema component matching make sense.
[1] https://lists.w3.org/Archives/Member/w3c-xsl-query/2004Mar/0113.html

			
            
Overtaken by events. XQuery no longer has a syntax
for schema context paths.
		
         

				
            
Section 2.4.1.1 Sequence Type
				Matching, bullet 6 of "ElementTest"
				states: "element(P), where P is a
				valid schema context path beginning
				with a top-level element name or type
				name in the in-scope schema
				definitions and ending with an element
				name."
				
            

					
               
What is a "valid schema
	                          context path"? There *is* BNF for
	                          "SchemaContextPath", but no
	                          additional constraints. What happens
	                          if the leading QName is the name of
	                          a local element? And what are the
	                          rules for the SchemaContextStep
	                          (other than it is a QName)? The same
	                          comment applies to
	                          "AttributeTest".
					
               
If we read the BNF and the
	                          Formal Semantics properly, the
	                          schema context path cannot actually
	                          begin with a type name, but only
	                          with either an element name or with
	                          the keyword 'type(' followed by a
	                          type name and a closing ')' perhaps
	                          this description should be revised.
				
            
			
         

			
            
Overtaken by events. XQuery no longer has a syntax
for schema context paths.
		
         

				
            
Section 3.10.4 Constructor
				Functions states: "For each
				user-defined top-level atomic type T
				in the in-scope type definitions that
				is in a namespace, a constructor
				function is effectively defined."
				
            
Perhaps the word 'effectively' should be replaced with
    'implicitly'?
				
            
With the current wording, we found ourselves wondering: who
    defines this constructor function for user-defined top-level
    atomic types? Is it the user, is it magic, implementation defined
    or implementation dependent?
				
            
We found the sentence construction here a little
    difficult. Perhaps "A constructor function is implicitly defined
    for each ..." We also found "the in-scope type definitions that is
    in a namespace" a bit difficult to parse at first.
			
         

			
            
Done.
		
         

				
            
B.1 Type Promotion, bullet 2
				states: "A value of type xs:decimal
				(or any type derived by restriction
				from xs:decimal) can be promoted to
				either of the types xs:float or
				xs:double. The result is the value of
				the target type that is closest to the
				original value."
				
            
There should probably be an algorithm, or reference to an
    algorithm, that defines how to find the value that "is the closest
    to the original value".
			
         

			
            
I recommend rejection of this comment unless it can be
made more specific. It suggest that
an algorithm is needed to specify how to find the float or double value
that is closest to a given decimal value. I don't know of such an
algorithm, but I am open to suggestions.