[
Lists Home |
Date Index |
Thread Index
]
??? JAXP is a factory interface, there is no underlying XSLT
processor... the XSLT processor is unknown to JAXP until runtime and
is set via a system property to the value of a processor specific
JAXP-compliant TransformerFactory instance... in essence its just a
big phat wrapper for any processor who wants to take advantage of
providing a common transformation interface and as such allowing the
developer to pick and choose between processors, changing only the
system property value to implement a new processor... Are you stating
that the Gnu project has taken things one step further and provided a
default XSLT processor if one is not set by the developer?
It would make sense to do this and if libxslt is the underlying engine
then I can see why the enormous gains in performance compared to
Xalan. But in the same way Xalan or Saxon supports the JAXP interface
you could make the same claims regarding DOM usage ... in reality
though whats passed via JAXP to the processors TransformerFactory
method is not whats being used on the inside of the process which, in
all cases that I am aware of, take whats given them and create an
optimized tree structure that has nothing to do with SAX or DOM and
everything to do with a model that fits well into the XSLT way of
processing things...
I realize that Sun has taken matters into their own hands and with
Tiger have integrated Xalan into the default classpath distribution
(along with JAXP) ... Is this what the Gnu project has done as well?
If so, I think thats fantastic! I guess maybe I need to pay more
attention to the Gnu classpath project... and I thought I already was!
:)
Cheers :)
<M:D/>
On Mon, 28 Mar 2005 09:33:26 +0100, Chris Burdess <dog@bluezoo.org> wrote:
> Michael Kay wrote:
> >> What kind of parser is best to use for XSLT transformations ?
> >> SAX or DOM
> >
> > XSLT processors will in general build a tree representation of the
> > source
> > document in memory. And in general, many of them will build a tree
> > representation that is much more efficient than using a
> > general-purpose DOM.
> > So there's no point building an inefficient DOM tree rather than
> > letting the
> > XSLT processor build its own. But this advice may depend on the XSLT
> > processor you are using.
>
> For what it's worth, the GNU JAXP XSLT processor uses DOM internally
> for both source and result trees, and is about 2.8 times as fast as
> Xalan on a wide range of transformations (the OASIS XSLT/XPath
> conformance suite). I don't have figures for memory usage or
> comparisons with Saxon though.
> --
> Chris Burdess
>
>
> -----------------------------------------------------------------
> The xml-dev list is sponsored by XML.org <http://www.xml.org>, an
> initiative of OASIS <http://www.oasis-open.org>
>
> The list archives are at http://lists.xml.org/archives/xml-dev/
>
> To subscribe or unsubscribe from this list use the subscription
> manager: <http://www.oasis-open.org/mlmanage/index.php>
>
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
