RE: [xml-dev] XPath 2.0 - how much of XQuery should it include?

Jeni Tennison wrote:

> 3. Mike's made an argument that the tools are easier to write 
> because they can focus on the optimisation of the XPath side 
> of the equation. But XQuery has a single approach:
> 
>   for $i in $list                 for $i in $list
>   return <foo />                  return 'foo'
> 
> Aside from syntax, I can't see a difference between these 
> queries and the XSLT:
> 
>   <xsl:for-each select="$list">   <xsl:for-each select="$list">
>     <foo />                         <xsl:item select="'foo'" />
>   </xsl:for-each>                 </xsl:for-each>
> 
> Perhaps XQuery implementers have some ideas about telling the 
> difference that could help.
>   

The <xsl:item> idea is not unattractive, and we haven't ruled it out. But I
think if we go this way it will tend to increase the amount of duplication
between the two languages rather than decrease it. If we had full
composability between XSLT and XPath expressions then we could put the
functionality where we liked. We haven't; and functionality that we put into
XPath is available in a wider variety of contexts than the same
functionality in XSLT. (Including to XPath hosts other than XSLT of course).
We all know the limitations of keys and sort keys having to be defined as a
single XPath expression. I don't think we can remove sequence construction
and mapping from XPath, so I would rather not duplicate them in XSLT.

I also want to keep the idea that an XSLT stylesheet is a template for the
result document. Literal result elements and text nodes in the stylesheet
are copied directly to the result; instructions generate groups of nodes in
the result. I thinnk that's a useful metaphor.

Michael Kay

Received on Tuesday, 14 May 2002 11:41:28 UTC