[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Common Element Solution (XSL 2.0)
Neat stuff. Thanks. 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: 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/
|
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
|