RE: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span

Subject: RE: [xsl] Normalize / Simplify HTML-Tables with row-span / col-span
From: David Tolpin <dvd@xxxxxxxxxxxxxx>
Date: Wed, 18 Feb 2004 19:34:16 +0400 (AMT)
> 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


Current Thread