- From: <bugzilla@jessica.w3.org>
- Date: Fri, 27 May 2016 18:24:53 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29670 --- Comment #4 from Abel Braaksma <abel.braaksma@xs4all.nl> --- (In reply to Michael Kay from comment #3) > Yes, let's just say that the global context item cannot be a streamed node. > > Perhaps with a suggestion that when implementing a legacy API in which a > single "setSource" method has provided both the GCI and the IMS, our > recommendation is that when the supplied value is a streamed input source, > and the initial mode is streamable, then the supplied value should be used > to set the IMS, and the GCI should be absent. With the current rules for xsl:global-context-item this would work, as the default (if the declaration is absent) is type="item()" and use="optional". This would then, of course, cause a dynamic (!) error if you would try to access the GCI within xsl:variable/param etc, but that may be clearer than requiring motionless expressions (and it does *not* remove the ability to have the GCI set to a non-streamed document node, different from the IMS). The only use-case we subvert is where the programmer wants information on the input tree. But a workaround (which could go in a Note) is to use an accumulator that only operates on the document node of the input tree. What would happen if you access the GCI with a streamed accumulator, as in comment 2? I think the answer should be: it doesn't matter, as a streamed accumulator is equally applicable to non-streamed trees (but the inverse is not true). This would imply removing anything in the spec related to xsl:global-context-item/@streamable="yes". Considering the issues we have with "getting it right", I think that's a good thing ;). But is this an allowed change at this CR stage? -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 27 May 2016 18:24:56 UTC