RE: Performance Question: Expensive Functions in Pred

> Another option of course is to do the applicability processing as a 
> separate step so that the base processing templates don't 
> have to care 
> about applicability. That would ensure that each element is only 
> processed once for applicability but might introduce other 
> performance 
> or scalability issues since one would have to generate either a new 
> serialized instance or a new result tree reflecting the input 
> document(s). It would be a cleaner engineering solution as it 
> would mean 
> base template writers wouldn't have to know about the need to do 
> applicability checks.

I do a similar thing using a SAXFilter on the way into the transform.
My element structure is of the form:

<node>
  <applic>
    <applic_info>
  </applic>

  <nodedata>
  ....
  </nodedata>
</node>

The <node> never makes it to the transform if its <applic> structure
does not pass the test.  What makes it tricky using SAX is that if the
<applic> does pass then the sax events for it (and the parent <node>)
need to be generated, but by then the sax parser is at the end
</applic>.  Implementing the applic check in XSLT would be much easier,
but slower.  I guess it depends on how suitable SAX is in your case.

cheers
andrew