XSLT 3.0 Packages Michael H. Kay

XSLT 3.0 Themes Streaming –support for large documents Packaging –support for large (sets of) stylesheets Maps –support for complex data structures

Why are XSLT packages needed? DocBook –230K lines, 357 modules QTspecs –88K lines, 238 modules DITA Open Toolkit –75K lines, 255 modules TEI –101K lines, 313 modules A scientific publishing platform –100K lines, 120 modules 3

Potential benefits Software engineering benefits –Information hiding / abstraction –Easier debugging –Better potential for change –Greater reuse Commercial benefits –Ability to distribute libraries without revealing source code Performance benefits –Separate compilation of modules –Memory savings 4

Limitations of xsl:include / xsl:import Everything is global –makes change difficult –can't "black-box" a stylesheet e.g. to create a pipeline controlled from XSLT No constraints on overriding –signature may be incompatible Can't override one component in two different ways Very difficult to find anything in the source code 5

Separate Compilation To compile a module you need to know about its dependencies –e.g. types of variables and functions With xsl:import / xsl:include: –there may be a call to a function (or template or variable) that's not declared –if there is a declaration, it can be overridden in arbitrary ways 6

Terminology Package –A collection of stylesheet modules linked using xsl:include and xsl:import Component –A named template, named mode, function, global variable, attribute set etc Symbolic Reference –A call-template, function call, variable reference etc P uses Q –Package P contains symbolic references to components declared in Package Q

Component Visibility Components can be declared: –public (visible and overridable in a using package) –private (not visible, not overridable) –final (visible but not overridable) –abstract (visible, must be overridden) Visibility can be: –explicit –defaulted at package level

Package Manifest xsl:package element –defines package name and version –defines dependencies on used packages including optional overrides –links to, or contains top-level xsl:stylesheet module –defines what it exposes to using packages (its public interface) – xsl:expose

example

Overriding Named Components Component must be public or abstract Signature must be compatible Overriding component is private to the using package –unless exposed Overriding declaration must appear within xsl:override element in the package manifest Overriding component can invoke the overridden component using xsl:original

Component Binding A (public) B (private) C (abstract) Package Q A (private) B (hidden) C (private) Package P uses exposesoverrides

Multiple overrides A (public) B (private) C (abstract) Package B A1A1 B1B1 C1C1 P uses exposesoverrides A2A2 B2B2 C2C2 Q uses

Template Rules and Packages Template Rules belong to a mode Default mode can be defined for a module A mode has visibility: –private: templates can't be invoked from using package –final: templates can be invoked but can't be overridden –public: templates can be invoked and overridden

Other Declarations Keys, decimal formats, and namespace aliases are local to a package xsl:strip-space and xsl:preserve- space are local to a package (affect doc() calls in that package) xsl:output is local to a package (affects xsl:result-document calls in that package) stylesheet parameters (xsl:param) must be public (but can be overridden by a private xsl:variable in a using package)

Conclusion XSLT 3.0 Packages –software engineering quality –code reuse –ease of debugging –IP protection –reduce compilation overhead 16