[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] [XSLT 3.0] Question about the simplified syntax of a package

Subject: Re: [xsl] [XSLT 3.0] Question about the simplified syntax of a package
From: "Abel Braaksma (Exselt) abel@xxxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 11 Nov 2014 11:28:49 -0000

> 1. As we see from the code above, only modes and named templates will be
> exposed in the equivalent xsl:package.
> Is it correct to conclude that if the principal stylesheet module contains
> components of type: function, attribute-set, accumulator, keys and global
> variables / parameters, these are not exposed and cannot be accessed from
> a using package? If so, what was the reason for this decision?

Keys are never exposed, they are always local, non-static parameters are
always global, static params are always local (visible only to the containing

I am not sure why the rest (functions, accumulators, global variables) are not
getting a default visibility of "public". The reasoning for xsl:mode and
xsl:template being public is that in XSLT 2.0, these components were visible
to the caller of the stylesheet (i.e., from commandline or programming
interface). However, since in XSLT 3.0 you can have an initial function, I'd
say that functions should be public as well. Officially, accumulators and
variables cannot be set by the caller, so it does not seem to make sense to
make them public as well.

Reading through this bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=24307
shows the reflection of a discussion where templates, functions and modes are
mentioned as implicitly public. From that, it seems indeed an omission (unless
another bug covered the function situation, but I could not find it).

Another thought that comes to mind is that with the resolution of bug
https://www.w3.org/Bugs/Public/show_bug.cgi?id=26468, there is no real need to
make XSLT 3.0 components (including initial functions) implicitly public, all
you need to do is change your XSLT 3.0 stylesheet root element into
xsl:package and add a name attribute.

I raised a new bug here to reflect your concerns:

> 2. Because the produced by the transformation above equivalent package
> doesn't have any "name" or "package-version" attributes specified, how
> should an <xsl:use-package> in a using package reference the package
> generated by the transformation?

You cannot reference a simplified package, this transformation is in place for
backwards compatibility, turning existing XSLT 2.0 stylesheets into packages
(as in "everything is a package" in XSLT 3.0), so the @name and
@package-version do not make sense. Simplified packages can only be used as
principal (or "top level", as opposed to "library") package. It fits with the
following two rules in section 3.6 Packages:

"A package typically has a name, given in its name attribute, which must be an
absolute URI. Unnamed packages are allowed, but they can only be used as the
"top level" of an application; they cannot be the target of an xsl:use-package
declaration in another package."

"A package may have a version identifier, given in its package-version
attribute. This is used to distinguish different versions of a package. The
value of the version attribute, after trimming leading and trailing
whitespace, must conform to the syntax given in 3.6.1 Versions of a Package.
If no version number is specified for a package, version 1 is assumed."


Abel Braaksma
Exselt XSLT 3.0 streaming processor

Current Thread