RE: Comments on XPath (30th April)

Useful comments, David.

> 2.3.2.2 Dereferences
> 
>   Either this should be removed or there needs to be a lot more
>   justification placed in the document as to why it should be 
> included.

The justification that's used is that the type of the result can be
determined statically, which it can't for id().
> 
> 
> 2.6.1 Value Comparisons
> 
>   these are useful for defining the semantics of = and friends but it
>   isn't clear they are really useful as user level syntax.

I think the justification is that using "eq" tells the optimizer it can use
access paths (e.g. indexes) that don't support the existential semantics.
But I tend to agree with you, people probably aren't going to use these
operators so there's not much point providing them.
> 
> 2.6.4 Order Comparisons
> 
>   It is not at all clear these are desirable in XPath for example
> 
>   //purchase[parcel="28-451"] << //sale[parcel="33-870"]
> 
>   Could more simply be expressed as (the boolean value of)
> 
>   //purchase[parcel="28-451"]/following::sale[parcel="33-870"]
> 
It doesn't actually mean quite the same; but I must admit I have difficulty
finding convincing use cases for these operators.

> 
> 
> 2.7 Logical Expressions
> 
> The first step in evaluating a logical expression is to 
> reduce each of its operands to an effective boolean value 
> 
>   This is a horrible incompatibility with XPath1 which 
> explictly states
>   that the second argument is not evaluated if the result can be
>   determined from the first. 

A difficult one, this. Database systems do need to optimize boolean
predicates by using indexes, and that makes it very hard to support the
XPath 1.0 semantics. I don't much like the alternative of introducing a
second pair of operators. I'm more inclined to solve it by having a rule at
the XSLT level, whereby XSLT constrains these XPath operators to behave in
the XPath 1.0 manner (which conforms to one of the options permitted by
XPath 2.0). Not nice.

> 
> 2.8 For Expressions
> 
>   The fact that for expressions mean that it possible in XPath to bind
>   variables to items but not to sequences is a very strange state of
>   affairs.

You think we should allow "let" in XPath? The trouble is, we can expand
XPath or contract it, and whatever we do, we will upset someone.

> Also the fact that there is no version of for that 
> moves the context item (and so .) is going to lead to endless user
confusion.

We've put this on the agenda for discussion once again, because the request
comes up repeatedly. The three options are:

* provide a simple (context-based) FOR expression only
* provide a full FOR expression with range variables
* provide both

> 
>   However to comment on the specifics in the current draft:
> 
> A for clause associates one or more variables with 
> expressions, creating tuples of variable bindings drawn from 
> the Cartesian product of the sequences of values  

You're not the only person who's noticed that a simpler formulation is
possible. 
> 
> 
> [6]    QuantifiedExpr    ::=    ("some" "$" |  "every" "$") 
> QName "in" Expr 
>                                    ("," Variable "in" Expr)* 
> "satisfies"  Expr 
> 
>    Why is the first Variable split into $Qname and not the second?

We're trying to present a syntax that's parseable without lookahead, under
certain constraints. "some $" and "every $" turn out to be "compound tokens"
in this syntax, where "some" and "every" can only be distinguished from
QNames by the presence of the following "$". It's messy and we're looking at
ways of presenting it better.
> 
> 
> [20]    CastExpr    ::=    ("cast" "as" |  "treat" "as" |  
> "assert" "as")  
> 
> 
>   I'm glad Mike just indicated  in a reply to my comments on F&O that
>   there will be some rationalisation here, and in the type constructor
>   functions. (Personally I'd prefer to see none of these in 
> XPath, but I assume that's too much to ask.)
> 
It's not necessarily too much to ask. We're certainly looking to make as
much simplification as we can (and no more).
> 
> 
> 2.12 Validate Expressions
> 
>   I do not think that this should be in XPath at all.

I agree.

Michael Kay

Received on Tuesday, 21 May 2002 13:25:05 UTC