[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: "Dimitre Novatchev dnovatchev@xxxxxxxxx" <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 11 Nov 2014 15:02:54 -0000

 Thank you, Abel,

This all makes sense except the confusing point that anything at all
should be exposed in a "package" that is not intended to be used by
other packages.

Unless we consider a command-line invocation as "using-package".

Cheers,
Dimitre

On Tue, Nov 11, 2014 at 3:28 AM, Abel Braaksma (Exselt)
abel@xxxxxxxxxx <xsl-list-service@xxxxxxxxxxxxxxxxxxxxxx> wrote:
>>
>> 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
any
>> 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
package).
>
> 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:
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27300.
>
>>
>> 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."
>
> and:
> "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."
>
> Cheers,
>
> Abel Braaksma
> Exselt XSLT 3.0 streaming processor
> http://exselt.net


Current Thread
Keywords