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

Re: XPath 1.5? (was RE: typing and markup)


Re:  XPath 1.5? (was RE:  typing and markup)
Hi Mike,

> Either would do. The above are the only template rules in the
> stylesheet. The first template rule is the only thing in the
> stylesheet that can produce any output. Therefore you know that if
> you are processing a node that cannot have row[id='0432'] as a
> descendant, you can skip it and its entire subtree.
>
> As I say, this is an example where schema knowledge could help
> greatly. The rule would be "if none of the descendants of this node
> can match a template rule that produces output, then don't process
> this subtree." The question is, would this rule be triggered
> sufficiently often to justify including it in the optimizer?

As with most of these optimisations, an alternative would be to
perform a kind of linting service for the XSLT authors and point out
that they would get much better performance if they rewrote their
stylesheet. Doing:

  <xsl:apply-templates select="/table/row[id='0432'][1]" />

for example, would speed things up no end.

But looking at it another way -- say that you've looked at the
stylesheet and you've noticed that you only need to process elements
that contain an element that matches row[id='0432']. Then there are
two ways you can use that information:

  - you can look in the schema or DTD to find out what kinds of
    elements can contain a row element with an id child with the value
    '0432' and all their ancestors, and then, while parsing the
    document, flag those elements that are of any of those types

  - while parsing, you can locate the row element with an id with the
    value '0432' and place a flag on it and all its ancestors

Isn't the latter easier to do and more flexible?

> (Alternatively, I might include it anyway because I'm only really
> interested in optimizing the cases that occur in benchmarks).

Quite. I think it's unlikely that this kind of arrangement would occur
in real life. In real life, the '0432' would be a parameter passed
into the stylesheet, and as you know, you can't use parameters in
template matches, so there'd either be the pull approach as above, or
a push approach that looked like:

<xsl:template match="row">
  <xsl:if test="id = $id">
    ...
  </xsl:if>
</xsl:template>

Although I guess since that restriction is lifted in XSLT 2.0, it
could happen.

Cheers,

Jeni

---
Jeni Tennison
http://www.jenitennison.com/


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
 

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.


Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

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.