RE: XPath for matching multiple child elements

> And while we're at it, could you comment on the performance 
> implications of a near-identity first pass in a pipeline (in 
> which, if you liked, you could rename the elements)? I guess 
> this would generally tend simply to double the time of the 
> transform? 

I'm seeing 3800ms for putting a 10Mb document through an identity transform,
4960ms for putting it through two identity transforms in series. That's
because the transformation cost for a simple serial transformation is
roughly comparable with the parsing and serialization costs: about 1200ms
each in this case. It uses twice the memory though, which may be a more
important factor.

In sum, is your assessment that none of these 
> tricks for maintainability (which all involve their 
> tradeoffs) are worth it, and one is just better off biting the bullet?

In 90% of applications better maintainability is worth having at the cost of
a bit of performance. For example, a pipeline architecture that modularizes
the transformation is almost always a good idea if it it takes a bit longer.
(concerning which, see http://www.w3.org/XML/XProc/docs/langspec.html if you
haven't already done so. This is an important development for the XSLT
community).

But in this example, I'm not convinced any of the suggestions have delivered
better maintainability.

Michael Kay
http://www.saxonica.com/