W3C home > Mailing lists > Public > public-qt-comments@w3.org > May 2016

[Bug 29499] [XSLT30] Global xsl:variable/xsl:param not in streamability rules

From: <bugzilla@jessica.w3.org>
Date: Thu, 12 May 2016 11:23:59 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29499-523-8eMIqUW5GI@http.www.w3.org/Bugs/Public/>

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
Addressing comment #2:

Situation 1: request streamed processing with initial match selection as a
streamed node.

a) xsl:key, through the key-function can be non-motionless. I think this is
guarded by fn:key(A, A, N), which effectively makes *any* use of keys


b) xsl:variable/param are not in effect, they do not access the initial match

I don't understand what you mean by "not in effect". I don't think there is a
problem here.

Situation 2: request streamed processing with global context item (not
xsl:global-context-item) set to a streamed node, I believe this is allowed and

a) xsl:variable can access the streamed global context item, i.e. <xsl:variable
name="n" select="." />

3.5.6 says: If the [xsl:global-context-item/@streamable] attribute is absent or
has the value no, or if there is no xsl:global-context-item declaration, then
when the transformation is primed, the item supplied as the global context item
cannot be a node in a streamed document (the transformation API may handle this
either by disallowing such an input, or by building the corresponding tree in
memory and supplying the global context item as an unstreamed node.)

So xsl:variable can access the streamed global context item only if
xsl:global-context-item/@streamable = 'yes', and in that case the variable must
be grounded an motionless, so in effect it can inspect the global context item
but cannot consume it.

b) xsl:param can also access it, but this can be overridden by a supplied
parameter, which the API may set to something unstreamed, but that can only be
detected *after* the static phase, at the priming phase.

The rule for xsl:param is exactly the same as xsl:variable.

Situation 3: streamed variables that are not used, may they be ignored? We
don't allow this with xsl:variable instructions, though it makes sense to allow
it with either, but as an implementation-defined leniency towards the "must
throw an error if not guaranteed streamable" rule.

The rules in 3.5.6 as written apply to all global variables/params whether they
are referenced or not. I would prefer not to make the rules more complicated
without a compelling use case.

Situation 4: import-precedence kicking in, i.e. a variable that would be
illegal at lower precedence, but legal through a higher-precedence override.
Same may be true for xsl:function and xsl:accumulator, I didn't check what we
say about this.

Again, the rules in 3.5.6 as written apply to all global variables/params
whether they are overridden or not. I can see a use-case here which is that you
might want to override a non-streamable variable declaration with a streamable

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 12 May 2016 11:24:02 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 May 2016 11:24:02 UTC