XPath questions: QName Reduction and ".." Recursion

Hi,

I read with much interest the XPath v1.0 Working Draft 13 Aug 1999,
and have a few questions:


(1) ".." Recursion

For this AbbreviatedStep, what is the semantics for a repeated
use of this parent operator such that the parent of the root 
of document (I'll just call it the "root" hereon) is attempted 
to be evaluated?  Ie. what is the result of "/../../..", for
example?

Unix path-style forces the parent of root to be short-circuited 
to root itself, so such evaluation results in the root itself.
Alternatively, we could return an empty nodeset as a result of
this parent-of-root evaluation.  Another alternative is to 
signal an error, like MSDOS path-style (not really preferred).  
Current spec doesn't seem to treat this case in any special way,
so that the result of the above example would return an empty
nodeset.

Perhaps it can be clarified further on this.



(2) QName Reduction

There appears to be a reduction-reduction conflict on the PathExpr
rule when a QName '(' ')' token sequence is found in the input 
XPath stream.  If we reduce the QName token as a WildcardName, 
we can get
	QName -> WildcardName -> NodeTest -> AbbreviatedBasis
		-> Basis -> Step -> RelativeLocationPath 
		-> LocationPath -> PathExpr
(and thus cause subsequent syntax error due to the presence of
the token sequence '(' ')').

On the other hand, if we reduce the QName as a FunctionName, we
get
	QName -> FunctionName '(' ')' -> FunctionCall 
		-> PrimaryExpr -> FilterExpr -> PathExpr

One example is this:
	child::para[position()=1]

The "position" is a perfectly legal QName, and at the same time,
it is also a FunctionName with defined functional semantics
(as opposed to a syntactic function such as node(), comment()
and text()).  The intended evaluation sequence should be to
absorb the parentheses to give a FunctionCall.  Thus, by 
giving priority to reduce to FunctionName over LocationPath,
the right reduction sequence occurs.

My suggestion is that perhaps it would be less confusing to
implementors and make the intended meaning clearer by 
specifying that priority should be given to FilterExpr reduction
over LocationPath in PathExpr.



(3) Function name space

Related to (2) above, an xpath such as "position" will be
evaluated to select the child nodes of the context node
whose names are "position", and not cause an error because
it is also a specification-defined function name but the
required parentheses are missing.  Is this the intended meaning?



(4) VariableReference

The spec has described how VariableReferences are referenced,
but does not suggest whether all these variables are globals,
or lexically scoped in certain ways that may be dependent on 
their position of definition.  For the latter, some implication
on the current node and context node may exist, since a 
VariableReference under a certain current node may give a value
while the same VariableReference when evaluated under a difference
current node may give an error.



(5) Empty VariableReference

Para 3.1 says "it is an error if the variable is not bound to
any value in the set of variable bindings in the expression 
context".  Is there any reason why this has to be the default
behavior?   

How about making it silent on error and give a default number
value as 0?  The number 0 is invariant under the transformations
described by string(), boolean() and number(), so I'd say it
serves as a good default value.  Making references to non-
existent variables a non-error-generating event seems to me
more in line with the common expectations and behavior of 
most scripting languages.  



Best Regards,

Chee-Kai Chin
SoftML Pte Ltd

Received on Thursday, 19 August 1999 01:45:39 UTC