This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
As far as I can tell, an xsl:perform-sort is identical in all respects to xsl:sequence except that in perform-sort (at least one) xsl:sort is mandatory and in xsl:sequence xsl:sort is not allowed. I would propose to remove xsl:perform-sort from the specification and allow xsl:sort as a child of xsl:sequence (so that the semantics of xsl:sequence become those currently used for xsl:perform-sort if it has an xsl:sort child) This simplifies the specification (one less element) and makes the use of xsl:sort more consistent. In other cases xsl:sort is optionally allowed as a child of the containing instruction (eg xsl:for-each) with sorting occurring if it is present, it is only in this case that there are two separate instructions, one requiring a sort specification and the other not allowing it. David
Thanks for the suggestion, the WG will look at it. It's a cosmetic change, but personally I'm reasonably sympathetic to it. xsl:perform-sort is proving to be one of the less-frequently-used features of 2.0, and perhaps if it's combined with xsl:sequence more people will notice its existence. Michael Kay (personal response)
We discussed this on 12 May without coming to a firm conclusion: the outstanding technical question was what we should do about an xsl:perform-sort instruction containing a sequence constructor (which is allowed by xsl:perform-sort but not by xsl:sequence). I suggested during the telcon that <xsl:perform-sort> <xsl:sort select="..."/> <instructions>... </xsl:perform-sort> is equivalent to <xsl:for-each select="."> <xsl:sort select="..."/> <instructions>... </xsl:perform-sort> but I was wrong: the second case computes sort keys from the input sequence (.), not from the output sequence. I think my instinct now is to leave it alone. It ain't broke, and fixing things that ain't broke during the end game always risks introducing bugs. Michael Kay
> It ain't broke, and fixing things > that ain't broke during the end game always risks introducing bugs. As a general rule there is a lot to be said for that, and if that ends up being the offical WG posssition, I won't object here (I may grumble a bit on xsl-list but that's a different thing...) However while it isn't broke, the current spec just feels wrong to me. I expected to be able to use xsl:sort with xsl:sequence and was surprised when I couldn't and surprised to find xsl:perform sort which had somehow escaped my attention before. However I know it's getting late for such comments. My "safe" plan would be a) allow xsl:perform-sort to have no xsl:sort children with the effect being that it returns the specified sequence in the input order. b) remove the existing xsl:sequence c) rename xsl:perform-sort to xsl:sequence d) fix up references to perform-sort and error codes to take account of the change. If that plan is workable then it looks fairly safe to me. (But I have not done a full analysis of the spec changes and code changes to implementation that would result) If there are hidden (or not so hidden) problems that mean that doing this merge means that you need to do more careful surgery and design of new instruction semantics, then reluctantly I'd agree that it might be getting late for new features.
David, thanks again for your comment and suggestions. The WG considered this very carefully and although there was sympathy for it we concluded that we did not want to make an non-essential change at this point in the process. Please let us know if you are not willing to accept this conclusion. If we do not hear from you in one week we will deem this comment closed.
As I indicated earlier, I half expected this outcome. I'm closing the report with no formal objection, but I may object over a beer if I catch any of the WG in a pub...