[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Re: . in for

Subject: Re: Re: . in for
From: Jeni Tennison <jeni@xxxxxxxxxxxxxxxx>
Date: Sun, 6 Jan 2002 12:49:38 +0000
xpath sort function
Mike Kay wrote:
>I wrote:
>>  - I think that users of XSLT will find it confusing that they have
>>    two choices for iterating over a sequence - a for expression or an
>>    xsl:for-each instruction - and will unadvisedly choose to use a for
>>    expression, which is not as extensible as xsl:for-each (you can't
>>    add sorting, can't assign variables, can't change to applying
>>    templates rather than iterating if you start with a for
>>    expression).
>
> Yes, it will be a bit confusing that there are two ways of doing it.
> But I don't think you're right about the limitations of the XPath
> "for" expression. You can do sorting using the new sort() function
> defined in XSLT 2.0, and you can switch back into XSLT (e.g. to do
> apply-templates) by calling a stylesheet function.

I'd missed the sort() function (been too busy looking at the XPath WDs
to look at the XSLT WD in any great detail). Even so, I note that the
sort() function cannot do everything that xsl:sort does. Specifically,
you cannot use variables from the context in which the sort is
used within the sort key.

For example, given that $rows contains a set of nodes to be sorted and
$sort-by is a local variable holding the name of one of its children,
and $sort-order holds the order of the sort, how can you use sort() to
sort the $rows according to the child whose name is specified by the
$sort-by variable? The XSLT way is:

  <xsl:for-each select="$rows">
    <xsl:sort select="*[name() = $sort-by]" order="{$sort-order}" />
    ...
  </xsl:for-each>

I can't see a way aside from creating N separate sort keys where N is
the result of multiplying the number of possible child elements of the
$rows by 2 (one sort specification for ascending, another for
descending). While you *can* do that, I think it's inadvisable when
the XSLT way is that much simpler, and I think that this demonstrates
my statement about the lack of extensibility of the for expression.

In addition, the fact that sort keys might be used within various
expressions leads to maintainability problems - changing the sort key
(e.g. adding extra sorts) to suit one expression may lead to
unexpected changes elsewhere as well.


The picture that Mike paints here is of an XSLT that is basically a
language for defining functions, defining sort keys, defining decimal
formats, defining variables and so on. XPath becomes the main driving
force of the transformation, with XSLT simply backing it up.

Rather than:

  <xsl:for-each select="row">
    <xsl:sort select="@cust" />
    <row num="{position()}">...</row>
  </xsl:for-each>

we shall be able to do:

  <xsl:variable name="rows" select="sort(row, 'my:cust-sort')" />
  <xsl:copy-of
    select="for $i in (1 to count($rows))
            return my:create-row($rows[$i], $i)" />

with XSLT handily providing a couple of definitions:

<xsl:sort-key name="my:cust-sort">
  <xsl:sort select="@cust" />
</xsl:sort-key>

<xsl:function name="my:create-row">
  <xsl:param name="row" type="element row" />
  <xsl:param name="position" type="xs:integer" />
  <xsl:result>
    <row num="{$position}">...</row>
  </xsl:result>
</xsl:function>

This is certainly a sea-change in the relationship between XSLT and
XPath. While it's an interesting one, I do wonder why it's a necessary
one -- what does this style enable us to achieve that we cannot
achieve with the 'traditional' style?

My fear is that this style is being introduced simply because it is
close to the style that XQuery uses, whether due to comments from the
XQuery folk on the limitations of XSLT, or due to XSLT folk wanting to
demonstrate that XSLT can do all that XQuery can (and in the same
way!), rather than because of any demand from XSLT users. In my
opinion, we should revel in the differences between XSLT and XQuery,
and put more space between them, not seek to combine them, or we will
end up with two conjoined languages that are both unusable because of
the limitations imposed by the other.

Cheers,

Jeni

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


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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.