[XPath] IBM-XP-115: XPath editorial comments

[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

Received on Tuesday, 17 February 2004 22:12:50 UTC