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 28129 - [xslt 3.0] xsl:global-context-item/@use-accumulators
Summary: [xslt 3.0] xsl:global-context-item/@use-accumulators
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
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: 2015-03-03 12:35 UTC by Michael Kay
Modified: 2015-10-29 09:50 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2015-03-03 12:35:22 UTC
The text in 3.6.6 shows that the attribute use-accumulators is permitted on xsl:global-context-item, but gives no hint of its meaning. All is explained in section 18.2.2.

Section 3.6.6 should therefore refer to 18.2.2 for the explanation.

Note also, 18.2.2 on one occasion refers to the attribute incorrectly as "use-accumulator".
Comment 1 Michael Kay 2015-03-03 14:11:37 UTC
On a related topic, but more substantively...

I started changing the streaming accumulator tests to add an xsl:global-context-item declaration to state that the accumulator was used for the streamed input document. But this cannot be done without also adding an xsl:package at the outermost level of the stylesheet.

This seems unnecessary and inconvenient.

I propose we drop the rule that xsl:global-context-item requires an explicit xsl:package as its parent. Instead we should have the rules:

(a) it can only appear once within a stylesheet module

(b) it is an error if it appears in an included or imported stylesheet module unless an equivalent declaration appears in the top-level module of the package.
Comment 2 Abel Braaksma 2015-03-13 17:13:19 UTC
I think the issue discussed in comment#1 is a result of merging xsl:package and xsl:stylesheet/transform into one top-level element, as proposed and implemented as a result of Bug 26468. From that bug's resolution:

<quote>
1. xsl:package has the same content model as xsl:stylesheet/transform, with the addition that it allows xsl:expose and xsl:use-package elements to appear as children (in any position).
</quote>

It appears to me that we simply forgot to allow xsl:global-context-item as a child of xsl:stylesheet. It makes sense to put it there, as a stylesheet with an xsl:stylesheet root is still a (simplified) package.

> (b) it is an error if it appears in an included or imported stylesheet 
> module unless an equivalent declaration appears in the top-level module 
> of the package.

I think we should always consider it an error. I can't think of a use-case why we should allow it in an imported module. It is a feature of packages, there are not XSLT 2.0 stylesheets around with such a declaration so there's no backwards compatibility issue, and if someone wants to import that declaration, he or she should create a package (by replacing xsl:stylesheet with xsl:package and use xsl:use-package instead).

Another argument against this is that *only* the principal stylesheet is a simplified package, the imported or included modules are not, so they should not contain features that are only available with packages.
Comment 3 Abel Braaksma 2015-04-05 14:57:44 UTC
Additional (editorial) note on section 18.2.2, we say that @use-accumulator has no effect when streaming is not specified, but we do not say whether or not it is parsed. In other words, is use-accumulator="no-existing-accum" always an error, or only when streaming is specified and the accumulator indeed does not exist in scope?
Comment 4 Michael Kay 2015-04-16 21:53:12 UTC
The proposal was largely accepted (see today's minutes for details) and I have implemented it, though with a little editorial license:

(a) I defined the rules for consistency between different xsl:global-context-item declarations within a single package; I did not impose the rule (suggested in comment 1) that one of those declarations must appear in the top-level module.

(b) As far as I can see the rules in 18.2.2 for static validity of the attribute are clear, so I made no changes.

(c) I extended the scope of error 3300 to cover additional error conditions implied by the prose.