Re: Cost of complex match patterns

>>>>> "Andrew" == Andrew Welch <andrew.j.welch@xxxxxxxxx> writes:

    >>> match="foo[//bar]"
    >> 
    >>> match="foo"
    >> 
    >>> Should the former be avoided, or because it's within a match
    >>> pattern it's converted to a simple lookup so it's fine?
    >> 
    >> I don't know the details of your processor on that point, but
    >> out of interest, if you only match on the main input tree, you
    >> can replace the former by:
    >> 
    >> <xsl:variable name="has-bar" as="xs:boolean" select="
    >> exists(//bar)"/>
    >> 
    >> <xsl:template match="foo[$has-bar]">


    Andrew> Indeed (apart from 1.0 where you can't use variables in
    Andrew> match patterns)... the question I'm asking though is
    Andrew> whether you need to workaround potentially expensive match
    Andrew> patterns (as they will be evaluated per element), or
    Andrew> whether through the inbuilt pattern matching process it's
    Andrew> actually a good idea to move work into the match pattern.

    Andrew> For example,

    Andrew> match="foo[ancestor::bar/@type = 'A']"

    Andrew> and

    Andrew> match="foo[ancestor::bar/@type = 'B']"

    Andrew>  (or "bar[@type = 'A']//foo" but I prefer the above)

    Andrew> Is it better to pass down the type through parameters to
    Andrew> avoid the predicate, or is there no need to worry about it
    Andrew> because it becomes a simple lookup?

    Andrew> I'm pretty sure it's the latter....

My attitude to such a question (whatever the language) would be to
code the predicate, and complain to an implementor if this wasn't at
least as quick as the alternatives.
-- 
Colin Adams
Preston Lancashire