[Bug 24506] Standard attributes are missing in streamability analysis

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

Abel Braaksma <abel.braaksma@xs4all.nl> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |REOPENED
         Resolution|WORKSFORME                  |---

--- Comment #5 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
Unfortunately, I have to reopen this bug. There is one standard attribute,
while not an operand, that does influence streamability: [xsl:]version.

Currently, we don't say anything about backwards compatibility processing and
streaming. But certain XPath expressions work differently when the effective
version of a construct is 1.0. For as far as I can see, it actually works in
favor or streamability: more expressions are streamable in 1.0 mode than in
other modes.

Take for instance a crawling expression and put it in an absorption context,
like string(a//b). In 3.0 (and 2.0) mode, this is not streamable (and will
likely raise a runtime error). In 1.0 mode, it is streamable, because the first
element will be returned.

I do not suggest we expand our rules for the odd case that someone chooses
XPath backwards compatibility mode on streamable expressions, but I do think we
should say something about it. My proposal would be to add a note, something
along those lines:

Note:
This section does not attempt to define streamability rules for constructs that
operate in XPath 1.0 backwards compatibility mode. It is believed that the
rules in this section apply both to 1.0 backwards compatibility and normal
processing, however, behavior under 1.0 backwards compatibility is considered
implementation defined. This allows, for instance, for implementations to
optimize expressions such as string(a//c) and make them streamable under 1.0
processing, because it is known at compile time that a//c will always only
return the first matching node.

See also bug 25185, which, if accepted, would automatically allow this
optimization without having to take into account backwards compatibility
behavior.

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

Received on Thursday, 27 March 2014 23:41:31 UTC