This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: XPath 2.0: Collection-Valued Expressions (Was: Re: XQuery 1.0 and XPath 2.0 Functions and Operators Version 1.0)


Hi Mike,

> So there's likely to be syntax akin to XQuery's
>
> sum(for $i in //item return $i/@price * $i/@qty)
>
> We've also been toying with extending path expressions:
>
> sum(//item/(@price*@qty))
>
> but that causes backwards-compatibility difficulties that we haven't
> solved yet.

Thanks (and to Evan) for illustrating this syntax. It's made it clear
to me that for xf:sum(), xf:min(), xf:max() and xf:avg() you need a
two-step process - build the new sequence, then use that as the
argument to the function. If we're allowed to write our own functions
in XSLT 2.0 then we don't even need extended XPath expressions like
the above, aside from for concision/readability.

However, I don't think it's a viable approach for functions that need
to return the original values from the sequence, such as xf:sort() and
xf:value-distinct. Say you want to get the people with a unique
combination of first and last name. If you did:

  xf:value-distinct(person/(xf:concat(name/last, ',' name/first)))

then you would get the distinct combinations of the first and last
names, not the person elements. It's even more problematic with
xf:sort(), I think, but I find it hard to see the rationale behind
xf:sort() anyway given that we have xsl:sort in XSLT.

Would I be correct in thinking that the for/in/return above is a FLIR
expression and that the first syntax also introduces variable
assignment within XPath expressions? I share Dimitre's fear that XPath
2.0 will become a new programming language rather than a simple
expression syntax, especially where the functionality of the new
syntax mirrors something that already exists in XSLT 2.0. The second
syntax seems much more compatible with the division between XPath and
XSLT as I understand it.

> There is an aim to have a much more rigorous type system in XQuery
> and XPath 2.0 than is present in XPath 1.0, with much more scope for
> static type checking and optimization. Unfortunately this makes the
> addition of dynamic features to the language, such as the ability to
> create expressions from strings, rather more difficult. Although
> this feature is much wanted, there was an explicit decision not to
> include it in the XSLT 2.0 or XPath 2.0 requirements.

Oh, OK, I didn't realise. Guess it's our fault for letting the
multiple requests for dynamic evaluation and its inclusion in several
XSLT processors speak for themselves rather than making a formal noise
about the requirement. Can I request now that it's on the requirements
list for XPath 3.0 (assuming we get that far)?

On the subject of typing, when I first read the constructor/cast
operations described in the F&O WD, I was concerned that this would
mean we would have to write things like:

  cast as string(
    xf:floor(cast as double(
      xf:substring-after(cast as string(@price), '$'))))" />

rather than:

  string(floor(substring-after(@price, '$')))

Can you (or someone) reassure me that there will still be automatic
conversions between value types such that we won't have to be
casting/constructing specific data types all over the place?
  
Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]