[Bug 24543] New: Supplying a streamable initial context item on a non-streamable initial mode

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
12 messages Options
Reply | Threaded
Open this post in threaded view
|

[Bug 24543] New: Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

            Bug ID: 24543
           Summary: Supplying a streamable initial context item on a
                    non-streamable initial mode
           Product: XPath / XQuery / XSLT
           Version: Last Call drafts
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: minor
          Priority: P2
         Component: XSLT 3.0
          Assignee: [hidden email]
          Reporter: [hidden email]
        QA Contact: [hidden email]

Under 6.6.3 Streamable Templates
(http://www.w3.org/TR/xslt-30/#streamable-templates), the fifth paragraph
(right before the Note), we write:

"Alternatively, streamed processing may be initiated by invoking the
transformation with an initial mode declared as streamable, while supplying the
initial context item (in an implementation-defined way) as a streamed
document."

It occurred to me that we never mention the reverse. What happens when the
initial context item is provided in a streaming way, and the initial mode is
not streamable?

I think the answer should be: it is implementation defined. Not sure we should
do something here, but it is clearly an error case if the stylesheet expects to
be non-streaming, but receives a streaming node.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #1 from Abel Braaksma <[hidden email]> ---
This also relates to another section, the 2nd paragraph before 6.6.2 Using
Modes (http://www.w3.org/TR/xslt-30/#using-modes):

"If the initial context item supplied to a stylesheet is a streamed document
node, then it is not permitted for the values of global variables to be
dependent on the context item in a way that requires reading of the input
stream. This constraint is enforced by the following static rule:"

The start of this sentence should probably be "If the initial context item
supplied to a stylesheet is a streamed document node and the initial mode is
declared streamable [...]"

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #2 from Michael Kay <[hidden email]> ---
>it is clearly an error case if the stylesheet expects to
be non-streaming, but receives a streaming node.

It doesn't feel like an error to me; it feels like normal operation. The
processor can always build a tree from the supplied stream, and then do a
normal non-streaming transformation on this tree.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

C. M. Sperberg-McQueen <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |[hidden email]
         Resolution|---                         |FIXED

--- Comment #3 from C. M. Sperberg-McQueen <[hidden email]> ---
We discussed this issue briefly in Prague and concluded that some
implementations might indeed have trouble with the situation described, but
that others might be well able to handle it.  In view of the latter, most of
the WG was disinclined to introduce an error for the situation.  (Processors
which need to can of course issue their own message.)

The WG accepted comment 1.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |---

--- Comment #4 from Michael Kay <[hidden email]> ---
I want to push back on the change proposed in comment 1.

Initialisation of global variables logically happens during the "priming" of a
stylesheet, at which point the initial mode is not known. In fact a stylesheet
might be primed once and then used several times with different initial modes.
Also, the document supplied as the "initial input" to be processed using the
initial mode might not be the same as the document containing the initial
context item for evaluating variables.

I'm not sure of the best way forward here.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #5 from Abel Braaksma <[hidden email]> ---
Indeed, there seems to be a conflict between priming the stylesheet and
initializing global variables and parameters. Currently, I see only one way
forward:

Defer the analysis of streamable global variables to the point where they are
used. This analysis could subsequently be simplified if we add an attribute
streamable=yes|no to the xsl:variable and xsl:param declarations, comparable to
their use on xsl:attribute-set and xsl:accumulator.

Consequently, global variables can reference the initial context item and the
problem with whether the mode is streamable or not will go away. The rules on
VarRef in 19.8.7.10 can be extended to include a rule similar to:

4. if V is a reference to a global variable that has the effective value of the
streamable attribute set to "no", then roaming and free-ranging.

5. Otherwise, the sweep of the expression is grounded and motionless.

Under global variables, a new section could be added that explains what a
streamable global variable is, and what rules it should obey to (basically,
result posture must be grounded, and the select expression or seqtor must be
motionless).

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #6 from Michael Kay <[hidden email]> ---
Actually, I think that given the separation of the "initial context item"
(which I would like to call "global context item") used for initializing global
variables, and the "initial input sequence" (which I would like to call
something like "initial match selection") used for the apply-templates
stylesheet entry point, the problem largely disappears.

The rule is simply that the global context item will never be a streamed node.
It's up to the API design to ensure this; if something like a StreamSource or
File is supplied, the API will typically build an in-memory tree. There is no
longer any interference with the "initial input sequence", except for a legacy
API that tries to set both to the same thing.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #7 from Michael Kay <[hidden email]> ---
Reviewed briefly on 3 Jul 2014. We need to outline the technical options and
choose between them: either we should allow the global context item to be a
streamed node (in which case we need rules saying global varaibles must be
motionless), or we should disallow it.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #8 from Michael Kay <[hidden email]> ---
I propose we resolve this as follows:

Add the attribute streamable="yes|no" (default "no") to the
xsl:global-context-item element. If the value "yes" is specified, then (a) the
"as" attribute must take the form as="document-node()" or
as="document-node(XXX)", and (b) the select expression or contained sequence
constructor of every global xsl:variable and xsl:param declaration in the
containing package must be motionless. If the value "no" is specified, 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.)

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

--- Comment #9 from Abel Braaksma <[hidden email]> ---
Yes, I think that would work and solve the issues with
xsl:accumulator/@initial-value and global params/variables.

I'm not sure we need to restrict the type, though. If the type is a non-node,
streamable="yes" simply has no effect and every initializing expression is
grounded by default (i.e., type-determined context posture). If the type is not
a document node, it can still be streamable="yes", because the rule for
allowing expressions such as "/" or "root()" already says "if the context item
is statically known to be a document node" (see 19.8.8.15), and will statically
(and correctly) fail.

Still, if as="element()" you can do expressions such as base-uri(.) or
ancestor-or-self::*/name(), which are motionless.

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] [XSLT30] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #10 from Michael Kay <[hidden email]> ---
Resolution:

Add the attribute streamable="yes|no" (default "no") to the
xsl:global-context-item element.

If the value "yes" is specified, then the select expression or contained
sequence constructor of every global xsl:variable and xsl:param declaration in
the containing package must be grounded and motionless (assessed with a context
posture of striding, and a context item type based on the declared type of the
global context item).

If the value "no" is specified, 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.)

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

Reply | Threaded
Open this post in threaded view
|

[Bug 24543] [XSLT30] Supplying a streamable initial context item on a non-streamable initial mode

Bugzilla from bugzilla@jessica.w3.org
In reply to this post by Bugzilla from bugzilla@jessica.w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24543

Michael Kay <[hidden email]> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #11 from Michael Kay <[hidden email]> ---
The agreed changes have been applied to the spec.

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