SAXONICA

Saxon Documentation
Full Contents
About Saxon
Changes in this Release
Conditions of Use
Using XSLT 2.0
Using XQuery
Handling Source Documents
XML Schema Processing
XPath API for Java
Saxon on .NET
Extensibility
Saxon Extensions
| Introduction
| EXSLT Extensions
| Extension attributes (XSLT only)
| Additional serialization parameters
| Extension functions
» | Extension instructions
Sample Saxon Applications
The Saxon SQL Extension
XSLT Elements
XPath 2.0 Expression Syntax
Function Library
Standards Conformance

# saxon:collation

saxon:collation is deprecated. It is also possible to specify a collation directly by using a URI of the form `http://saxon.sf.net/collation?keyword=value;keyword=value;...`. For details see Collations.

The `saxon:collation` element is a top-level element used to define collating sequences that may be used in sort keys and in functions such as `compare()`.

The collation name is a URI , and is defined in the mandatory `name` attribute. This must be a valid URI. If it is a relative URI, it is interpreted as being relative to the base URI of the `saxon:collation` element itself.

The default attribute was used in earlier Saxon releases to identify the default collation. From Saxon 8.8 this attribute is ignored, with a warning. To specify the default collation, use the standard `[xsl:]default-collation` attribute.

The other attributes control how the collation is defined. These attributes have the same effect as the corresponding query parameters in a URI starting with `http://saxon.sf.net/collation?`, and are described here.

Specifically, these attributes are:

attribute | values | effect
class | fully-qualified Java class name of a class that implements `java.util.Comparator`. | This parameter should not be combined with any other parameter. An instance of the requested class is created, and is used to perform the comparisons. Note that if the collation is to be used in functions such as contains() and starts-with(), this class must also be a `java.text.RuleBasedCollator`. This approach allows a user-defined collation to be implemented in Java. This option is also available on the .NET platform, but the class must implement the Java interface java.util.Comparator.
rules | details of the ordering required, using the syntax of the Java `RuleBasedCollator` | This defines exactly how individual characters are collated. This option is also available on the .NET platform, and if used will select a collation provided using the GNU Classpath implementation of `RuleBasedCollator`. At the time of writing, this is not 100% compatible with the Sun JDK implementation.
lang | any value allowed for xml:lang, for example `en-US` for US English | This is used to find the collation appropriate to a Java locale or .NET culture. The collation may be further tailored using the parameters described below.
ignore-case | yes, no | Indicates whether the upper and lower case letters are considered equivalent. Note that even when ignore-case is set to "no", case is less significant than the actual letter value, so that "XPath" and "Xpath" will appear next to each other in the sorted sequence. On the Java platform, setting ignore-case sets the collation strength to secondary.
ignore-modifiers | yes, no | Indicates whether non-spacing combining characters (such as accents and diacritical marks) are considered significant. Note that even when ignore-modifiers is set to "no", modifiers are less significant than the actual letter value, so that "Hofen" and "Höfen" will appear next to each other in the sorted sequence. On the Java platform, setting ignore-case sets the collation strength to primary.
ignore-symbols | yes, no | Indicates whether symbols such as whitespace characters and punctuation marks are to be ignored. This option currently has no effect on the Java platform, where such symbols are in most cases ignored by default.
ignore-width | yes, no | Indicates whether characters that differ only in width should be considered equivalent. On the Java platform, setting ignore-width sets the collation strength to tertiary.
strength | primary, secondary, tertiary, or identical | Indicates the differences that are considered significant when comparing two strings. A/B is a primary difference; A/a is a secondary difference; a/ä is a tertiary difference (though this varies by language). So if strength=primary then A=a is true; with strength=secondary then A=a is false but a=ä is true; with strength=tertiary then a=ä is false. This option should not be combined with the ignore-XXX options. The setting "primary" is equivalent to ignoring case, modifiers, and width; "secondary" is equivalent to ignoring case and width; "tertiary" ignores width only; and "identical" ignores nothing.
decomposition | none, standard, full | Indicates how the collator handles Unicode composed characters. See the JDK documentation for details. This option is ignored on the .NET platform.
alphanumeric | yes, no | If set to yes, the string is split into a sequence of alphabetic and numeric parts (a numeric part is any consecutive sequence of ASCII digits; anything else is considered alphabetic). Eacn numeric part is considered to be preceded by an alphabetic part even if it is zero-length. The parts are then compared pairwise: alphabetic parts using the collation implied by the other query parameters, numeric parts using their numeric value. The result is that, for example, AD985 collates before AD1066. Note that an alphanumeric collation cannot be used in conjunction with functions such as contains() and substring-before().
case-order | upper-first, lower-first | Indicates whether upper case letters collate before or after lower case letters.

Sorting and comparison according to Unicode codepoints can be achieved by setting up a collator as `<saxon:collation name="unicode" class="net.sf.saxon.sort.CodepointCollator"/>`

Note that a stylesheet containing a `saxon:collation` declaration cannot be compiled at this release, because the underlying Java classes are not serializable.

Next