DO NOT REPLY [Bug 26825] - DTM result set contains only one string with well-formed XML

[bu...@apache.org]

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=26825>.
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=26825

DTM result set contains only one string with well-formed XML





------- Additional Comments From keshlam@us.ibm.com  2004-02-10 19:19 -------
I haven't dug into this, but some semi-informed speculation on what's going on...

The SQL extension uses its own -- partial -- implementation of DTM. (It
minimizes memory use by discarding subtrees as you move through the query
result.) This means that certain DTM operations don't work -- you don't have
full freedom to navigate the query's response.

I am guessing that one of the features which isn't implemented is the ability to
navigate back from one of these DTM instances to the DTMManager in order to
request a new Temporary Tree/Result Tree Fragment -- which would actually want
to be passed back to a more general implementation of DTM. It *is*
architecturally possible to have a DTM which isn't bound to a DTMManager, but
that's become an unusual situation.

So the question is whether to fix the SQL extension to be able to retrieve a new
DTM, or to rearchitect how Xalan is instantiating temporary trees so they don't
discuss this request with the current source document at all. The latter might
be architecturally cleaner but -- again, just at a guess -- I suspect it would
require pretty substanial changes to the way we're passing data through Xalan.

There's a related issue outstanding against some experimental XSLTC changes I've
been working with, for whatever that's worth, so resolving one might help
both... but that isn't on the top of my own priority queue right now.