No, you've got it completely the wrong way around! Saxon uses a
different data structure for RTFs from its normal tree model, and it's
this different data structure that has a bug in it!
Michael,
1) it was your words that the only thing node-set does is flipping
a bit.
2) i provided the test that shows that the same bug occurs whether
node-set is used or not on an RTF.
3) the code to build RTF creates a subclass of SingletonNodeSet,
FragmentValue; which is where the bug is.
4) exslt/Common.java contains the code which I think is used to implement
node-set, namely, method Common.nodeSet, which only calls allowGeneralUse
for instances of SingletonNodeSet; the full text of this method is here:
public void allowGeneralUse() {
generalUseAllowed = true;
}
Where SingletonNodeSet, used to build RTF and represent node-set after the
call to nodeSet is converted to a different structure?
But you can't prove anything from bugs, especially performance bugs.
They can happen anywhere at any time. This one happened because RTFs are
usually small, which meant that a scalability problem in this area
didn't show up in all the standard performance tests; the same bug in
the tree model used for input documents would have shown up very
quickly.
I am not proving, I am illustrating. And no, it didn't happen because of
incomplete or insufficient testing. It happened because there is not a single
word about required computational complexity of XSLT constructs. If the
spec said that adding a node to RTF must not be more complex than O(n),
it would not happen.
David Tolpin
http://davidashen.net/
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list