[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: XSLT with DOM or SAX ?

• To: Oleg Tkachenko <oleg@t...>
• Subject: Re: XSLT with DOM or SAX ?
• From: Frans Englich <frans.englich@t...>
• Date: Sun, 27 Mar 2005 18:40:11 +0000
• Cc: xml-dev@l...
• In-reply-to: <4246E16F.9010007@t...>
• References: <42460104.8020609@m...> <42462ADD.2090106@m...> <4246E16F.9010007@t...>
• User-agent: KMail/1.5.4

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

• Follow-Ups:
  • RE: XSLT with DOM or SAX ?
    • From: "Michael Kay" <mike@s...>

• References:
  • XSLT with DOM or SAX ?
    • From: Razvan MIHAIU <mihaiu@m...>
  • Re: XSLT with DOM or SAX ?
    • From: Razvan MIHAIU <mihaiu@m...>
  • Re: XSLT with DOM or SAX ?
    • From: Oleg Tkachenko <oleg@t...>

• Prev by Date: RE: Quiz: static transformation vs. JIT generation
• Next by Date: Re: Quiz: static transformation vs. JIT generation
• Previous by thread: Re: XSLT with DOM or SAX ?
• Next by thread: RE: XSLT with DOM or SAX ?
• Index(es):
  • Date
  • Thread