[
Lists Home |
Date Index |
Thread Index
]
On Sunday 27 March 2005 16:38, Oleg Tkachenko wrote:
> Razvan MIHAIU wrote:
> >> Provided that DOM is hugely inefficient for performing XSLT, most XSLT
> >> processors always build their own proprietary optimized tree
> >> representation of an input XML to work with.
> >> Given that it's clear that DOM is just a waste of memory here - use
> >> SAX instead.
> >
> > I do not understand. An XSLT processor can require random access to
> > the XML instance. With SAX you would be forced to pass the document
> > multiple times.
>
> Nope, it just builds optimized in-memory XML tree to work with. Just
> take a look at Xalan or Saxon's sources.
> This is actually hot spot for various optimizations in XSLT, e.g. see
> http://xml.apache.org/xalan-j/dtm.html.
>
> > Are you suggesting to use SAX to build an in-memory representation of
> > XML other than DOM ?> >> Provided that DOM is hugely inefficient for
performing XSLT, most XSLT
> >> processors always build their own proprietary optimized tree
> >> representation of an input XML to work with.
> >> Given that it's clear that DOM is just a waste of memory here - use
> >> SAX instead.
> >
> > I do not understand. An XSLT processor can require random access to
> > the XML instance. With SAX you would be forced to pass the document
> > multiple times.
>
> Nope, it just builds optimized in-memory XML tree to work with. Just
> take a look at Xalan or Saxon's sources.
> This is actually hot spot for various optimizations in XSLT, e.g. see
> http://xml.apache.org/xalan-j/dtm.html.
>
> > Are you suggesting to use SAX to build an in-memory representation of
> > XML other than DOM ?
>
> Sure. Unless your source XML is already in DOM, what's the point to use
> DOM if XSLT processor's building its own in-memory representation?
I am curious of whether it is possible to still approach a special tailored
tree approach, which is popular among processors and which I have
understanding for, while still being collaborative with plain DOM.
Let's say a hypotethical XSLT engine was to be used in a DOM-based(ref
counted, impl separated) web-browser for ordinary client-side processing, as
well as a support component in arbitrary applications such as exporting
Office formats, is there then any hopes for doing something significant at
the tree structure? In short, the engine may be passed a DOM structure, and,
for example in the case of a web browser, must deliver.
Is there any approaches of supporting multiple tree-backends? E.g, when the
engine is used for "pure" XSLT processing, it can take care of all steps, and
build a tree tailored for its own purposes.
It's vague, but perhaps someone can deepen the topic..
Cheers,
Frans
|
