XSL Transformations (XSLT) Version 4.0

2.3.1 Information needed for Static Analysis

The following information is needed prior to static analysis of a package:

• The location of the package manifest, or in the absence of a package manifest, the stylesheet module that is to act as the principal stylesheet module of the package. The complete package is assembled by recursively expanding the xsl:import and xsl:include declarations in the principal stylesheet module, as described in 3.11.2 Stylesheet Inclusion3.10.2 Stylesheet Inclusion3.11.23.10.2 Stylesheet Inclusion and 3.11.3 Stylesheet Import3.10.3 Stylesheet Import3.11.33.10.3 Stylesheet Import.

• Information about the packages referenced from this package using xsl:use-package declarations. The information needed will include the names and signatures of public components exported by the referenced package.

• A set (possibly empty) of values for static parameters (see 9.5 Global Variables and Parameters). These values are available for use within static expressions (notably in [xsl:]use-when expressions and shadow attributes) as well as non-static expressions in the stylesheet. As a minimum, values must be supplied for any static parameters declared with the attribute required="yes".

Conceptually, the output of the static analysis of a package is an object which might be referred to (without constraining the implementation) as a compiled package. Prior to dynamic evaluation, all the compiled packages needed for execution must be checked for consistency, and component references must be resolved. This process may be referred to, again without constraining the implementation, as linking.

2.3.3 Apply-Templates Invocation

[Definition: A stylesheet may be evaluated by supplying a value to be processed, together with an initial mode. The value (which can be any sequence of items) is referred to as the initial match selection. The processing then corresponds to the effect of the xsl:apply-templates instruction.]

The initial match selection will often be a single document node, traditionally called the source document of the transformation; but in general, it can be any sequence. If the initial match selection is an empty sequence, the result of the transformation will be empty, since no template rules are evaluated.

Processing proceeds by finding the template rules that match the items in the initial match selection, and evaluating these template rules with a focus based on the initial match selection. The template rules are evaluated in final output state.

The following information is needed when dynamic evaluation is to start with a template rule:

• The initial match selection. An API that chooses to maintain compatibility with previous versions of this specification should allow a method of invocation in which a singleton node is provided, which is then used in two ways: the node itself acts as the initial match selection, and the root node of the containing tree acts as the global context item.

• Optionally, an initial mode.

  [Definition: The initial mode is the mode used to select template rules for processing items in the initial match selection when apply-templates invocation is used to initiate a transformation.]

  In searching for the template rule that best matches the items in the initial match selection, the processor considers only those rules that apply to the initial mode.

  If no initial mode is supplied explicitly, then the initial mode is that named in the default-mode attribute of the (explicit or implicit) xsl:package element of the top-level package or in the absence of such an attribute, the unnamed mode.

  [ERR XTDE0044] It is a dynamic error if the invocation of the stylesheet specifies an initial mode when no initial match selection is supplied (either explicitly, or defaulted to the global context item).

  A (named or unnamed) modeM is eligible as an initial mode if one of the following conditions applies, where P is the top-level package of the stylesheet:

  1. M is explicitly declared in an xsl:mode declaration within P, and has public or finalvisibility (either by virtue of its visibility attribute, or by virtue of an xsl:expose declaration).

  2. M is the unnamed mode.

  3. M is named in the default-mode attribute of the (explicit or implicit) xsl:package element of P.

  4. M is declared in a package used by P, and is given public or finalvisibility in P by means of an xsl:accept declaration.

  5. The effective value of the declared-modes attribute of the explicit or implicit xsl:package element of P is no, and M appears as a mode-name in the mode attribute of a template rule declared within P.

  [ERR XTDE0045] It is a dynamic error if the invocation of the stylesheet specifies an initial mode and the specified mode is not eligible as an initial mode (as defined above).

• Parameters, which will be passed to the template rules used to process items in the input sequence. The parameters consist of two sets of (QName, value) pairs, one set for tunnel parameters and one for non-tunnel parameters, in which the QName identifies the name of a parameter and the value provides the value of the parameter. Either or both sets of parameters may be empty. The effect is the same as when a template is invoked using xsl:apply-templates with an xsl:with-param child specifying tunnel="yes" or tunnel="no" as appropriate. If a parameter is supplied that is not declared or used, the value is simply ignored. These parameters are not used to set stylesheet parameters.

  A supplied value is converted if necessary to the declared type of the template parameter using the coercion rules.

• Details of how the result of the initial template is to be returned. For details, see 2.3.6 Post-processing the Raw Result

The raw result of the invocation is the result of processing the supplied input sequence as if by a call on xsl:apply-templates in the specified mode: specifically, each item in the input sequence is processed by selecting and evaluating the best matching template rule, and converting the result (if necessary) to the type declared in the as attribute of that template using the coercion rules; and the results of processing each item are then concatenated into a single sequence, respecting the order of items in the input sequence.

It is a dynamic error[see ERR XTDE0700] if the template rule selected for processing any item in the initial match selection defines a template parameter that specifies required="yes" and no value is supplied for that parameter.

2.3.4 Call-Template Invocation

[Definition: A stylesheet may be evaluated by selecting a named template to be evaluated; this is referred to as the initial named template.] The effect is analogous to the effect of executing an xsl:call-template instruction. The following information is needed in this case:

• Optionally, the name of the initial named template which is to be executed as the entry point to the transformation. If no template name is supplied, the default template name is xsl:initial-template. The selected template must exist within the stylesheet.

• Optionally, a context item for evaluation of this named template, defaulting to the global context item if it exists. This is constrained by any xsl:context-item element appearing within the selected xsl:template element. The initial named template is evaluated with a singleton focus based on this context item if it exists, or with an absent focus otherwise.

  Note:

  The context item for evaluation of the named template must be either a single item or absent; it cannot be an arbitrary value.

• Parameters, which will be passed to the selected template rule. The parameters consist of two sets of (QName, value) pairs, one set for tunnel parameters and one for non-tunnel parameters, in which the QName identifies the name of a parameter and the value provides the value of the parameter. Either or both sets of parameters may be empty. The effect is the same as when a template is invoked using xsl:call-template with an xsl:with-param child specifying tunnel="yes" or tunnel="no" as appropriate. If a parameter is supplied that is not declared or used, the value is simply ignored. These parameters are not used to set stylesheet parameters.

  A supplied value is converted if necessary to the declared type of the template parameter using the coercion rules.

• Details of how the result of the initial named template is to be returned. For details, see 2.3.6 Post-processing the Raw Result

The raw result of the invocation is the result of evaluating the initial named template, after conversion of the result to the type declared in the as attribute of that template using the coercion rules, if such conversion is necessary.

The initial named template is evaluated in final output state.

[ERR XTDE0040] It is a dynamic error if the invocation of the stylesheet specifies a template name that does not match the expanded QName of a named template defined in the stylesheet, whose visibility is public or final.

It is a dynamic error[see ERR XTDE0700] if the initial named template, or any of the template rules invoked to process items in the initial match selection, defines a template parameter that specifies required="yes" and no value is supplied for that parameter.

3.1.1 XSLT Namespace

[Definition: The XSLT namespace has the URI http://www.w3.org/1999/XSL/Transform. It is used to identify elements, attributes, and other names that have a special meaning defined in this specification.]

XSLT processorsmust use the XML namespaces mechanism [Namespaces in XML] to recognize elements and attributes from this namespace. Elements from the XSLT namespace are recognized only in the stylesheet and not in the source document. The complete list of XSLT-defined elements is specified in C Element Syntax Summary. Implementationsmust not extend the XSLT namespace with additional elements or attributes. Instead, any extension must be in a separate namespace. Any namespace that is used for additional instruction elements must be identified by means of the extension instruction mechanism specified in 24.2 Extension Instructions24.2 Extension Instructions.XSLT processorsmust use the XML namespaces mechanism [Namespaces in XML] to recognize elements and attributes from this namespace. Elements from the XSLT namespace are recognized only in the stylesheet and not in the source document. The complete list of XSLT-defined elements is specified in C Element Syntax Summary. Implementationsmust not extend the XSLT namespace with additional elements or attributes. Instead, any extension must be in a separate namespace. Any namespace that is used for additional instruction elements must be identified by means of the extension instruction mechanism specified in 24.3 Extension Instructions24.3 Extension Instructions.XSLT processorsmust use the XML namespaces mechanism [Namespaces in XML] to recognize elements and attributes from this namespace. Elements from the XSLT namespace are recognized only in the stylesheet and not in the source document. The complete list of XSLT-defined elements is specified in C Element Syntax Summary. Implementationsmust not extend the XSLT namespace with additional elements or attributes. Instead, any extension must be in a separate namespace. Any namespace that is used for additional instruction elements must be identified by means of the extension instruction mechanism specified in 24.2 Extension Instructions24.3 Extension Instructions24.224.3 Extension Instructions.

Except where the rules for forwards compatible behavior dictate otherwise, it is a static error for any element in the stylesheet to be in the XSLT namespace unless it is an element defined in this specification [see ERR XTSE0010].

This specification uses a prefix of xsl: for referring to elements in the XSLT namespace. However, XSLT stylesheets are free to use any prefix, provided that there is a namespace declaration that binds the prefix to the URI of the XSLT namespace.

3.5.13.4.1 Versions of a Package

If a package has a version number, the version number must conform to the grammar:

        PackageVersion   ::= NumericPart ( "-" NamePart )?
        NumericPart      ::= IntegerLiteral ( "." IntegerLiteral )*
        NamePart         ::= NCName

Here IntegerLiteral^XP and NCName are as defined in the XPath 4.0 grammar productions of the same name (including rules on limits). Leading and trailing whitespace is ignored; no other whitespace is allowed.

Examples of valid version numbers are 2.0.5 or 3.10-alpha.

[Definition: The integer literals and the optional NamePart within the version number are referred to as the portions of the version number.]

Versions are ordered. When comparing two versions:

1. Trailing zero portions (that is, any zero-valued integer that is not followed by another integer) are discarded.

2. Comparison proceeds by comparing portions pairwise from the left.

3. If both versions have the same number of portions and all portions compare equal (under the rules of the XPath eq operator using the Unicode codepoint collation), then the versions compare equal.

4. If the number of portions in the two versions V₁ and V₂ is N₁ and N₂, with N₁<N₂, and if all portions in positions 1 to N compare equal, then V₁ is less than V₂ if the portion of V₂ in position N₁ is an integer, and is greater than V₂ if this portion is an NCName. For example, 1.2 is less than 1.2.5, while 2.0 is greater than 2.0-rc1.

5. Portions are compared as follows:

   1. If both portions are integers, they are compared using the rules of XPath value comparisons.

   2. If both portions are NCNames, they are compared using the rules of XPath value comparisons, using the Unicode Codepoint Collation.

   3. If one portion is an integer and the other is an NCName, the NCName comes first.

For example, the following shows a possible ordered sequence of version numbers:

0-rc1 < 0-rc2 < 0 < 1 = 1.0 < 1.0.2 
   < 1.0.3-rc1 < 1.0.3 < 1.0.3.2 < 1.0.10

Implementations may impose limits on the values used in a version number (or a version range: see below). Such limits are implementation-defined. As a minimum, a processor must accept version numbers including:

• A numeric part containing four integers;

• Each integer being in the range 0 to 999999;

• An NCName of up to 100 characters

Dependencies between packages may specify a version range (see 3.5.2 Dependencies between Packages3.5.2 Dependencies between Packages). A version range represents a set of accepted versions. The syntax of a version range is shown below. Whitespace is permitted only where indicated, using the terminal symbol S.Dependencies between packages may specify a version range (see 3.4.2 Dependencies between Packages3.4.2 Dependencies between Packages). A version range represents a set of accepted versions. The syntax of a version range is shown below. Whitespace is permitted only where indicated, using the terminal symbol S.Dependencies between packages may specify a version range (see 3.5.2 Dependencies between Packages3.4.2 Dependencies between Packages3.5.23.4.2 Dependencies between Packages). A version range represents a set of accepted versions. The syntax of a version range is shown below. Whitespace is permitted only where indicated, using the terminal symbol S.

        PackageVersionRange    ::=  AnyVersion | VersionRanges
        AnyVersion             ::=  "*"
        VersionRanges          ::=  VersionRange (S? "," S? VersionRange)*
        VersionRange           ::=  PackageVersion | VersionPrefix | 
                                      VersionFrom | VersionTo | VersionFromTo
        VersionPrefix          ::=  PackageVersion ".*"
        VersionFrom            ::=  PackageVersion "+"
        VersionTo              ::=  "to" S (PackageVersion | VersionPrefix)
        VersionFromTo          ::=  PackageVersion S 
                                      "to" S (PackageVersion | VersionPrefix)

The meanings of the various forms of version range are defined below:

• The range AnyVersion matches any version.

• The range VersionRanges matches a version if any constituent VersionRange matches that version.

  For example, 9.5.0.8, 9.6.1.2 matches those specific versions only, while 9.5.0.8, 9.6+ matches either version 9.5.0.8 or any version from 9.6 onwards.

• A range that is a PackageVersion matches that version only.

• The range VersionPrefix matches any version whose leading portions are the same as the portions in the PackageVersion part of the VersionPrefix.

  For example, 1.3.* matches 1.3,  1.3.5,  1.3.10.2,  and 1.3-beta (but not 1 or 1.4).

  Note:

  The .* indicates that additional portions may follow; it does not indicate a substring match on the final portion. So 1.3.* does not match 1.35, and 3.3-beta.* does not match 3.3-beta12. Also, 3.3-beta.* does not match 3.3-beta.5: this is because the last dot is not a portion separator, but is part of the final NCName. In fact, using .* after a version number that includes an NCName portion is pointless, because an NCName portion can never be followed by further portions.

• The range VersionFrom matches any version that is greater than or equal to the version supplied.

  For example 1.3+ matches 1.3,  1.3.2,  1.4,  and 2.1 (but not 1.3-beta or 1.2). And 1.3-beta+ matches 1.3-beta,  1.3-gamma,  1.3.0,  1.4, and 8.0, but not 1.3-alpha or 1.2.

• The range VersionTo matches any version that is less than or equal to some version that matches the supplied PackageVersion or VersionPrefix.

  For example, to 4.0 matches 1.5,  2.3,  3.8,  4.0,  and 4.0-beta (but not 4.0.1), while to 3.3.* matches 1.5 or 2.0.6 or 3.3.4621, but not 3.4.0 or 3.4.0-beta.

• The range VersionFromTo matches any version that is greater than or equal to the starting PackageVersion, and less than or equal to some version that matches the ending PackageVersion or VersionPrefix.

  For example, 1 to 5 matches 1.1,  2.1,  3.1,  or 5.0 (but not 5.1), while 1 to 5.* matches all of these, plus versions such as 5.7.2 (but not 6.0 or 6.0-beta). Similarly, 1.0-beta to 1.0 matches 1.0-beta, 1.0-beta.2, 1.0-gamma, and 1.0, but not 1.0-alpha or 1.0.1.

3.5.23.4.2 Dependencies between Packages

When components in one package reference components in another, the dependency of the first package on the second must be represented by an xsl:use-package element. This may appear in the principal stylesheet module of the first package (which may be a package manifest), or it may appear in a stylesheet module that is referenced from the principal stylesheet module via one or more xsl:include declarations; however it must not be referenced via xsl:import declarations (this is to avoid complications caused by multiple xsl:use-package declarations with different import precedence).

[Definition: If a package Q contains an xsl:use-package element that references package P, then package Q is said to use package P. In this relationship package Q is referred to as the using package, package P as the used package.]

The phrase directly uses is synonymous with uses as defined above, while directly or indirectly uses refers to the transitive closure of this relationship.

<!-- Category: declaration -->
<xsl:use-package
  name = uri
  package-version? = string〔'*'〕 >
  <!-- Content: (xsl:package-location | xsl:accept | xsl:override)* -->
</xsl:use-package>

A package may be used by more than one other package, but the relationship must not be cyclic. It is possible, but by no means inevitable, that using the same package in more than one place within a stylesheet will cause static errors due to the presence of conflicting components according to the above rules. Where a package is successfully used by more than one other package, its components may be overridden in different ways by different using packages.

The name and package-version attributes together identify the used package. The value of the package-version attribute, if present, must conform to the rules for a PackageVersionRange given in 3.5.1 Versions of a Package3.5.1 Versions of a Package; if omitted the value * is assumed, which matches any version. The used package must have a name that is an exact match for the name in the name attribute (using codepoint comparison), and its explicit or implicit package-version must match the version range given in the package-version attribute.The name and package-version attributes together identify the used package. The value of the package-version attribute, if present, must conform to the rules for a PackageVersionRange given in 3.4.1 Versions of a Package3.4.1 Versions of a Package; if omitted the value * is assumed, which matches any version. The used package must have a name that is an exact match for the name in the name attribute (using codepoint comparison), and its explicit or implicit package-version must match the version range given in the package-version attribute.The name and package-version attributes together identify the used package. The value of the package-version attribute, if present, must conform to the rules for a PackageVersionRange given in 3.5.1 Versions of a Package3.4.1 Versions of a Package3.5.13.4.1 Versions of a Package; if omitted the value * is assumed, which matches any version. The used package must have a name that is an exact match for the name in the name attribute (using codepoint comparison), and its explicit or implicit package-version must match the version range given in the package-version attribute.

Rules for determining the location of the package are described at 3.5.3 Locating Packages3.4.3 Locating Packages3.5.33.4.3 Locating Packages.

[ERR XTSE3005] It is a static error if a package is dependent on itself, where package A is defined as being dependent on package B if A contains an xsl:use-package declaration that references B, or if A contains an xsl:use-package declaration that references a package C that is itself dependent on B.

[ERR XTSE3008] It is a static error if an xsl:use-package declaration appears in a stylesheet module that is not in the same stylesheet level as the principal stylesheet module of the package.

The xsl:accept and xsl:override elements are used to modify the visibility or behavior of components acquired from the used package; they are described in 3.5.4.2 Accepting Components3.4.4.2 Accepting Components3.5.4.23.4.4.2 Accepting Components below.

3.5.33.4.3 Locating Packages

A package may be located either explicitly, through one or more xsl:use-package elements, or implicitly, in an implementation-defined mechanism. Providing multiple package locations allows a developer to create fallback mechanisms or perform diagnostics.

<xsl:package-location
  href = uri
  path-in-archive? = string
  archive-type? = string
  is-priority? = boolean〔true()〕
  format? = string />

A xsl:package-location points to a resource that may or may not be an archive. If the target resource is an archive, then xsl:package-location:

• must have an attribute path-in-archive, specifying the location of the package manifest within the archive. The value of path-in-archive is normalized such that it always begins with the string !/ (the result of replace(., "^(!/)?(.+)", "!/$2")).

• may have an attribute archive-type, specifying the type of archive. Implementations must support the ZIP file format, as defined by [ISO 21320], the default archive format if the attribute is missing or the explicit format if the attribute has the value zip. All other values of this attribute are implementation-defined.

It is a static error if the attribute archive-type is present without the attribute path-in-archive, or if it does not have the value zip or an implementation-defined value.

The attribute href takes an absolute or relative URI reference, which is resolved as described in 5.8 URI References, to locate the resource that is the package manifest or is the archive that contains the package manifest.

The URI scheme for archive resources is currently only provisionally defined ([RFC 7595]), with the syntax jar:<url>!/[<entry>], but variations on this syntax are known (such as using zip instead of jar). The entry is already accommodated by the attribute archive-type, so the following adjustments must be made to the value of href that points to an archive:

• Remove "zip:" or "jar:" from the beginning of the value.

• Remove !/ and any string text that follows.

The attribute format takes a string, default value xslt if the attribute is absent, specifying the format of the package manifest. The value xslt indicates that the package manifest is a standard XML resource as described in these specifications. All other values are implementation-defined, allowing implementers to support optimized formats for a package manifest, be it a compiled binary resource or a different XML format.

[Definition: A xsl:package-location without the attribute is-priority, or with is-priority set to true is a high priority package location.][Definition: A xsl:package-location with is-priority set to false is a low priority package location.]

Each high priority package location is processed in document order, followed by implementation-defined package locations, followed by each low priority package location in document order. [Definition: The first package location whose value of href, when resolved as described in 5.8 URI References, allows the system to find the specified resource, and its entry if the resource is an archive, is the optimal package location.] Once an optimal package location is found, no other package locations are checked.

If the returned resource is an archive, the archive entry is to be treated as the package manifest, otherwise the resource itself is to be treated as the package manifest. The package manifest returned from the optimal package location is checked against the implicit or explicit value of the attribute format. If the resource does not conform to the rules for the format type a static error is raised.

The package manifest is then checked against the the package name and version specified in the xsl:use-package declaration. If the resource does not conform to the rules for the name and version, a static error is raised.

[ERR XTSE3000] It is a static error if after evaluating each xsl:package-location declaration and implementation-defined package location, no priority package location is found.

[ERR XTSE3002] It is a static error if the package manifest returned by the priority package location does not conform to the rules of the implicit or explicit value of attribute format.

[ERR XTSE3003] It is a static error if the package manifest returned by the priority package location does not conform to the name and version specified in an xsl:use-package declaration.

[ERR XTSE3004] It is a static error if the attribute archive-type is present without the attribute path-in-archive, or if it does not have the value zip or an implementation-defined value.

<xsl:use-package name="Q" version="3.0" xmlns:saxon="http://saxon.sf.net/"/>
     <package-location href="q-dev.xsl" use-when="$diagnostics-on"/>
     <package-location _href="file:/{$prod-path}/q.zip" path-in-archive="q.sef" 
           is-priority="true" format="saxon:sef"/>
     <package-location href="file:/D:/fallback/q.xsl" format="xslt" is-priority="false"/>
</xsl:package>

3.5.43.4.4 Named Components in Packages

This section discusses the use of named components in packages.

The components which can be declared in one package and referenced in another are: functions, named templates, attribute sets, modes, and global variables and parameters.

In addition, keys and accumulators are classified as named components because they can contain references to components in another package, even though they cannot themselves be referenced from outside the package.

Named and unnamed modes come within the scope of this section, but there are differences noted in 3.5.5 Overriding Template Rules from a Used Package3.4.5 Overriding Template Rules from a Used Package3.5.53.4.5 Overriding Template Rules from a Used Package.

Not all declarations result in components:

• Named declarations that can neither be referenced from outside their containing package, nor can contain references to components in other packages (examples are xsl:output, xsl:character-map, and xsl:decimal-format) are not considered to be components and are therefore outside the scope of this section.

• Some declarations, such as xsl:decimal-format and xsl:strip-space, declare aspects of the processing context which are not considered to be components as defined here.

• Template rules (xsl:template with a match attribute) are also not considered to be components for the purposes of this section, which is concerned only with components that are bound by name. However, when an xsl:template has both a match attribute and a name attribute, then it establishes both a template rule and a named template, and in its role as a named template it comes within the scope of this discussion.

• A named declaration, for example a named template, a function, or a global variable, may be overridden within the same package by another like-named declaration having higher import precedence. When a declaration is overridden in this way it cannot be referenced by name either from within its containing package or from outside that package.

• In the case of xsl:attribute-set and xsl:key declarations, several declarations combine to form a single component.

The section is largely concerned with details of the rules that affect references from one component to another by name, whether the components are in the same package or in different packages. The rules are designed to meet a number of requirements:

• A component defined in one package can be overridden by a component in another package, provided the signatures are type-compatible.

• The author of a package can declare whether the components in the package are public or private (that is, whether or not they can be used from outside the package) and whether they are final, overridable, or abstract (that is whether they can or must be overridden by the using package).

• Within an application, two packages can make use of a common library and override its components in different ways.

• Visibility of components can be defined either as part of the declaration of the component, or in the package manifest.

• An application that wishes to make use of a library package can be selective about which components from the library it acquires, perhaps to avoid name clashes between components acquired from different libraries.

[Definition: The term component is used to refer to any of the following: a stylesheet function, a named template, a mode, an accumulator, an attribute set, a key, global variable, or a mode.]

[Definition: The symbolic identifier of a component is a composite name used to identify the component uniquely within a package. The symbolic identifier comprises the kind of component (stylesheet function, named template, accumulator, attribute set, global variable, key, or mode), the expanded QName of the component (namespace URI plus local name), and in the case of stylesheet functions, the upper bound of the arity range.]

[Definition: Two components are said to be homonymous if they have the same symbolic identifier.]

Every component has a declaration in some stylesheet module and therefore within some package. In the case of attribute sets and keys, there may be several declarations. The declaration is an element in an XDM tree representing the stylesheet module. Declarations therefore have identity, based on XDM node identity.

[Definition: The declaring package of a component is the package that contains the declaration (or, in the case of xsl:attribute-set and xsl:key, multiple declarations) of the component.]

When a component declared in one package is made available in another, the using package will contain a separate component that can be regarded as a modified copy of the original. The new component shares the same symbolic identifier as the original, and it has the same declaration, but it has other properties such as its visibility that may differ from the original.

[Definition: A component declaration results in multiple components, one in the package in which the declaration appears, and potentially one in each package that uses the declaring package, directly or indirectly, subject to the visibility of the component. Each of these multiple components has the same declaring package, but each has a different containing package. For the original component, the declaring package and the containing package are the same; for a copy of a component made as a result of an xsl:use-package declaration, the declaring package will be the original package, and the containing package will be the package in which the xsl:use-package declaration appears.]

The properties of a component are as follows:

• The original declaration of the component.

• The package to which the component belongs (called its containing package, not to be confused with the declaring package).

• The symbolic identifier of the component.

• The visibility of the component, which determines the way in which the component is seen by other components within the same package and within using packages. This is one of public, private, abstract, final, or hidden. The visibility of components is discussed further in 3.5.4.1 Visibility of Components3.5.4.1 Visibility of Components.The visibility of the component, which determines the way in which the component is seen by other components within the same package and within using packages. This is one of public, private, abstract, final, or hidden. The visibility of components is discussed further in 3.4.4.1 Visibility of Components3.4.4.1 Visibility of Components.The visibility of the component, which determines the way in which the component is seen by other components within the same package and within using packages. This is one of public, private, abstract, final, or hidden. The visibility of components is discussed further in 3.5.4.1 Visibility of Components3.4.4.1 Visibility of Components3.5.4.13.4.4.1 Visibility of Components.

• A set of bindings for the symbolic references in the component. The way in which these bindings are established is discussed further in 3.5.4.5 Binding References to Components3.4.4.5 Binding References to Components3.5.4.53.4.4.5 Binding References to Components.

[Definition: The declaration of a component includes constructs that can be interpreted as references to other components by means of their symbolic identifiers. These constructs are generically referred to as symbolic references. Examples of constructs that give rise to symbolic references are the name attribute of xsl:call-template; the [xsl:]use-attribute-sets attribute of xsl:copy, xsl:element, and literal result elements; the explicit or implicit mode attribute of xsl:apply-templates; XPath variable references referring to global variables; XPath static function calls (including partial function applications) referring to stylesheet functions; and named function references (example: my:f#1) referring to stylesheet functions. ]

Symbolic references exist as properties of the declaration of a component. The symbolic identifier being referred to can be determined straightforwardly from the syntactic form and context of the reference: for example, the instruction <xsl:value-of select="f:price($o)" xmlns:f="http://f.com/"/> contains a symbolic reference to a function with expanded name {http://f.com/}price and with arity=1. However, because there may be several (homonymous) function components with this symbolic identifier, translating this symbolic reference into a reference to a specific component (a process called “binding”) is less straightforward, and is described in the text that follows.

The process of assembling a stylesheet from its constituent packages is primarily a process of binding these symbolic references to actual components. Within any component whose declaration is D, there is a set of bindings; each binding is an association between a symbolic reference in D and a component whose symbolic identifier matches the outward reference. Outward references for which a component C contains a binding are said to be bound in C; those for which C contains no binding are said to be unbound.

For example, suppose that in some package Q, function A calls B, which in turn calls C, and that B is private. Now suppose that in some package P which uses Q, C is overridden. The effect of the binding process is that P will contain three components corresponding to A, B, and C, which we might call A_P, B_P, and C_P. The declarations of A_P and B_P are in package Q, but the declaration of C_P is in P. The internal visibility of B_P will be hidden (meaning that it cannot be referenced from within P), and B_P will contain a binding for the component C_P that corresponds to the outward reference from B to C. The effect is that when A calls B and B calls C, it is the overriding version of C that is executed.

In another package R that uses Q without overriding C, there will be three different components A_R, B_R, and C_R. This time the declaration of all three components is in the original package Q. Component B_R will contain a binding to C_R, so in this package, the original version of C is executed. The fact that one package P overrides C thus has no effect on R, which does not override it.

The binding process outlined above is described in more detail in 3.5.4.5 Binding References to Components3.4.4.5 Binding References to Components3.5.4.53.4.4.5 Binding References to Components.

Template rules are not components in their own right; unlike named templates, they are never referenced by name. Component references within a template rule (for example, references to functions, global variables, or named templates) are treated as occurring within the component that represents the containing mode. This includes component references within the match patterns of template rules. If a template rule lists several modes, it is treated as if there were multiple template rules one in each mode.

An xsl:apply-templates instruction with no mode attribute is treated as a reference to the default mode defined for that instruction (see 3.7.3 The default-mode Attribute3.7.3 The default-mode Attribute), which in turn defaults to the unnamed mode. An implicit reference to the unnamed made is treated in the same way as any other symbolic reference. Note that there is an unnamed mode in every package, and the unnamed mode always has private visibility.An xsl:apply-templates instruction with no mode attribute is treated as a reference to the default mode defined for that instruction (see 3.6.3 The default-mode Attribute3.6.3 The default-mode Attribute), which in turn defaults to the unnamed mode. An implicit reference to the unnamed made is treated in the same way as any other symbolic reference. Note that there is an unnamed mode in every package, and the unnamed mode always has private visibility.An xsl:apply-templates instruction with no mode attribute is treated as a reference to the default mode defined for that instruction (see 3.7.3 The default-mode Attribute3.6.3 The default-mode Attribute3.7.33.6.3 The default-mode Attribute), which in turn defaults to the unnamed mode. An implicit reference to the unnamed made is treated in the same way as any other symbolic reference. Note that there is an unnamed mode in every package, and the unnamed mode always has private visibility.

Where an xsl:template element has both a name and a match attribute, it is treated as if there were two separate xsl:template elements, one with a name attribute and one with a match attribute.

Keys and accumulators behave rather differently from other components. Their visibility is always private, which means they can only be used within their declaring package. In addition, the component binding is generally made dynamically rather than statically, by virtue of a string passed as an argument to the function key, accumulator-before, or accumulator-after. (In the case of accumulators, there can also be static references: see the use-accumulators attribute of xsl:source-document, xsl:merge-source, and xsl:mode.) However, outward references from key definitions and accumulators to other components (such as global variables and functions) behave in the same way as component references contained in any other private component, in that they may be re-bound to an overriding declaration of the target component.

<xsl:package name="Q"
        version="3.0"                
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:variable name="A" visibility="final" select="$B + 1"/>
  <xsl:variable name="B" visibility="private" select="$C * 2"/>
  <xsl:variable name="C" visibility="public" select="22"/>
</xsl:package>

<xsl:package name="P"
        version="3.0"                
        xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:use-package name="Q">
    <xsl:override>
      <xsl:variable name="C" visibility="private" select="$xsl:original + 3"/>
    </xsl:override>
  </xsl:use-package>
  
  <xsl:template name="T" visibility="public">
    <xsl:value-of select="$A"/>
  </xsl:template>
</xsl:package>

<xsl:variable name="v" as="xs:integer" visibility="public" select="3"/>

<xsl:function name="f:factory" as="fn(*)" visibility="final">
  <xsl:sequence select="fn() { $v }"/>
</xsl:function>

      
<xsl:use-package name="P">
  <xsl:override>
    <xsl:variable name="v" as="xs:integer" select="4"/>
  </xsl:override>
</xsl:use-package>

<xsl:template name="xsl:initial-template">
  <v value="{f:factory()()}"/>
</xsl:template>

<xsl:variable name="get-order" select="key('orders-key', ?, ?)"/>

3.5.53.4.5 Overriding Template Rules from a Used Package

The rules in the previous section apply to named components including functions, named templates, global variables, and named attribute sets. The rules for modes, and the template rules appearing within a mode, are slightly different.

The unnamed mode is local to a package: in effect, each package has its own private unnamed mode, and the unnamed mode of one package does not interact with the unnamed mode of any other package. An xsl:apply-templates instruction with no mode attribute is treated as a symbolic reference to the default mode defined for that instruction (see 3.7.3 The default-mode Attribute3.7.3 The default-mode Attribute), which in turn defaults to the unnamed mode. Because the unnamed mode always has private visibility, it cannot be overridden in another package.The unnamed mode is local to a package: in effect, each package has its own private unnamed mode, and the unnamed mode of one package does not interact with the unnamed mode of any other package. An xsl:apply-templates instruction with no mode attribute is treated as a symbolic reference to the default mode defined for that instruction (see 3.6.3 The default-mode Attribute3.6.3 The default-mode Attribute), which in turn defaults to the unnamed mode. Because the unnamed mode always has private visibility, it cannot be overridden in another package.The unnamed mode is local to a package: in effect, each package has its own private unnamed mode, and the unnamed mode of one package does not interact with the unnamed mode of any other package. An xsl:apply-templates instruction with no mode attribute is treated as a symbolic reference to the default mode defined for that instruction (see 3.7.3 The default-mode Attribute3.6.3 The default-mode Attribute3.7.33.6.3 The default-mode Attribute), which in turn defaults to the unnamed mode. Because the unnamed mode always has private visibility, it cannot be overridden in another package.

A named mode may be declared in an xsl:mode declaration as being either public, private, or final. The values of the visibility attribute are interpreted as follows:

As with other named components, an xsl:use-package declaration may contain an xsl:accept element to control the visibility of a mode acquired from the used package. The allowed values of its visibility attribute are public, private, and final.

The xsl:mode declaration itself must not be overridden. A using package must not contain an xsl:mode declaration whose name matches that of a public or finalxsl:mode component accepted from a used package.

The xsl:expose and xsl:accept elements may be used to reduce the visibility of a mode in a using package; the same rules apply in general, though some of the rules are not applicable because, for example, modes cannot be abstract.

It is not possible for a package to combine the template rules from two other packages into a single mode. When xsl:apply-templates is used without specifying a mode, the chosen template rules will always come from the same package; when it is used with a named mode, then they will come from the package where the mode is defined, or any package that uses that package and adds template rules to the mode. If two template rules defined in different packages match the same node, then the rule in the using package wins over any rule in the used package; this decision is made before taking other factors such as import precedence and priority into account.

A static error occurs if two modes with the same name are visible within a package, either because they are both declared within the package, or because one is declared within the package and the other is acquired from a used package, or because both are accepted from different used packages.

The rules for matching template rules by import precedence and priority operate as normal, with the addition that template rules declared within an xsl:use-package element have higher precedence than any template rule declared in the used package. More specifically, given an xsl:apply-templates instruction in package P, naming a mode M that is declared in a used package Q and is overridden in P, the search order for template rules is:

1. Rules declared within P (specifically, xsl:template rules declared as children of an xsl:override element within the xsl:use-package element that references package Q). If there are multiple rules declared within P that match a selected node, they are resolved on the basis of their explicit or implicit priority, and if the priorities are equal, the last one in declaration order wins.

2. Rules declared within Q, taking import precedence, priority, and declaration order into account in the usual way (see 6.6 Conflict Resolution for Template Rules).

3. Built-in template rules (see 6.8 Built-in Template Rules) selected according to the on-no-match attribute of the xsl:mode declaration (in Q), or its default.

If the mode is overridden again in a package R that uses P, then this search order is extended by adding R at the start of the search list, and so on recursively.

3.5.63.4.6 Declarations Local to a Package

The xsl:import and xsl:include declarations are local to a package.

Declarations of keys, accumulators, decimal formats, namespace aliases (see 11.1.4 Namespace Aliasing), output definitions, and character maps within a package have local scope within that package — they are all effectively private. The elements that declare these constructs do not have a visibility attribute. The unnamed decimal format and the unnamed output format are also local to a package.

If xsl:strip-space or xsl:preserve-space declarations appear within a library package, they only affect calls to the doc or document functions appearing within that package. Such a declaration within the top-level package additionally affects stripping of whitespace in the document that contains the global context item.

An xsl:decimal-format declaration within a package applies only to calls on format-number appearing within that package.

An xsl:namespace-alias declaration within a package applies only to literal result elements within the same package.

An xsl:import-schema declaration within a package adds the names of the imported schema components to the static context for that package only; these names are effectively private, in the sense that they do not become available for use in any other packages. However, the names of schema components must be consistent across the stylesheet as a whole: it is not possible for two different packages within a stylesheet to use a type-name such as part-number to refer to different schema-defined simple or complex types.

Type names used in the interface of public components in a package (for example, in the arguments of a function) must be respected by callers of those components, in the sense that the caller must supply values of the correct type. Often this will mean that the using component, if it contains calls on such interfaces, must itself import the necessary schema components. However, the requirement for an explicit schema import applies only where the package contains explicit use of the names of schema components required to call such interfaces.

At execution time, the schema available for validating instance documents contains (at least) the union of the schema components imported into all constituent packages of the stylesheet.

3.5.73.4.7 Declaring the Global Context Item

The xsl:global-context-item element is used to declare whether a global context item is required, and if so, what its required type is.

The element is a declaration that can appear at most once in any stylesheet module; and if more than one xsl:global-context-item declaration appears within a package, then the declarations must be consistent. Specifically, all the attributes must have semantically equivalent values.

[ERR XTSE3087] It is a static error if more than one xsl:global-context-item declaration appears within a stylesheet module, or if several modules within a single package contain inconsistent xsl:global-context-item declarations

If there is no xsl:global-context-item declaration for a package, this is equivalent to specifying the empty element <xsl:global-context-item/>, which imposes no constraints.

<!-- Category: declaration -->
<xsl:global-context-item
  as? = item-type
  use? = "required" | "optional" | "absent"〔'optional'〕 />

The use attribute takes the value required, optional, or absent. The default is optional.

• If the value required is specified, then there must be a global context item.

• If the value optional is specified, or if the attribute is omitted, or if the xsl:global-context-item element is omitted, then there may or may not be a global context item.

• If the value absent is specified, then the global focus (context item, position, and size) will be absent

  Note:

  This specification does not define whether supplying a global context item in this situation results in an error or warning, or whether the supplied context item is simply ignored.

If the as attribute is present then its value must be an ItemType^XP. If the attribute is omitted this is equivalent to specifying as="item()".

The as attribute defines the required type of the global context item. The default value is as="item()". If a global context item is supplied then it must conform to the required type, after conversion (if necessary) using the coercion rules.

[ERR XTSE3089] It is a static error if the as attribute is present when use="absent" is specified.

The global context item is available only within the top-level package. If a valid xsl:global-context-item declaration appears within a library package, then it is ignored, unless it specifies use="required", in which case an error is raised: [see ERR XTTE0590].

A type error is raised if the top-level package contains an xsl:global-context-item declaration specifying a required type that does not match the supplied global context item. The error code is the same as for xsl:param: [see ERR XTTE0590].

[ERR XTDE3086] It is a dynamic error if an xsl:global-context-item declaration specifies use="required", and no global context item is supplied.

3.5.83.4.8 Worked Example of a Library Package

The example in this section illustrates the use of overrides to customize or extend a (fictional) library package named http://example.com/csv-parser, which provides a parsing function for data formatted as lines containing comma-separated values. For simplicity of exposition, the example shows a simple, naive implementation; a realistic CSV parser would be more complicated and make the example harder to follow.

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:csv="http://example.com/csv"
   exclude-result-prefixes="xs csv"
   version="3.0">

   <xsl:output indent="yes" />

   <xsl:use-package name="http://example.com/csv-parser" 
                    package-version="*" />

   <!-- example input "file"  -->
   <xsl:variable name="input" as="xs:string">
       name,id,postal code
       "Abel Braaksma",34291,1210 KA
       "Anders Berglund",473892,9843 ZD
   </xsl:variable>

   <!-- entry point -->
   <xsl:template name="xsl:initial-template">
       <xsl:copy-of select="csv:parse($input)" />
   </xsl:template>

</xsl:stylesheet>

<csv>
  <row>
    <field quoted="no">name</field>
    <field quoted="no">id</field>
    <field quoted="no">postal code</field>
  </row>
  <row>
    <field quoted="yes">Abel Braaksma</field>
    <field quoted="no">34291</field>
    <field quoted="no">1210 KA</field>
  </row>
  <row>
    <field quoted="yes">Anders Berglund</field>
    <field quoted="no">473892</field>
    <field quoted="no">9843 ZD</field>
  </row>
</csv>

<?xml version="1.0" encoding="UTF-8"?>
<xsl:package
   name="http://example.com/csv-parser"
   package-version="1.0.0"
   xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:csv="http://example.com/csv"
   exclude-result-prefixes="xs csv"
   declared-modes="yes"
   version="3.0">

   <!--* Mode declarations ... *-->
   <!--* Variable declarations ... *-->
   <!--* Attribute-set declaration ... *-->
   <!--* Function declarations ... *-->
   <!--* Templates ... *-->

</xsl:package>

<xsl:function name="csv:parse" visibility="final">
    <xsl:param name="input" as="xs:string" />   
    <xsl:variable name="result" as="element()">
        <csv>
            <xsl:apply-templates 
                select="(tokenize($input, $csv:line-separator) 
                        ! csv:preprocess-line(.))" 
                mode="csv:parse-line" />
        </csv>
    </xsl:variable>
    <xsl:apply-templates select="$result" 
                         mode="csv:post-process" />
</xsl:function>

<xsl:variable name="csv:line-separator" 
              as="xs:string" 
              select="'\r\n?|\n\r?'" 
              visibility="public"/>

<xsl:function name="csv:preprocess-line" 
                 as="xs:string?" 
                 visibility="public">
    <xsl:param name="line" as="xs:string" />
    <xsl:sequence select="normalize-space($line)" />
</xsl:function>

<xsl:mode name="csv:parse-line" visibility="public"/>

<xsl:template match="." mode="csv:parse-line">
    <row>
        <xsl:apply-templates 
            select="tokenize(., $csv:field-separator)" 
            mode="csv:parse-field" />
    </row>
</xsl:template>

<xsl:variable name="csv:field-separator" 
              as="xs:string" 
              select="','" 
              visibility="public"/>

<xsl:template match="." 
              mode="csv:parse-field" 
              expand-text="yes">
    <xsl:variable name="string-body-pattern"
                  as="xs:string"
                  select="'([^' || $csv:validated-quote || ']*)'"/>
    <xsl:variable name="quoted-value"
                  as="xs:string"
                  select="$csv:validated-quote 
                          || $string-body-pattern 
                          || $csv:validated-quote"/>
    <xsl:variable name="unquoted-value"
                  as="xs:string"
                  select="'(.+)'"/>

    <field xsl:use-attribute-sets="csv:field-attributes">{
        csv:preprocess-field(
          replace(., 
                  $quoted-value || '|' || $unquoted-value, 
                  '$1$2'))
    }</field>
</xsl:template>

<xsl:attribute-set name="csv:field-attributes" 
                   visibility="public">
    <xsl:attribute name="quoted" 
                   select="if (starts-with(., $csv:validated-quote)) 
                           then 'yes' 
                           else 'no'" />
</xsl:attribute-set>

<xsl:mode name="csv:parse-field"
          on-no-match="shallow-copy" 
          visibility="public"/>

<xsl:variable name="csv:quote" 
              as="xs:string" 
              select="'&quot;'" 
              visibility="public"/>

<xsl:variable name="csv:validated-quote" visibility="private"
   as="xs:string" select="
       if (string-length($csv:quote) ne 1) 
       then error( #csv:ERR001, 
                  'Incorrect length for $csv:quote, should be 1') 
       else $csv:quote" />

<xsl:function name="csv:preprocess-field" 
              as="xs:string">
    <xsl:param name="field" 
               as="xs:string" />
    <xsl:sequence select="$field" />
</xsl:function>

<xsl:mode name="csv:post-process" 
          on-no-match="shallow-copy" 
          visibility="public"/>

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
   xmlns:xs="http://www.w3.org/2001/XMLSchema"
   xmlns:csv="http://example.com/csv"
   exclude-result-prefixes="xs csv"
   version="3.0">

   <xsl:output indent="yes" />

   <xsl:use-package name="http://example.com/csv-parser" 
                    package-version="*">
       <xsl:override>
           <!-- Change the root element from 'csv' to 'root' -->
           <xsl:template match="csv" mode="csv:post-process">
               <root>
                   <xsl:apply-templates mode="csv:post-process" />
               </root>
           </xsl:template>

           <!-- add an extra attribute that uses the context item -->
           <xsl:attribute-set name="csv:field-attributes" 
                              use-attribute-sets="xsl:original">
               <xsl:attribute name="type" 
                              select="if (. castable as xs:decimal) 
                                      then 'numeric' 
                                      else 'string'" />
           </xsl:attribute-set>          

           <!-- use semicolon not comma between fields -->
           <xsl:variable name="csv:field-separator" 
                         as="xs:string" select="';'" 
                         visibility="public"/>

           <!-- prevent empty rows from appearing with empty lines -->
           <xsl:function name="csv:preprocess-line" 
                         as="xs:string?" 
                         visibility="public">
               <xsl:param name="line" as="xs:string" />
               <xsl:variable name="norm-line" 
                             select="normalize-space(xsl:original($line))" />
               <xsl:sequence select="if (string-length($norm-line) > 0) 
                                     then $norm-line 
                                     else ()" />
           </xsl:function>
       </xsl:override>
   </xsl:use-package>

   <!-- example input "file"  -->
   <xsl:variable name="input" as="xs:string">
       name;id;postal code
       "Braaksma Abel";34291;1210 KA
       "Berglund Anders";473892;9843 ZD
   </xsl:variable>

   <!-- entry point -->
   <xsl:template name="xsl:initial-template">
       <xsl:copy-of select="csv:parse($input)" />
   </xsl:template>

</xsl:stylesheet>

<root>
  <row>
    <field quoted="no" type="string">name</field>
    <field quoted="no" type="string">id</field>
    <field quoted="no" type="string">postal code</field>
  </row>
  <row>
    <field quoted="yes" type="string">Braaksma Abel</field>
    <field quoted="no" type="numeric">34291</field>
    <field quoted="no" type="string">1210 KA</field>
  </row>
  <row>
    <field quoted="yes" type="string">Berglund Anders</field>
    <field quoted="no" type="numeric">473892</field>
    <field quoted="no" type="string">9843 ZD</field>
  </row>
</root>

3.7.13.6.1 The fixed-namespaces Attribute

The fixed-namespaces attribute, if present, defines the fixed namespace bindings for a stylesheet module. The attribute may appear only on the outermost element of a stylesheet module (xsl:stylesheet, xsl:transform, or xsl:package). It is not available with simplified stylesheet modules.

If the fixed-namespaces attribute is present, then it defines the entire set of namespace bindings present in the static context of XPath expressions and patterns within the stylesheet, as well as other constructs where namespace prefixes are used in attribute and text nodes, such as the name attribute of declarations like xsl:function and xsl:variable, and as and type attributes referring to item types and schema types.

The value of the attribute is a whitespace-separated list of tokens, where each token contributes one or more namespace bindings to the fixed namespace bindings of the stylesheet module. Each token must be one of the following. If a token falls into more than one of these categories, then the first one that applies takes precedence.

• The string #standard, which is equivalent to specifying xsl xml xs xsi fn math map array err. This has the effect of binding each of these namespace prefixes to the reserved namespace with which it is conventionally associated.

• An NCName corresponding to one of the namespace prefixes present in the in-scope namespaces of the containing element node. This has the effect of adding the corresponding namespace binding to the fixed namespace bindings.

• Any one of the strings xsl, xml, xs, xsi, fn, math, map, array, err. This has the effect of binding that particular namespace prefix to the reserved namespace with which it is conventionally associated, whether or not the native namespace bindings contain a binding for this prefix.

  Note:

  Including xml in the list has no effect, since the XML namespace will always be in scope anyway.

  If the namespace prefix is explicitly bound to a different namespace, for example xmlns:math="java:java.util.Math", then that binding takes precedence.

• A string in the form prefix=uri, where prefix is an NCName and uri is a (non-empty) namespace URI: for example, xalan=http://xml.apache.org/xalan. This has the effect of binding the specified prefix to the specified URI.

• A URI Reference identifying the location of an XML document whose namespace bindings are to be used. For example, ./package.xsl. A token is interpreted as a URI if it does not match any of the other possibilities listed above (which will be the case if it contains a "/" as in this example).

  The URI Reference is used to locate an XML document, in the same way as described for xsl:include and xsl:import in 3.11.1 Locating Stylesheet Modules3.10.1 Locating Stylesheet Modules3.11.13.10.1 Locating Stylesheet Modules. The resource that is retrieved may be any namespace well-formed XML document. The in-scope namespace bindings of the outermost element of this document are added to the fixed namespace bindings of the stylesheet module.

  Note:

  Such URIs cannot contain whitespace.

If different tokens in the fixed-namespaces attribute result in multiple bindings for the same namespace prefix, the last one wins.

[ERR XTSE0122] It is a static error if a token appearing in the fixed-namespaces attribute takes a form that is not one of the permitted forms, or if it is interpreted as a URI but cannot be dereferenced to locate a namespace well-formed XML document. It is not permitted to bind the prefix xmlns. It is not permitted to bind the prefix xml or the XML namespace URI http://www.w3.org/XML/1998/namespace, other than to each other.

The following observations apply when a fixed-namespaces attribute is present:

• All expressions in the stylesheet module will have the same statically known namespaces^XP in their static context. This means that all prefixes used in XPath expressions, patterns, and similar constructs must be declared at the top level.

• Namespace prefixes used in element and attribute names in the stylesheet cannot be declared using this mechanism. Such prefixes must be bound using native namespace bindings. This also applies to namespace prefixes used in the [xsl:]exclude-result-prefixes and [xsl:]extension-element-prefixes attributes, and the stylesheet-prefix and result-prefix attributes of xsl:namespace-alias.

• It is not an error for an element within a stylesheet module to rebind a prefix listed in the fixed-namespaces attribute to a different URI; however this rebinding has no effect on the static context of XPath expressions and other similar constructs within its scope.

• The fixed-namespaces attribute has no effect on the interpretation of unprefixed names.

3.7.23.6.2 The default-collation Attribute

The default-collation attribute is a standard attribute that may appear on any element in the XSLT namespace, or (as xsl:default-collation) on a literal result element.

The attribute, when it appears on an element E, is used to specify the default collation used by all XPath expressions appearing in attributes or text value templates that have E as an ancestor, unless overridden by another default-collation attribute on an inner element. It also determines the collation used by certain XSLT constructs (such as xsl:key and xsl:for-each-group) within its scope.

The value of the attribute is a whitespace-separated list of collation URIs. If any of these URIs is a relative URI reference, then it is resolved as described in [Functions and Operators 4.0] section 5.3.1 Collations.. If the implementation recognizes one or more of the resulting absolute collation URIs, then it uses the first one that it recognizes as the default collation.

[ERR XTSE0125] It is a static error if the value of an [xsl:]default-collation attribute, after resolving against the base URI, contains no URI that the implementation recognizes as a collation URI.

The [xsl:]default-collation attribute does not affect the collation used by xsl:sort or by xsl:merge.

In the absence of an [xsl:]default-collation attribute, the default collation may be set by the calling application in an implementation-defined way. The recommended default, unless the user chooses otherwise, is to use the Unicode codepoint collation.

3.7.33.6.3 The default-mode Attribute

[Definition: The [xsl:]default-mode attribute defines the default mode, which is used as the default value for the mode attribute of all xsl:template and xsl:apply-templates elements within its scope.]

More specifically, when an element E matches the pattern (xsl:template[@match] | xsl:apply-templates)[not(@mode) or normalize-space(@mode) eq "#default"] (using the Unicode codepoint collation), then the effective value of the mode attribute is taken from the value of the [xsl:]default-mode attribute of the innermost ancestor-or-self element of E that has such an attribute. If there is no such element, then the default is the unnamed mode. This is equivalent to specifying #unnamed.

In addition, when the attribute appears on the xsl:package, xsl:stylesheet, or xsl:transform element of the principal stylesheet module of the top-level package, it provides a default value for the initial mode used on stylesheet invocation.

The value of the [xsl:]default-mode attribute must either be an EQName, or the token #unnamed which refers to the unnamed mode.

3.7.43.6.4 User-defined Data Elements

[Definition: In addition to declarations, the xsl:stylesheet element may contain among its children any element not from the XSLT namespace, provided that the expanded QName of the element has a non-null namespace URI. Such elements are referred to as user-defined data elements.]

[ERR XTSE0130] It is a static error if an xsl:stylesheet, xsl:transform, or xsl:package element has a child element whose name has a null namespace URI.

An implementation may attach an implementation-defined meaning to user-defined data elements that appear in particular namespaces. The set of namespaces that are recognized for such data elements is implementation-defined. The presence of a user-defined data element must not change the behavior of XSLT elements and functions defined in this document; for example, it is not permitted for a user-defined data element to specify that xsl:apply-templates should use different rules to resolve conflicts. The constraints on what user-defined data elements can and cannot do are exactly the same as the constraints on extension attributes, described in 3.2 Extension Attributes3.2 Extension Attributes. Thus, an implementation is always free to ignore user-defined data elements, and must ignore such data elements without giving an error if it does not recognize the namespace URI. An implementation may attach an implementation-defined meaning to user-defined data elements that appear in particular namespaces. The set of namespaces that are recognized for such data elements is implementation-defined. The presence of a user-defined data element must not change the behavior of XSLT elements and functions defined in this document; for example, it is not permitted for a user-defined data element to specify that xsl:apply-templates should use different rules to resolve conflicts. The constraints on what user-defined data elements can and cannot do are exactly the same as the constraints on extension attributes, described in 24.1 Extension Attributes24.1 Extension Attributes. Thus, an implementation is always free to ignore user-defined data elements, and must ignore such data elements without giving an error if it does not recognize the namespace URI. An implementation may attach an implementation-defined meaning to user-defined data elements that appear in particular namespaces. The set of namespaces that are recognized for such data elements is implementation-defined. The presence of a user-defined data element must not change the behavior of XSLT elements and functions defined in this document; for example, it is not permitted for a user-defined data element to specify that xsl:apply-templates should use different rules to resolve conflicts. The constraints on what user-defined data elements can and cannot do are exactly the same as the constraints on extension attributes, described in 3.2 Extension Attributes24.1 Extension Attributes3.224.1 Extension Attributes. Thus, an implementation is always free to ignore user-defined data elements, and must ignore such data elements without giving an error if it does not recognize the namespace URI.

User-defined data elements can provide, for example,

• information used by extension instructions or extension functions (see 24 Extensibility and Fallback),

• information about what to do with any final result tree,

• information about how to construct source trees,

• optimization hints for the processor,

• metadata about the stylesheet,

• structured documentation for the stylesheet.

3.9.13.8.1 XSLT 1.0 Compatibility Mode

[Definition: An element in the stylesheet is processed with XSLT 1.0 behavior if its effective version is equal to 1.0.]

In this mode, if any attribute contains an XPath expression, then the expression is evaluated with XPath 1.0 compatibility mode set to true. For details of this mode, see [XPath 4.0] section 2.2.1 Static Context. Expressions contained in text value templates are always evaluated with XPath 1.0 compatibility mode set to false, since this construct was not available in XSLT 1.0.

Furthermore, in such an expression any function call for which no implementation is available (unless it uses the standard function namespace) is bound to a fallback error function whose effect when evaluated is to raise a dynamic error [see ERR XTDE1425] . The effect is that with backwards compatible behavior enabled, calls on extension functions that are not available in a particular implementation do not cause an error unless the function call is actually evaluated. For further details, see 24.1 Extension Functions24.1 Extension Functions.Furthermore, in such an expression any function call for which no implementation is available (unless it uses the standard function namespace) is bound to a fallback error function whose effect when evaluated is to raise a dynamic error [see ERR XTDE1425] . The effect is that with backwards compatible behavior enabled, calls on extension functions that are not available in a particular implementation do not cause an error unless the function call is actually evaluated. For further details, see 24.2 Extension Functions24.2 Extension Functions.Furthermore, in such an expression any function call for which no implementation is available (unless it uses the standard function namespace) is bound to a fallback error function whose effect when evaluated is to raise a dynamic error [see ERR XTDE1425] . The effect is that with backwards compatible behavior enabled, calls on extension functions that are not available in a particular implementation do not cause an error unless the function call is actually evaluated. For further details, see 24.1 Extension Functions24.2 Extension Functions24.124.2 Extension Functions.

Certain XSLT constructs also produce different results when XSLT 1.0 compatibility mode is enabled. This is described separately for each such construct.

3.9.23.8.2 XSLT 2.0 Compatibility Mode

[Definition: An element is processed with XSLT 2.0 behavior if its effective version is equal to 2.0.]

In this specification, no differences are defined for XSLT 2.0 behavior. An XSLT 4.0 processor will therefore produce the same results whether the effective version of an element is set to 2.0 or 4.0.

3.9.33.8.3 XSLT 3.0 Compatibility Mode

[Definition: An element is processed with XSLT 3.0 behavior if its effective version is equal to 3.0.]

In this specification, no differences are defined for XSLT 3.0 behavior. An XSLT 4.0 processor will therefore produce the same results whether the effective version of an element is set to 3.0 or 4.0.

3.11.13.10.1 Locating Stylesheet Modules

The include and import mechanisms use two declarations, xsl:include and xsl:import, which are defined in the sections that follow.

These declarations use an href attribute, whose value is a URI reference, to identify the stylesheet module to be included or imported. If the value of this attribute is a relative URI reference, it is resolved as described in 5.8 URI References.

After resolving against the base URI, the way in which the URI reference is used to locate a representation of a stylesheet module, and the way in which the stylesheet module is constructed from that representation, are implementation-defined. In particular, it is implementation-defined which URI schemes are supported, whether fragment identifiers are supported, and what media types are supported. Conventionally, the URI is a reference to a resource containing the stylesheet module as a source XML document, or it may include a fragment identifier that selects an embedded stylesheet module within a source XML document; but the implementation is free to use other mechanisms to locate the stylesheet module identified by the URI reference.

The referenced stylesheet modulemust be either a standard stylesheet module or a simplified stylesheet. It must not be a package manifest. If it is a simplified stylesheet module then it is transformed into the equivalent standard stylesheet module by applying the transformation described in 3.8 Simplified Stylesheet Modules3.8 Simplified Stylesheet Modules. The referenced stylesheet modulemust be either a standard stylesheet module or a simplified stylesheet. It must not be a package manifest. If it is a simplified stylesheet module then it is transformed into the equivalent standard stylesheet module by applying the transformation described in 3.7 Simplified Stylesheet Modules3.7 Simplified Stylesheet Modules. The referenced stylesheet modulemust be either a standard stylesheet module or a simplified stylesheet. It must not be a package manifest. If it is a simplified stylesheet module then it is transformed into the equivalent standard stylesheet module by applying the transformation described in 3.8 Simplified Stylesheet Modules3.7 Simplified Stylesheet Modules3.83.7 Simplified Stylesheet Modules.

Implementations may choose to accept URI references containing a fragment identifier defined by reference to the XPointer specification (see [XPointer Framework]). Note that if the implementation does not support the use of fragment identifiers in the URI reference, then it will not be possible to include an embedded stylesheet module.

[ERR XTSE0165] It is a static error if the processor is not able to retrieve the resource identified by the URI reference, or if the resource that is retrieved does not contain a stylesheet module.

3.11.23.10.2 Stylesheet Inclusion

<!-- Category: declaration -->
<xsl:include
  href = uri />

A stylesheet module may include another stylesheet module using an xsl:include declaration.

The xsl:include declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.11.1 Locating Stylesheet Modules3.11.1 Locating Stylesheet Modules.The xsl:include declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.10.1 Locating Stylesheet Modules3.10.1 Locating Stylesheet Modules.The xsl:include declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.11.1 Locating Stylesheet Modules3.10.1 Locating Stylesheet Modules3.11.13.10.1 Locating Stylesheet Modules.

[ERR XTSE0170] An xsl:include element must be a top-level element.

[Definition: A stylesheet level is a collection of stylesheet modules connected using xsl:include declarations: specifically, two stylesheet modules A and B are part of the same stylesheet level if one of them includes the other by means of an xsl:include declaration, or if there is a third stylesheet module C that is in the same stylesheet level as both A and B.]

[Definition: The declarations within a stylesheet level have a total ordering known as declaration order. The order of declarations within a stylesheet level is the same as the document order that would result if each stylesheet module were inserted textually in place of the xsl:include element that references it.] In other respects, however, the effect of xsl:include is not equivalent to the effect that would be obtained by textual inclusion.

If two or more xsl:include declarations within the same stylesheet level reference the same absolute URI, or reference different absolute URIs that are known to refer to the same resource, then the duplicate xsl:include declarations, other than the first in declaration order, are ignored. Similarly, an xsl:include declaration that references the top-level stylesheet module within its stylesheet level is ignored.

3.11.33.10.3 Stylesheet Import

<!-- Category: declaration -->
<xsl:import
  href = uri />

A stylesheet module may import another stylesheet module using an xsl:importdeclaration. Importing a stylesheet module is the same as including it (see 3.11.2 Stylesheet Inclusion3.10.2 Stylesheet Inclusion3.11.23.10.2 Stylesheet Inclusion) except that template rules and other declarations in the importing module take precedence over template rules and declarations in the imported module; this is described in more detail below.

The xsl:import declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.11.1 Locating Stylesheet Modules3.11.1 Locating Stylesheet Modules.The xsl:import declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.10.1 Locating Stylesheet Modules3.10.1 Locating Stylesheet Modules.The xsl:import declaration has a requiredhref attribute whose value is a URI reference identifying the stylesheet module to be included. This attribute is used as described in 3.11.1 Locating Stylesheet Modules3.10.1 Locating Stylesheet Modules3.11.13.10.1 Locating Stylesheet Modules.

[ERR XTSE0190] An xsl:import element must be a top-level element.

<xsl:stylesheet version="3.0"
                xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
  <xsl:import href="article.xsl"/>
  <xsl:import href="bigfont.xsl"/>
  <xsl:attribute-set name="note-style">
    <xsl:attribute name="font-style">italic</xsl:attribute>
  </xsl:attribute-set>
</xsl:stylesheet>

[Definition: The stylesheet levels making up a stylesheet are treated as forming an import tree. In the import tree, each stylesheet level has one child for each xsl:import declaration that it contains.] The ordering of the children is the declaration order of the xsl:import declarations within their stylesheet level.

[Definition: A declarationD in the stylesheet is defined to have lower import precedence than another declaration E if the stylesheet level containing D would be visited before the stylesheet level containing E in a post-order traversal of the import tree (that is, a traversal of the import tree in which a stylesheet level is visited after its children). Two declarations within the same stylesheet level have the same import precedence.]

For example, suppose

• stylesheet module A imports stylesheet modules B and C in that order;

• stylesheet module B imports stylesheet module D;

• stylesheet module C imports stylesheet module E.

Then the import tree has the following structure:

• A

  • B

    • D

  • C

    • E

The order of import precedence (lowest first) is D, B, E, C, A.

In general, a declaration with higher import precedence takes precedence over a declaration with lower import precedence. This is defined in detail for each kind of declaration.

[ERR XTSE0210] It is a static error if a stylesheet module directly or indirectly references itself via a chain of xsl:include and xsl:import declarations that contains at least one xsl:import.

3.13.13.12.1 Stripping Whitespace and Commentary from the Stylesheet

The tree representing the stylesheet is preprocessed as follows:

1. All comments and processing instructions are removed.

2. All xsl:note elements are removed, together with their content (see 3.13.2 The xsl:note element3.12.2 The xsl:note element3.13.23.12.2 The xsl:note element).

3. Any text nodes that are now adjacent to each other are merged.

4. Any whitespace text node that satisfies both the following conditions is removed from the tree:

   • The parent of the text node is not an xsl:text element

   • The text node does not have an ancestor element that has an xml:space attribute with a value of preserve, unless there is a closer ancestor element having an xml:space attribute with a value of default.

5. Any whitespace text node whose parent is one of the following elements is removed from the tree, regardless of any xml:space attributes:

   xsl:accumulator
xsl:analyze-string
xsl:apply-imports
xsl:apply-templates
xsl:attribute-set
xsl:call-template
xsl:character-map
xsl:choose
xsl:evaluate
xsl:fork
xsl:merge
xsl:merge-source
xsl:mode
xsl:next-iteration
xsl:next-match
xsl:override
xsl:package
xsl:stylesheet
xsl:switch
xsl:transform
xsl:use-package

6. Any whitespace text node whose immediate following-sibling node is an xsl:param or xsl:sort or xsl:context-item or xsl:on-completion element is removed from the tree, regardless of any xml:space attributes.

7. Any whitespace text node whose immediate preceding-sibling node is an xsl:catch element is removed from the tree, regardless of any xml:space attributes.

[ERR XTSE0260] Within an XSLT element that is required to be empty, any content other than comments or processing instructions, including any whitespace text node preserved using the xml:space="preserve" attribute, is a static error.