Saxon

Legacy ID: #3141649 Legacy Poster: W. Eliot Kimber (drmacro)

Most of my XSLT work revolves around transforms for generating XSL-FO for technical documents in many different national languages. As part of this locale-specific collation is of vital importance. With Saxon 6 I implemented a package that provides a generic collator factory driven by an external configuration system that is then integrated with Saxon 6 through its simple collator extension mechanism, which binds locale codes to collator classes. With XSLT 2 and Saxon 8 this approach isn't really appropriate. I've been thinking about how best to get what I want, which is the ability to easily extend Saxon 8's collators with my collator factory, which is currently bound to ICU4J, which provides good collators for most languages out of the box. Unfortunately, I see two problems with Saxon 8 as currently implemented: 1. Using the collator-URI-to-class method isn't ideal because it requires the XSLT to be processor-specific, which I'd rather avoid (even though in practice we will probably only ever use Saxon). That is, I'd rather have the locale-specific information on xsl:sort drive the selection of collators, with the binding between saxon and my collator factory handled outside the XSLT itself. As an alternative/refinement to this approach, I might use a collator URI to identify a general collator factory which then uses the other properties on xsl:sort to construct a specific comparator instance. But I would not want/be able to use collator URIs to point to locale-specific comparator instances, for the simple reason that a single XSLT processor might need to handle up to 50+ locales, often in the same input document (such as a mult-language "getting started" manual). Thus the condition that controls collator selection is the locale of the data being processed at that moment. Thus it makes more sense to delegate the details of collator selection to the collator factory rather than putting it into the XSLT. In addition, in my use cases, the person implementing the XSLT and the person managing the collator configurations are often two different people operating in different parts of the business process, so I need this separation of concerns to avoid unnecessary dependency on XSLT engineers. 2. Saxon's makeUsingProperties() method of the CollationFactory class won't work for ICU4J because ICU4J does not subclass java.text.RuleBasedCollator (but it does implement Comparator). This poses a problem for the posibility of replacing the built-in CollationFactory, since makeUsingProperties() is just what I want to do but I couldn't with ICU4J. Doh. I think the best approach would be as follows: 1. Revise the API for CollationFactory so that makeUsingProperties returns a Comparator, not a java.text.Collator. 2. Provide the run-time option of providing a CollationFactory implementation to replace the built-in CollationFactory. Given these two changes I could quickly adapt my existing ICU4J comparator factory (which underlies my current Saxon 6.2 support code) to work with Saxon 8. I'm happy to take a stab at these changes to the code but only if you think this approach is appropriate. Cheers, Eliot Kimber