You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@xalan.apache.org by "W. Eliot Kimber" <el...@isogen.com> on 2002/11/25 21:43:04 UTC

Implementing Customizable Collators for xsl:sort

I have a general requirement to be able to use locale and/or 
business-rule specific collators with xsl:sort (primarily for use in 
generation of back-of-the-book indexes in FO instances).

It appears from transformer/NodeSorter.java that this is not yet 
implemented. I'm trying to determine the level of effort to implement 
this, ideally in the same way that Saxon 7.x does (allowing you to 
delegate collation to a single object that handles one or more locales).

I've only had time to glance at the code but it didn't look like it 
would be as simple as just plugging in a different Collator implementation.

Has anybody done any sizing or design on this?

We want to be able to use XSLTC to compile our style sheets but we must 
be able to use custom collators.

Thanks,

Eliot
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139


Re: Implementing Customizable Collators for xsl:sort

Posted by "W. Eliot Kimber" <el...@isogen.com>.
W. Eliot Kimber wrote:

> This seems simple enough. Now the question I have is: how best to tell 
> the NodeSortRecord class about my Collator implementation?

I have modified the XSLTC code to add a CollatorFactory abstract class 
that has a getCollator() method, which is called by NodeSortRecord. 
getCollator takes language and country arguments (as for 
java.util.Locator's constructor). The default implementation simply 
constructs a Locale and then does Collator.getInstance(locale) to 
construct a locale-specific collator.

I use a property (org.apache.xml.xsltc.COLLATOR_FACTORY) to specify the 
class name of my own CollatorFactory implementation on the java command 
line, That class then goes through my configuration mechanism to get a 
collator for a particular locale.

This all works great.

What I haven't been able to figure out yet is how to get the lang and 
country attributes from xsl:sort to the NodeSortRecord's init() method 
in order to be able to construct the appropriate Collator object. Can 
someone help me unravel the many levels of indirection here?

Thanks,

Eliot
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139


Re: Implementing Customizable Collators for xsl:sort

Posted by "W. Eliot Kimber" <el...@isogen.com>.
Santiago Pericas-Geertsen wrote:
> Eliot:
> 
>  XSLTC's sorting code is in a different package:
> 
>  org.apache.xalan.xsltc.dom
> 
>  The class NodeSortRecord.java defines the following static variable:
> 
>     protected static Collator _collator = Collator.getInstance();
> 
>  Thus, it should be locale-aware (using the default locale). I haven't 
> thought much about this, but I suppose you could change this class to obtain 
> a collator via some other method (e.g. to provide a business-specific 
> collator). The rest of the code should work. 

This seems simple enough. Now the question I have is: how best to tell 
the NodeSortRecord class about my Collator implementation?

For my use case, I have generic code that constructs RuleBasedCollator 
instances dynamically using collator rule sets fetched from a separate 
configuration file. Thus, I can have one master Collator object that can 
serve any number of locales. The Saxon 6.x API requires me to have one 
Collator implementation per locale because it uses the locale value to 
look up the corresponding collator class. In Saxon 7, you can use a 
Saxon extension element (saxon:collation) to declare what objects should 
handle collation for which locales. I don't find either of these methods 
entirely satisfactory.

For my purposes, I think the easiest thing would be to supply a factory 
class that can take the attributes from xsl:sort (or the xsl:sort node 
itself) and return a Collator object. Setting this using a Java property 
would probably be good enough--a Saxon-style extension element would be 
more general but requires a lot more implementation effort.

I'll start by experimenting with using a Java property to specify a 
Collator factory and see how that feels.

Thanks,

Eliot
-- 
W. Eliot Kimber, eliot@isogen.com
Consultant, ISOGEN International

1016 La Posada Dr., Suite 240
Austin, TX  78752 Phone: 512.656.4139


Re: Implementing Customizable Collators for xsl:sort

Posted by Santiago Pericas-Geertsen <Sa...@sun.com>.
Eliot:

 XSLTC's sorting code is in a different package:

 org.apache.xalan.xsltc.dom

 The class NodeSortRecord.java defines the following static variable:

    protected static Collator _collator = Collator.getInstance();

 Thus, it should be locale-aware (using the default locale). I haven't 
thought much about this, but I suppose you could change this class to obtain 
a collator via some other method (e.g. to provide a business-specific 
collator). The rest of the code should work. 

 You can find additional information about XSLTC's xsl:sort implementation 
here:

http://xml.apache.org/xalan-j/xsltc/xsl_sort_design.html

 Hope this helps.

-- Santiago

On Monday 25 November 2002 15:43, W. Eliot Kimber wrote:
> I have a general requirement to be able to use locale and/or
> business-rule specific collators with xsl:sort (primarily for use in
> generation of back-of-the-book indexes in FO instances).
>
> It appears from transformer/NodeSorter.java that this is not yet
> implemented. I'm trying to determine the level of effort to implement
> this, ideally in the same way that Saxon 7.x does (allowing you to
> delegate collation to a single object that handles one or more locales).
>
> I've only had time to glance at the code but it didn't look like it
> would be as simple as just plugging in a different Collator implementation.
>
> Has anybody done any sizing or design on this?
>
> We want to be able to use XSLTC to compile our style sheets but we must
> be able to use custom collators.
>
> Thanks,
>
> Eliot