[Bug 24531] Streamability of NodeComp, is operator

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

--- Comment #1 from Michael Kay <mike@saxonica.com> ---
>Since we have established that node identity of a streaming node is not deterministic

I don't think that's the case.

What we actually say is:

Specifically, if the xsl:stream instruction is evaluated several times (or if
different xsl:stream instructions are evaluated) with the same URI (after
making it absolute) as the value of the href attribute, it is
implementation-dependent whether the same nodes or different nodes are returned
on each occasion; it is also possible that the actual document content will be
different.

However, the document that is processed by an invocation of xsl:stream conforms
to the XDM data model, which means that its nodes have identity and that they
follow the usual rules for document order. This means for example that

.. is parent::x

will return true if and only if the context item has a parent element whose
name is x. It also means that (. is .) is true so long as a context item
actually exists.

Similarly (.. << .) is true so long as the context item exists and has a
parent; this follows from the rules in XDM and we have said nothing to imply
that these rules do not apply.

An "is" comparison between two nodes in different documents is always false,
and this applies even when one (or both) of the documents is streamed. Equally,
a "<<" comparison between two nodes in different documents is always
implementation-defined, and this again remains the case when one or both
documents is streamed.

I believe it is not actually possible to use these operators to compare two
nodes in different streamed documents, since we don't allow binding of
variables to nodes in streamed documents. However, identity of such nodes can
be compared using generate-id() The one respect in which node identity is
different for streamed documents is that we explicitly leave it
implementation-defined whether two calls on xsl:stream with the same URI return
the same document or different documents.

Equally, it's not possible to use these operators to compare two nodes in the
same streamed document unless one is reached by a "climbing" expression from
the other (as in the examples above). But the fact that you can't actually get
a handle on two nodes to ask them how they relate doesn't mean the relationship
doesn't exist or that it is indeterminate; it's fundamental, for example that
select="author" processes the child author elements in document order, and that
document order therefore needs to be well defined for streamed nodes.

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

Received on Thursday, 6 February 2014 10:27:09 UTC