Santiago Pericas-Geertsen wrote:
Eliot:This seems simple enough. Now the question I have is: how best to tell the NodeSortRecord class about my Collator implementation?
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.
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, [EMAIL PROTECTED]
Consultant, ISOGEN International
1016 La Posada Dr., Suite 240
Austin, TX 78752 Phone: 512.656.4139
