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

Re: Bad programmers use recursion, xslt (Offtopic...)

• To: Michele Vivoda <idmichele@y...>, xml-dev@l...
• Subject: Re: Bad programmers use recursion, xslt (Offtopic...)
• From: Tatu Saloranta <cowtowncoder@y...>
• Date: Mon, 27 Mar 2006 12:57:52 -0800 (PST)
• Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:Received:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type:Content-Transfer-Encoding; b=32FJGN1EU58FbSUyAilbeBlBuCh84K7M53DSQSFMhd0AgVxnnAc4J5PlZ/K6Qz5jvm5FFxhyy/ulTB0JT+2x1hjjYuCxOjeinCcyfNnaI7X/2fahWfZI11TSe/TwWlW1G0HTgupZBzADE5rpV1xeKmXKan438hB4rFKcWJ1HGlA= ;
• In-reply-to: <20060327101200.89390.qmail@w...>

--- Michele Vivoda <idmichele@y...> wrote:

> > Regarding xslt, what I have always wondered is
> whether
> > there are many (enough?) cases where having
> stateful
> > alternative (with real variables or such to store
> > state) would have benefits: it seems as if
> computing
> > certain things just once (or cumulatively) could
> yield
> > significant improvements.
> 
> Not sure if related but I found in my experience 
> that sometimes splitting a single XSLT1.0
> transformation 
> into two transformations could bring good if 
> not big performance improvements. 
> 
> In the first pass you prepare the intermediate
> structures you need and and in some way you 
> add them to the source.
> 
> In the second pass you exploit these pre-prepared
> structures saving the effort of calculating 
> them on the fly (lookup, sort etc). 
> They are already prepared by you
> in the first pass with the flavour you like. 

Yes, I think it is related. It is another way to solve
the problem. I did something similar with conversion
from OpenOffice format to DocBook/HTML: one problem
with OOo format (wrt xslt processing) is that it is
bit tricky (and inefficient) to try to resolve styling
in correct way. It is better (for the use case in
hand... not necessarily generally) to first flatten
style tree, then use flattened styles in the second
transformation phase. Also, the pre-processing stage
could be shared between different backends.
This can also potentially reduce complexity of the
solution, solving some O^2 (and up) cases?

Also, I think XSL+SAX are nicely suitable for such
pipeline processing; although event-based interfaces
are pain for other kinds of processing
(recursive-descent parsing, data binding), they work
well for pipelining, and for creating/serializing tree
models (which of course makes sense due to historical
background of DOM + XSLT being main driving
technologies running on SAX).
There used to be lots of activity in coming up with
frameworks for glueing transformation pipelines
together, too. Perhaps now is time to formalize them,
as Michael pointed out?

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

• References:
  • Re: Bad programmers use recursion, xslt (Offtopic...)
    • From: Michele Vivoda <idmichele@y...>

• Prev by Date: RE: Namespaces, Xml Schema Whitespace normalization, xs:anyURI, and URILiterals in XPath 2.0
• Next by Date: Services and Domains
• Previous by thread: RE: Bad programmers use recursion, xslt (Offtopic...)
• Next by thread: RE: Bad programmers use recursion (Offtopic was Re: XML Performance in a Transacation)
• Index(es):
  • Date
  • Thread