[
Lists Home |
Date Index |
Thread Index
]
Oh, I dont... sorry, didnt mean to lead you into the belief that this
is what I was suggesting. Your earlier numbers were significant and
while obviously the difference comes 100% from the transformation
engine at the time of the comment I simply wondered if you had found
ways to gain greater performance, possibly by illiminating, or better
said, integrating the libxmlj code more directly into the JAXP cose
base itself... e.g. Instead of simply providing a Factory instance
for JAXP to pass the proper information to binding the libxmlj library
directly into the JAXP code base, and fif so possibly adding a bit of
a performance enhancment.
I think were on the same page now... thanks for the clarification!
On Tue, 29 Mar 2005 10:12:54 +0100, Chris Burdess <dog@bluezoo.org> wrote:
> M. David Peterson wrote:
> > > > Sweet! Thanks for the info :) I'm glad to see the agressive stance
> > > > to integrate this directly... I'm assuming by doing so you/they? are
> > > > able to shave some time off the clock?
> > >
> > > Not really. I assume you're talking about the implementation of
> > >
> > > http://java.sun.com/j2se/1.5.0/docs/api/javax/xml/transform/
> > > TransformerFactory.html#newInstance()
> > >
> > > ?
> >
> > Yeah. This is with the assumption that the mentioned libxmlj
> > implementation of libxml and libxslt uses the JAXP interface to
> > implement a transformation as this is the impression I received from
> > your first post. Is this not the case?
>
> Yes. I don't understand why you think this would make
> TransformerFactory.newInstance perform any better than Sun's
> implementation though (or why performance in this method is of such
> great importance).
> --
> Chris Burdess
>
--
<M:D/>
:: M. David Peterson ::
XML & XML Transformations, C#, .NET, and Functional Languages Specialist
|
