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

Re: Stylesheet optimisation

Subject: Re: Stylesheet optimisation
From: "Steve Muench" <smuench@xxxxxxxxxxxxx>
Date: Fri, 3 Dec 1999 14:26:27 -0600
resultset oracle optimisation web
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

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.