- From: Tony Graham <Tony.Graham@MenteithConsulting.com>
- Date: Mon, 28 May 2007 12:07:31 +0100
- To: public-qt-comments@w3.org
On Sun, May 27 2007 23:23:42 +0100, Liam Quin wrote: > On Sun, May 27, 2007 at 08:59:05PM +0100, Tony Graham wrote: >> Section 10, "Sorting", of XSLT 1.0 [1] includes: >> >> if no lang value is specified, the language should be determined >> from the system environment >> >> Section 13.1.3 "Sorting Using Collations", of XSLT 2.0 [2] includes: >> >> If none of the collation, lang or case-order attributes is present, >> the collation is chosen in an implementation-defined way. >> >> This difference in expectation in the absence of the 'lang' attribute > > I see one main difference between > determined from the system environment > and > chosen in an implementation-defined way > which is that the second wording requires the implementation to > document how it chooses the collation in this case. > > The older wording is also much looser -- SHOULD be determined -- > so that an implementation could have had a hard-wired default if > it so chose, and now, if it has a hard-wired default, it still can, > but must say so. I'm not attempting to change anything about the normative text of either version of XSLT. I suggest that there are a lot of XSLT 1.0 stylesheets that work correctly now because the language used when sorting is being taken from the system environment by their XSLT 1.0 processor. For example, searching the XSL-List archive for 'xsl:sort' and 'lang' on the same line [1] gives matches from 31 messages though there are rather more than 31 messages in the archive that include 'xsl:sort' without 'lang'. I was therefore asking whether the possibility that the sort order could change when using an XSLT 1.0 stylesheet with an XSLT 2.0 processor should be documented in Appendix J. >> (which recently caused unexpected results for me) > How did it cause unexpected results? I added an XSLT 2.0 stylesheet to a sequence of XSLT 1.0 stylesheets (since the task, and the new stylesheet, was made much simpler with regex). The system worked fine when everything was run using an XSLT 2.0 processor, but my test data had used all lowercase names (which was usual in this application). When my client first used data with a mixture of uppercase and lowercase names, part of the result from the sequence of stylesheets was in an unexpected order. After verifying that the new stylesheet was working correctly, I then had to find where the change was being introduced. The change was introduced because an existing XSLT 1.0 stylesheet was using xsl:sort without specifying the 'lang' attribute. I would like to think that I would have found the cause sooner if the different expectations in the absence of 'lang' had been documented in Appendix J so I could have made the connection through a feat of memory rather than a feat of detective work. (Incidentally, the client had forgotten that the xsl:sort was in their existing stylesheet since that part of its input data was ordinarily in the correct order anyway, but I now have to check the other xsl:sort in their stylesheets for XSLT 2.0 surprise potential.) Regards, Tony Graham. ====================================================================== Tony.Graham@MenteithConsulting.com http://www.menteithconsulting.com Menteith Consulting Ltd Registered in Ireland - No. 428599 Registered Office: 13 Kelly's Bay Beach, Skerries, Co. Dublin, Ireland ---------------------------------------------------------------------- Menteith Consulting -- Understanding markup ====================================================================== [1] http://www.biglist.com/cgi-bin/wilma/wilma_glimpse/xsl-list?query=xsl%3Asort%3Blang%3D&Search=Search&lineonly=on&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles
Received on Monday, 28 May 2007 11:07:41 UTC