How Does Component Visibility Work in XSLT 3.0?

XSLT 3.0 introduces a modular packaging system via xsl:package that allows stylesheets to encapsulate code, prevent naming collisions, and control external access to their internal definitions. Component visibility determines whether components—such as templates, functions, variables, modes, keys, and attribute sets—can be referenced, overridden, or extended by importing stylesheets. By assigning visibility levels such as public, private, final, and abstract, developers can enforce strict interface contracts and maintain clean separation of concerns across complex transformation pipelines.

The Role of Packages in XSLT 3.0

Prior to XSLT 3.0, modularity relied on xsl:include and xsl:import, which merge declarations into a single flat namespace where global variables and templates can unintentionally collide.

An XSLT 3.0 package (<xsl:package>) operates as an independent compilation unit. Declarations within a package interact through well-defined interfaces. When a stylesheet imports a package using <xsl:use-package>, it can only see components explicitly exposed by that package. Visibility controls access boundaries both within the declaring package and across consuming packages.

The Core Visibility Levels

The visibility attribute can be applied directly to components or set as a default on <xsl:package>. The four primary visibility values function as follows:

1. private

A private component is strictly internal to the declaring package.

• It cannot be called or referenced by consuming stylesheets.
• It cannot be overridden by an importing package.
• It does not conflict with same-named components in other packages.
• If no visibility is explicitly stated, private is often the default state for many top-level components inside a package unless specified otherwise by package defaults.

2. public

A public component forms part of the package’s exposed interface.

• It is visible to any package that loads the declaring package via xsl:use-package.
• Consuming packages can invoke the component directly.
• Consuming packages have permission to override the component using <xsl:override> to customize or extend behavior.

3. final

A final component is visible externally but cannot be modified.

• Consuming packages can access and execute the component.
• Consuming packages are prohibited from overriding the component with <xsl:override>.
• Marking components as final guarantees deterministic behavior and prevents breaking changes in core library logic.

4. abstract

An abstract component defines a required contract without providing an implementation in the declaring package.

• The declaring package defines the component's signature (e.g., function arguments, template parameters, or mode declarations) but omits the body.
• Consuming packages must provide a concrete implementation using <xsl:override> before the package can be evaluated.
• If a package contains an abstract component that is not implemented by a consuming package or defined elsewhere in the inheritance chain, compilation fails.

Modifying Visibility with xsl:use-package

When a package consumes another package using <xsl:use-package>, it can alter the exposed components' visibility using child elements:

• <xsl:accept>: Re-exports or adjusts the visibility of components from the used package. For example, a consuming package can downgrade a public component to private to prevent downstream consumers from accessing it, or elevate an item from public to final.
• <xsl:override>: Supplies concrete implementations for abstract components or custom behavior for public components. Overriding a component allows the consuming package to replace template rules, functions, or variable values while retaining the original component's interface.

Supported Declarations

Visibility attributes are supported across major top-level XSLT declarations:

• Named and rule-based templates (xsl:template)
• Stylesheet functions (xsl:function)
• Global variables and parameters (xsl:variable, xsl:param)
• Modes (xsl:mode)
• Keys (xsl:key)
• Attribute sets (xsl:attribute-set)

By leveraging explicit visibility semantics, XSLT 3.0 packages enable true encapsulation, reusable component libraries, and safe, compile-time verified transformations.