RE: Common Element Solution (XSL 2.0)

> Now I have a better idea of when I might use current-group. How much 
> performance improvement might one expect from this change? 

Depends on the implementation, of course, and also on the data volumes. But
I think under many implementations it will make the difference between an
O(n) and an O(n^2) solution.

> 
> I thought about making count(/table/table) into a variable 
> for the sake of performance,

For this one there's a much better chance that the optimizer will do the
work for you anyway. I'm not sure if Saxon will do it though: it depends on
knowing that all the items in the group are in the same document. It's best
not to rely on such optimizations if you don't have to.
> 
> I  also thought about the one-such-name-to-a-table problem, 

For your particular application the source data obviously satisfies this
constraint, but the constraint needs to be stated in case someone tries to
apply the same algorithm to a different situation where the constraint
doesn't hold.

It's not hard to generalize the solution: instead of

   count(current-group()) = $number-of-tables

you want something like

   count(current-group()/parent::table) = $number-of-tables

relying on the fact that "/" eliminates duplicates.

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