Re: [xsl] Common Element Solution (XSL 2.0)

Subject: Re: [xsl] Common Element Solution (XSL 2.0)
From: "Jay Bryant" <jay@xxxxxxxxxxxx>
Date: Tue, 22 Mar 2005 22:16:42 -0600
Neat stuff.


Jay Bryant
Bryant Communication Services

----- Original Message ----- 
From: "Michael Kay" <mike@xxxxxxxxxxxx>
To: <xsl-list@xxxxxxxxxxxxxxxxxxxxxx>
Sent: Tuesday, March 22, 2005 5:24 PM
Subject: RE: [xsl] 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.
> 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
> knowing that all the items in the group are in the same document. It's
> 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

Current Thread