Re: [xslt] Patch for xsl:sort lang support

[Daniel Veillard <veillard redhat com>]

On Wed, May 14, 2008 at 07:07:23PM +0200, Nick Wellnhofer wrote:
> 
> Attached is a patch that provides support for language dependent sorting 
> using the lang attribute of xsl:sort. The patch is against 
> libxslt-1.1.23, but it applies to 1.1.24 as well. See also 
> http://bugzilla.gnome.org/show_bug.cgi?id=152501
> 
> I tested the patch on several Linux distros and on Windows XP. It should 
> work on BSD-based systems, too. But maybe some smaller changes are 
> needed. On Linux I'm using strxfrm_l, so I changed configure to define 
> _GNU_SOURCE if glibc is detected. On Windows I'm using _wcsxfrm_l 
> because _strxfrm_l doesn't support UTF8. I put the bulk of the locale 
> handling code in a new file called xsltlocale.c.
> 
> I also included a test case, but that still needs work, because glibc 
> and MSVCRT sort order is different when using the French locale.

  okay, thanks a lot for doing this. This sounds a reasonnable solution
to that long-standing problem. The patch looks fine but there is just
one thing i would like to see changed: we should not use is*/tolower/toupper
in libxslt, because they are user locale dependant. Even if they are used
for test a priori in the ASCII range, there is a risk of confusion and
i would prefer to see the checks and normalizations done on the lang
attribute to use explicit 'a', 'z', 'A', 'Z' comparisons like in other
places of libxml2/libxslt.

> The changes to namespaces.c and transform.c have nothing to do with this 
> patch. They are because of bug #377440: 
> http://bugzilla.gnome.org/show_bug.cgi?id=377440

  Okay that need to be looked at separately. And hence as a separate patch.
I think the behaviour given in comment #2 is normal. If in the input stylesheet
you have an explicit namespace definition, and no exclude-result-prefixes,
you have to put them back in scope (and the reason is that the namespace 
prefix may be used inside attribute values or inside content, so it may
be used by the result iven if you can't guess that just by the analysis
of the output structure, it's bad design but legal).
  Apparently based on comment #3 the behaviour is actually correct for
both #2 and #3 examples.
  The question in the comment block of #4 is an open one. xmlSearchNsByHref
may be a bit too strong, and your suggestion on the default namespace sounds
more reasonnable to me than the full recursive search.

Daniel

-- 
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard      | virtualization library  http://libvirt.org/
veillard redhat com  | libxml GNOME XML XSLT toolkit  http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine  http://rpmfind.net/