[Bug 29670] [XSLT30] xsl:accumulator/ @initial-value accessing the global context item and streamability

https://www.w3.org/Bugs/Public/show_bug.cgi?id=29670

--- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Thanks, this does simplify matters.

> So an accumulator can reference the GCI only in the case where it is being 
> applied to the tree rooted at the GCI.
I don't think this is possible. Apparently, the GCI can only be accessed in
xsl:variable/xsl:param. Even if GCI == IMS, then still, from the point of view
of the spec, they are not the same.

This does create an edge-case scenario, though, which I am not sure we address
properly:

<xsl:global-context-item streamable="yes" />

<xsl:variable name="X" select="accumulator-before('acc')" />

<xsl:accumulator 
   name="acc" 
   initial-value="has-children()"
   streamable="yes">
   <xsl:accumulator-rule select="$value" />
</xsl:accumulator>

<xsl:template match="/">
   <xsl:value-of select="$X" />
</xsl:template>

What happens here is that $X uses fn:accumulator-before, which results in the
accumulator "acc" being applicable to the GCI (the real GCI, irrespective of
the IMS).

I am not sure this is (un)fortunate. As in this case both the xsl:variable and
the xsl:accumulator/@initial-value *MUST* be motionless/grounded. I don't think
it serves any practical use-case, but I think it is the only way to force an
accumulator on a streamed GCI, though this GCI cannot be consumed in any way.

In fact, that applies to any GCI that is a streamed node. It cannot be
consumed. Yes, if the IMS is the same (but we don't enforce, nor disallow them
to be node-identity equal) then you can argue that applying templates will
consume the GCI, but that is not what happens here.

This begs the question: if we can never consume a streamed GCI, should we
maintain all that machinery? I know that when we added it it seemed a good
idea, but perhaps we would do better to suggest GCI to be absent when IMS is a
streamed node.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Friday, 27 May 2016 17:21:06 UTC