27015 2014-10-10 09:45:50 +0000 [xslt 3.0] xsl:context-item/@use = "prohibited": detailed wording 2015-10-29 09:50:44 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Working drafts PC All CLOSED FIXED P2 normal --- 1 mike mike public-qt-comments oldest_to_newest 112944 0 mike 2014-10-10 09:45:50 +0000 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. 113014 1 mike 2014-10-13 09:21:41 +0000 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. 116231 2 mike 2014-12-12 17:59:14 +0000 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) 116517 3 mike 2014-12-18 21:19:15 +0000 The WG confirmed its decision to resolve this issue as proposed in https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Nov/0013.html