DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4546>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE.
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=4546 normalize-space does not properly handle text data ------- Additional Comments From [EMAIL PROTECTED] 2002-04-22 19:41 ------- Fix checked in. Chunk size range is set when the FastStringBuffer is created. Each FSB instance may set this differently, depending on which constructor was called and what parameters were supplied. Generally, the DTM implementation is responsible for setting these allocation parameters. SAX2DTM sets the initial chunk size at 10 bits, which comes out to 1024 characters per chunk. Other DTMs, such as the SQL extension, may be using other values. Due to some issues that arose in our support for variable chunk sizes -- specifically, the fact that we weren't responding correctly when appending content from a FastStringBuffer back into that same FSB -- we are currently forcing the size to a specific value. The code for this workaround is enabled by DEBUG_FORCE_FIXED_CHUNKSIZE. I suppose we should make it permanant at some point; the varying size was a nice idea, but if we aren't using it we probably shouldn't spend cycles on it. (We should also consider whether we want to update SAX2DTM to increase the minimum FSB chunk size, now that we've got the shared DTM code running for Result Tree Fragments and hence will tend to use these buffers more efficiently.)
