- From: <bugzilla@jessica.w3.org>
- Date: Thu, 12 May 2016 11:23:59 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29499 --- 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 roaming/free-ranging. Yes. b) xsl:variable/param are not in effect, they do not access the initial match selection. 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 supported. 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 one. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Thursday, 12 May 2016 11:24:02 UTC