RE: Comments on XPath 2.0 specification

> > There are many good reasons, I think, for not adopting the 
> "dot product"
> > semantics you suggest. One of them is simply that it's 
> incompatible with
> > XPath 1.0.
> 
> 
> As is the current 2.0 proposal (that this is now an error).  
> Admittedly, 
> that's safer than changing its value without issuing an error.

I'm afraid we've made the spec very cryptic in this area and you can be
excused for not following its contorted logic. What we say is that
multiplying two sequences is a type error. Elsewhere we say that the context
can define how type errors should be handled, and one of the permitted
policies (which we expect to be used in an environment where XPath 1.0
compatibility is important) is to convert the sequence to a number by taking
its first item. (Or at any rate, that's the intent, there may be minor bugs
in the detail of how this is currently specified).

The general idea here is to allow two modes for running XPath: a mode where
the type checking is fairly strict, and a mode where the system tries
wherever possible to convert the supplied value to the required type.
> 
> Still, compare
> 
> 	sum(//item/quantity * //item/USPrice)
> 
> and
> 
> 	sum(for $item in //item return($item/quantity*$item/USPrice))
> 
> (Assuming that's correct.  I'm presuming the bound variable does not 
> become the focus of the return expression, since I can't find 
> language 
> in the spec saying it does.)
> 
> Which is simpler and eaiser to use?

We have debated (and may well debate again) the possible provision of a
variant of the "for" expression that uses the context item instead of an
explicit range variable. This would allow syntax such as

    sum(for //item return quantity * USPrice)

The main reason we excluded this from the current draft is that there are
technical problems with the parsing (because of the need to avoid reserved
words). But personally, I would like to see such a construct. 

There's another thread on this list that suggests we should adopt the syntax
of higher-order functions, for example

   sum ( map( //item, quantity * USPrice ))

> 
> By the way, I presume someone has noticed how much this looks like an 
> SQL select, and suggested something akin to
> 
> 		sum(select quantity*price from //item)
> 
> 
> (Here the value of "from" *does* become the focus.)
> 
Yes indeed. It does suggest to me the idea that

    sum(quantity * price from //item)

might be an acceptable (and parseable) syntax.

Mike Kay

Received on Wednesday, 23 January 2002 14:40:02 UTC