Re: [XSLTerrata] Undocumented xsl:sort/@lang incompatibility?

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