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 27015 - [xslt 3.0] xsl:context-item/@use = "prohibited": detailed wording
Summary: [xslt 3.0] xsl:context-item/@use = "prohibited": detailed wording
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Working 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: 2014-10-10 09:45 UTC by Michael Kay
Modified: 2015-10-29 09:50 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2014-10-10 09:45:50 UTC
The wording of the rule for @use="prohibited" is rather fuzzy:

If the value prohibited is specified, then there will be no context item available to the body template (if the calling template has a context item, it will not be made available to the called template).

(a) it doesn't mention what happens to position() or last()

(b) it assumes there is a calling template

Propose instead:

If the value prohibited is specified, then the contained sequence constructor, and any xsl:param elements, are evaluated with an absent focus. 

Note: it is not an error to call such a template with a non-absent focus; the context item is simply treated as absent. This option is useful when streaming, since an xsl:call-template instruction may become streamable if the referenced template is declared to make no use of the context item.
Comment 1 Michael Kay 2014-10-13 09:21:41 UTC
There's a similar problem for xsl:global-context-item. It says "If the value prohibited is specified, then the global context item must be absent." This doesn't really indicate if we expect a dynamic error in this case (and what error?), or if we expect the supplied global context item to be ignored. One could say that the decision between the two is a matter of API design and therefore out of scope. The analogy with xsl:context-item would suggest ignoring the supplied context item rather than throwing an error. This also might be appropriate given the existence of legacy APIs that supply a context item and an initial match selection in the same breath.
Comment 2 Michael Kay 2014-12-12 17:59:14 UTC
This was discussed by the WG on 13 Nov 2014, but the minutes of that meeting were accidentally lost, so the decision needs reconfirming. According to the editor's notes, the WG agreed to resolve the issue as proposed in 

https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Nov/0013.html

(member-only link)
Comment 3 Michael Kay 2014-12-18 21:19:15 UTC
The WG confirmed its decision to resolve this issue as proposed in 

https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Nov/0013.html