Re: Stylesheet optimisation

Subject: Re: Stylesheet optimisation
From: "Steve Muench" <smuench@xxxxxxxxxxxxx>
Date: Fri, 3 Dec 1999 14:26:27 -0600
Ray,

I can second that emotion. All parts of your observations.

For lots of examples of this, check out:

http://technet.oracle.com/tech/xml/demo/demo1.htm

Each example has a link to the source XSQL Page and
XSLT Stylesheets that drive the rendering...

The most interesting demo is the "Do You XML?" demo
which is a completely functional, searchable,
categorized web site built with four SQL queries and
a single XSLT stylesheet. Fully data-driven.

_________________________________________________________
Steve Muench, Consulting Product Manager & XML Evangelist
Business Components for Java Development Team
http://technet.oracle.com/tech/java
http://technet.oracle.com/tech/xml
----- Original Message -----
From: Ray Cromwell <ray@xxxxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxx>
Sent: Friday, December 03, 1999 4:26 PM
Subject: Re: Stylesheet optimisation


| >
| > > Ouups, forgot the links to java lobby post :
| > >
| >
http://www.javalobby.org/servlet/News?action=displayStories&xsl=comment.xsl&;
| > format=full&id=510100000000125
| >
| > Interesting article. Having experimented with various ways of avoiding
| > building the full tree, I'm sure many interesting transformations can be
| > done this way, but the language to achieve them won't be XSLT. XSLT
gives
| > you direct read access to the input document and append access to the
output
|
| I was the original author of that post. I don't understand what you
| mean by saying that the "language to achieve them won't be XSLT" That's
| like saying "there are many ways of inlined polymorphic dispatch,
| but the language to achieve them won't be Java" (JIT v HotSpot) or
| "there are many ways of optimizing a join, but the language
| won't be SQL"
|
| My point is that for web sites that are transforming simple DTDs
| like database result sets, there exists a subset of XSLT/XPath that
| can be efficiently processed without building a memory intensive
| object model or result set. XSL was supposedly designed to allow
| efficient processing, for instance, by being side effect free.
|
| Consider the following XML input
|
| <foo>
| <bar>quote of the day</bar>
| <body> some useful content </body>
| </foo>
|
| and the following templates
|
| <xsl:template match="foo">
|   <HEADER> <xsl:apply-templates select="bar"/> </HEADER>
|
|   <xsl:apply-templates select="body"/>
|
|   </FOOTER> <xsl:apply-templates select="bar"/> </FOOTER>
| </xsl:template>
|
| According to the XSL design, I should only have
| to apply the template to "bar" once, because the
| side-effect-free-ness guarantees that the second
| application will result in an identical result
| fragment.
|
|
| Now consider an XML input like this
|
| <resultset>
| <row>
|    <col>Apple</col>
|    <col>$1.25</col>
| </row>
|
| <row>
|    <col>Orange</col>
|    <col>$3.25</col>
| </row>
|
| <row>
|    <col>Frape</col>
|    <col>$0.35</col>
| </row>
| </resultset>
|
| And the following stylesheet
|
|
| <xsl:template match="resultset">
|
| <TABLE>
|   <xsl:apply-templates select="row"/>
| </TABLE>
|
| </xsl:template>
|
|
| <xsl:template match="row">
| <TR>   <xsl:apply-templates select="col"/> </TR>
| </xsl:template>
|
|
|
| <xsl:template match="col">
| <TD> <xsl:apply-templates/> </TD>
| </xsl:template>
|
|
| Whether or not you consider this an interesting XSLT stylesheet,
| I can assure you, there are many cases where XSLT stylesheets
| will be "simple" and won't have XPath's grabbing data from random
| spots all over the XML document.
|
| All I'm suggesting is, that perhaps an XSLT processor can "optimize"
| the stylesheet after it is loaded and detect how much state has
| to be preserved for processing. It can always fall back on
| a slower processing model, but if it could detect when a
| stylesheet could be "optimized" and give warning about what
| constructs are likely to be slow, wouldn't that be great for
| development in the same way that breakpoints and tracing are?
|
|
| -Ray
|
|
|
|
|
|
|
|
|
|
|  XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list
|


 XSL-List info and archive:  http://www.mulberrytech.com/xsl/xsl-list


Current Thread