24532 2014-02-05 21:22:41 +0000 Streamability of NodeComp, before/after operator 2014-02-24 15:01:45 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Last Call drafts PC Windows NT CLOSED WORKSFORME P2 normal --- 1 abel.braaksma mike cmsmcq public-qt-comments oldest_to_newest 99828 0 abel.braaksma 2014-02-05 21:22:41 +0000 This is somewhat similar as the previous bug 24531. The same that was written there might apply here. In addition: How can a processor possibly check using forward-only streaming whether one node is before the other? There is only two situations using streaming nodes on both operands, that is currently streamable and that is when one of the operands is motionless and the other is consuming, or when both are motionless. a) foo >> bar b) foo[@bar << @zzz] c) @foo << bar d) foo << . e) ancestor-or-self::foo >> bar Hmm, while writing this down, I am finding out the obvious logic here: one of the nodes will always be in the current stack, which is always before any consuming expression. And if both are motionless, their relative position is known. Is this true always? Is there an easy proof for this? Common sense tells me this is correct, but still, I find operators << and >> to "feel" very free-ranging. 99892 1 mike 2014-02-06 10:41:50 +0000 I believe that document order on two nodes within a streamed document is perfectly well defined, and indeed it is fundamental to streaming that it should be well defined. We have however severely restricted the ability to process two nodes in a streamed document simultaneously, and therefore to ask questions about the relative order of two such nodes, because it's in the nature of streaming that we only process one node at a time. The expression (A << B) is disallowed (free-ranging) if A and B are both consuming or if either is free-ranging. But I think this leaves expressions like (.. << .) well defined and streamable. Indeed I think that (. << child::author) is probably permitted (and is consuming), provided there is only one author; though it's a pretty useless thing to write. 100373 2 cmsmcq 2014-02-12 09:48:16 +0000 The WG discussed this during the ftf meeting in Prague and decided that this issue is (as noted) essentially similar to bug 24531; we close it the same way.