[
Lists Home |
Date Index |
Thread Index
]
BTW... for the record, theres also the whole matter of Source with
JAXP but it doesnt seem to long ago that this particular subject was
hashed out by the big boys in this arena so I thought it best to not
get involved with this piece of th JAXP pie... still, its quite an
important piece so if any body out there is interested in learning
more about this do a search in the archives for "Source" in the
subject line that contains comments from Michael Kay, Elliotte Rusty
Harold, Dare Obasanjo, etc... I learned more in one day of post
bashing from the XML brass than I think I ever have from any other
source within any given 24 hour period (or was it 48? No matter the
length its all fantastic content to learn from for sure! :D
On Mon, 28 Mar 2005 02:15:16 -0700, M. David Peterson
<m.david.x2x2x@gmail.com> wrote:
> ??? 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
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|