This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29453 - [xslt30ts] package-019 - use package via xsl:include
Summary: [xslt30ts] package-019 - use package via xsl:include
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Candidate Recommendation
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-02-14 10:11 UTC by Michael Kay
Modified: 2016-10-06 18:42 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2016-02-14 10:11:44 UTC
Perhaps a spec issue, perhaps a test issue.

The spec says in 3.5.2:

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 in the package manifest of the first package.

This appears to prohibit what this test is attempting, which is to have the xsl:use-package declaration in an included module.
Comment 1 Michael Kay 2016-02-14 10:16:54 UTC
Also affects package-020X

Also, package-020c.xsl is referenced in test package-020c, but is not committed.
Comment 2 Michael Kay 2016-02-15 16:48:19 UTC
We decided that we should allow an xsl:use-package to appear within an included stylesheet module but not within an imported stylesheet module (to avoid any issues of multiple declarations with different precedence). A new error code needs to be defined.
Comment 3 Michael Kay 2016-02-19 12:51:19 UTC
The changes to the spec have been applied.
Comment 4 Max Toro 2016-03-02 15:43:15 UTC
It would be very helpful if you could elaborate on the import precedence issues, the spec already disallows declarations that are homonymous with accepted and overriding components.

Disallowing xsl:use-package on imported modules is a limitation for hiding complexity, imagine hundreds of stylesheets that import one common module, with this limitation all stylesheets need to be aware of and explicitly use a package.

Another argument is keeping xsl:use-package close to where the used package components are referenced, e.g. if the accepted components are used in an imported module and not the principal module.
Comment 5 Michael Kay 2016-03-02 15:54:57 UTC
In general if a declaration occurs in an imported module then it can always be overridden in an importing module. An xsl:import in an imported module imports declarations with different precedence from the same xsl:import appearing in an importing module, and similar rules apply to an xsl:include in an imported module.

We don't want to handle the complexity of use-package bringing components in at anything other than the highest import precedence of the using package, because the rules just get too complicated. We could define it so that xsl:use-package creates components at the highest import precedence regardless where it appears, but (a) that would be inconsistent with the usual behaviour of xsl:import, and (b) it would reduce our flexibility to introduce refinements in the future.

In the scenario you describe where hundreds of stylesheet use one common module, we would encourage you to turn that module into a package so that it can be separately compiled and reused. That's what packages are designed for.
Comment 6 Abel Braaksma 2016-05-26 15:48:22 UTC
For reference, the new error mentioned in comment 2 is:

[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.

(In reply to Michael Kay from comment #1)
> Also affects package-020X
> 
> Also, package-020c.xsl is referenced in test package-020c, but is not
> committed.
Changes have been applied to the tests and committed. New error code is now used for using xsl:import with an xsl:use-package element.