Carsten Heyl <[EMAIL PROTECTED]> wrote:
> I guess the limit is because of the way the integer handles are
used/generated?
Yes. 12 bits of doc identity and 20 bits of node identity. The XSLTC
DOMImpl is using 8/24 bits, which would put the limit at 255 docs but give
you 16,777,215 nodes per document, which is maybe more acceptable. Or, we
could compromise on 10/22, 1023 docs and 4,194,303 nodes. Or 9/23, 511
docs and 8,388,607 nodes. Opinions? (Remember that currently we are using
the same mechanism for result tree fragments... so each RTF is a document.
However, this may change soon [i.e. making RTF docs unmanaged], in which
case it would put less stringent requirements on the doc identity.)
For release 2.2.0 I would like to keep it as it is.
BTW, it may be possible in your case that the node identity will wrap, and
you'll see no ill effect if you're processing in incremental mode. (Not
very comforting, I know).
> Is it possible to pass "hints" via sax events or via xsl template to
"forget" certain parts
> of the tree? Possibly generating a runtime error if accessing them later
on?
This is something that I think Art Welch was going to work on, but I don't
think he has the cycles right now. This is definitely something we should
work on soon.
> But the main problem still exist:
> All nodes seems to be kept in memory when closing the transformer.
Hopefully within the next six months, we'll be able to detect when the
stylesheet is capable of being streamed, and not have to create the entire
source tree. This is a sort of holy grail for us.
-scott
