RE: Using a Xalan Node, bridged from Xerces, as an input to an XSL Transformation

[David N Bertoni/Cambridge/IBM <da...@us.ibm.com>]

> > I'm willing to believe that serialization is much faster, but what is
the
> > cost of making the clone?  It must be pretty high.
>
> Yes, the creation of the clone is quite expensive, but we will be
serializing
> our documents every time we create > them and the sum of cloning and
serialization
> is less than no clone and serialization (if I remember correctly, I
believe the
> cloning case took about 75% as long as the non cloning case when the
entire XML
> document was serialized)

OK, if you've tested it, then I believe you.  It just surprises me.  You
might also want
to consider using the Xerces serializer.

> > Another option would be to walk the Xerces DOM_Document and build an
> > instance of Xalan's source tree from it.  That's much faster than
serializing and
> > parsing.  And there are classes designed to do that without writing too
much code.
>
> So, walking the Xerces DOM_Document is preferrable to the following?
>
>                 XercesDOMSupport             domSupport;
>                 XercesParserLiaison          parserLiaison(domSupport);
>
>                 XalanDocument* const         newXalanDoc = parserLiaison.
createDocument(xercesDoc);
>                 XercesDocumentBridge        *bridge = parserLiaison.
mapDocument(newXalanDoc);
>

Yes, absolutely.  Drastically faster and simpler.

> Is the usage pattern for walking the Xerces tree similar to the
serialization
> with FormatterTreeWalker?

Yes, in theory, but there isn't a class that will do it with the new source
tree.
I'll try to put one and together and put it into CVS.  It should be
available in
the next release.  In the meantime, you could get the code from the
repository
and build it into your version, or just get the latest code.  The only
drawback
is that any ID attributes would not be preserved as ID attributes.  Are you
using
the id() function in your stylesheets?

> I apologize for my ignorance here, but I can not find an example of this
in the docs,
> nor can I find anything in the mail list archives.  Could someone point
me to the classes
> to look at?  Our goal is to not have to re-serialize the Tree in order to
perform a
> transformation, so if this allows us to do that, it would meet our needs
perfectly.
>

There probably isn't one, so no need to apologize.

> > Are you saying you want to start a transformation at a particular node?
> > That would be possible with an enhancement that allows you to specify
both the input
> > document and the initial context node for the transformation.  That's
pretty easy to do.
>
> Great, so the API will be similar to the Xpath Evaluation API?

It would be an optional 4th parameter to the appropriate XalanTransform::
transform()
overloads.

> > If you are in a situation where the tree will be modified between
> > transformations, that becomes very inefficient, as Xalan expects the
source tree to by immutable,
> > so the wrapper (XercesDocumentBridge) does not work when you modify the
document between
> > transformations.  The end result is that you need to destroy and
rebuild the bridge every
> > time you modify the underlying Xerces document.

> No, we will not be modifying the tree after it has been initially created
with Xerces.
> From reading the mail archives, it has been made very clear that Xalan
should not be
> used to modify the tree, so we understood that before trying to use the
Xalan Tree.

That's good.  I will work on the TreeWalker derivative that can convert the
Xerces DOM into
a new instance of the source tree.  You might want to subscribe to the CVS
mailing list
to watch for it.  Or, you could post an inquiry on the list to get the
status.

Dave