This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Since we have established that node identity of a streaming node is not deterministic, due to the fact that streaming itself is not deterministic, how do we determine node identity? Should we not simply prohibit node identity checks? It seems odd that we allow an instruction like <xsl:value-of select=". is ." /> to return false. However, due to the lacking determinism, this is possible. Along the same lines, if processors do not have a good way of checking node identity, they may resort to deep-equal comparison, which would end up consuming (I think we should prohibit this kind of operation). Perhaps we should be much cruder than we currently are and say that node identity comparison in a streaming environment is always false? This would prevent differences between processors, and might be too far-fetched, but at least it would be stable. Or forbid its use in streaming scenarios, so as not to tempt people from using it.
>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.
The WG discussed this during the ftf meeting in Prague. There was some sentiment that the material in comment 1 might make a useful Note at an appropriate location in the document.
A suitable Note has been added to the spec.