RE: Computational complexity of XSL processing

Hi.

Your points are valid, but my limited experience is already starting to
show me that filters are damn useful.

One instance where I've found it handy is to infer the "type" of a
container based upon its content, which in some cases I find prefereable to
hastling the back-end developers to include hard coded typing, and saves a
proliferation of content models.

Conditional processing if the result is just being tweaked, but basically
the saem throughout, but if what one is doing with the result is markedly
different in differing cases I find filtering preferable.

I think as developers experience of XSL increases (I certainly place myself
in this bracket) more creative uses of filtering will emerge. It's a bit
like dHTML, the really creative stuff didn't start comming about until way
after its introduction.

In short, I'd be wary at this stage of predicting which aspects of XSL will
be rarely used.

Cheers
     Guy.





xsl-list@xxxxxxxxxxxxxxxx on 02/23/99 01:18:58 AM

To:   xsl-list@xxxxxxxxxxxxxxxx
cc:    (bcc: Guy Murphy/UK/MAID)
Subject:  RE: Computational complexity of XSL processing




[SNIP]
>
> From my experience, people seldom really use extremely complex
> match patterns anyway. Most people seem to treat match patterns
> and select patterns much like a case statement nested inside an
> if block.
>
Agreed. I've only found one case where I really needed anything more
elaborate than "element-name", "*", "element-name/*", and
"parent-element/child-element". I usually prefer to handle anything else by
conditional processing within the template. If there was an inheritance
mechanism that allowed more than one rule to be applied, it might be
different.
Mike Kay

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






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