W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2005

[Bug 1308] proposal: merge xsl:perform-sort and xsl:sequence

From: <bugzilla@wiggum.w3.org>
Date: Sat, 14 May 2005 23:37:30 +0000
To: public-qt-comments@w3.org
Cc:
Message-Id: <E1DX6CI-0005kg-Ut@wiggum.w3.org>

http://www.w3.org/Bugs/Public/show_bug.cgi?id=1308





------- Additional Comments From davidc@nag.co.uk  2005-05-14 23:37 -------
> 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.
Received on Saturday, 14 May 2005 23:37:34 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:57:05 UTC