This is great news! Frankly I didn't expect this to happen until
sometime next week; great job Scott!
I was waiting for the DTM branch to become main trunk before doing any
work on the source document information (system id, line and column
numbers for the input XML document). Now that's almost complete I'll
get back to implementing it.
Thanks,
Ovidiu
On Mon, 11 Jun 2001 16:57:17 -0400, [EMAIL PROTECTED] wrote:
> Tomorrow I would like to move the DTM_EXP branch to the main branch. The
> branch is not absolutely perfect, but it's pretty damn good, and I think
> any final polishing should be done on the main branch. I would also like
> to get any ongoing bug fixes into the DTM version instead of the existing
> trunk.
>
> I expect that the first couple of days people might encounter some issues
> with extensions (a fair amount of *internal* api has changed), but I don't
> think we can discover these and resolve them one way or the other until we
> get it in the mainstream.
>
> I will branch the existing trunk, so that people can still work off that if
> they absolutely have to.
>
> I won't immediately merge any of the bug fixes from the last two weeks
> (since we last did a merge to DTM_EXP). Instead over the next couple of
> days we will merge any bugfixes in, or the bugfix authors can do it.
>
> The SQL extension will be broken to start out with. John Gentilin is
> working on this (I hope), and it should be functional within a week or two.
>
> In general the DTM work (not just the DTM, but all the work on the branch)
> provides faster performance and lower object garbage... though it is an
> ongoing battle. Brief summary of the work:
> 1) The DTM itself, which presents node identity as 32-bit integer handles.
> The DTM has many features, including direct character dispatch to SAX2,
> native DTM iterators and "traversers", multiple document management, etc.
> 2) Joe Kesselman's CoRoutine parsers, which are in a threaded SAX flavor
> and in a Xerces parseMore() flavor (no threads). These do away with the
> "race" conditions that occured in the original code, and should make Xalan
> much more robust.
> 3) *Much* more robust XPath itteration. The "waiting" iterators of old are
> no more, and good riddance. There is stil lots more we want to do with
> this mechanism. (There is something here called MatchIterators, but it's
> not being used yet for various reasons. We will be taking advantage of
> these down the line.)
> 4) A fair amount of XObject creation reduction. You can now get boolean,
> number, nodeset, and string values directly from an Expression, instead of
> going through an XObject.
> 5) XMLString, which makes it so we can have string objects that don't wrap
> Java's String object, but instead get their character data from an array or
> Fast String Buffer.
> 6) Serializers now only do internal buffering if they know they are writing
> to a FileStream.
> 7) The variable stack mechanism has been redisigned, so that it is no
> longer so interpretive, and is much more robust, I think.
> 8) Some small amount of stylesheet rewriting (but not yet redundent
> expression elimination), in particular to reduce full RTF creation and
> interpretation.
>
> Please let the list know if you have objections to moving this branch to
> the trunk tomorrow.
>
> -scott
>
>
>
>
