This doesn't sound like a limit with the number of nodes.  Rather, it
sounds like a limit with the number of unique string indexes, perhaps for
attribute values?

There is certainly a limit to the number of unique element names... 32K (16
bits), and the number of unique namespaces is limited to 1023 (10 bits).  I
wouldn't think that this would be a problem.

This is more likely a bug with a trick done with attribute values where a
negative value is used to indicate that the value lives in another table?

-scott




                                                                                       
                               
                    Joseph_Kesselman                                                   
                               
                    @lotus.com              To:     [EMAIL PROTECTED]           
                               
                                            cc:     (bcc: Scott Boag/CAM/Lotus)        
                               
                    07/17/01 11:28          Subject:     Re: String indexoutof range 
exception                        
                    AM                                                                 
                               
                    Please respond                                                     
                               
                    to xalan-dev                                                       
                               
                                                                                       
                               
                                                                                       
                               





The DTM model can indeed run out of space if a source document is too
large. Currently we allocate 20 bits for node addressing, so we can handle
about a million nodes. Beyond that we'll fail, probably nondiagnostically.
We're considering increasing that, though doing so will impose tighter
limits on how many documents a given DTMManager can keep track of
simultaneously. We could remove the restriction by switching to longs as
our basic node ID type, but that would increase storage and processing

The size of _text_ nodes shouldn't be a problem... I think.

Could you show us a complete stack trace of the exception, so we can
investigate where the problem is occurring?





Reply via email to