Cart
|
[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Performance Question: Expensive Functions in Pred
 On Thursday 27 May 2004 23:35, Eliot Kimber wrote: That's an interesting idea. I hadn't considered it, partly because I just don't normally do SAX-based stuff because optimal performance has not been a top requirement in the work I've done lately (and as a matter of engineering practice I only address performance issues once the core business logic is sound and proven as long as performance is otherwise acceptable) and partly because I try to keep the number of distinct system components as small as possible, so I prefer to do everything in XSLT if I can just to limit potential points of failure and overall system complexity. But that can have the side effect of making the XSLT more complex, as is the case here. So from an engineering activity it's a question of finding the right balance between system complexity, processing performance, and code maintainability (which normally means simplicity at the template/method level). Obviously there can be no right answer in general, so it's important to understand what cost and benefit one can expect from a particular coding approach. I can see that for performance, and for keeping the XSLT simpler and easier to maintain, that a separate SAX filter could work well. My main concern there would be the complexity of implementing the business logic as a SAX event handler. In many cases the check is purely hierarchical or, in the simplest case, requires examining only the current element, but in some cases we have the check involves examining siblings, descendants, or worse (e.g., nearest preceding element of type foo with a descendant of type bar that is itself applicable--relatively easy to do in XSLT, not so much in a streaming SAX application). And now that you mention it I can see that a SAX filter might be a good way to implement XInclude resolution, although I've already got it implemented in XSLT as a standalone step. But a SAX processor would be more generally applicable (I could use it for DOM construction, for example). Hmm. Cheers, E. -- W. Eliot Kimber Professional Services Innodata Isogen 9030 Research Blvd, #410 Austin, TX 78758 (512) 372-8122 eliot@xxxxxxxxxxxxxxxxxxx www.innodata-isogen.com 
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! 
Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|
