- From: <bugzilla@jessica.w3.org>
- Date: Mon, 22 Feb 2016 16:02:03 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29499 --- Comment #2 from Abel Braaksma <abel.braaksma@xs4all.nl> --- I didn't find that rule previously, thanks. I see a few caveats and I'm not sure we handle / guard them well. 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 roaming/free-ranging. b) xsl:variable/param are not in effect, they do not access the initial match selection. 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 supported. a) xsl:variable can access the streamed global context item, i.e. <xsl:variable name="n" select="." /> 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. 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. 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. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Monday, 22 February 2016 16:02:07 UTC