> The Java code keeps all the data in memory, organized by area 
> and ordered by date/time. In order to minimize the processing 
> time (since it's intended to compare the actual XML 
> marshalling/unmarshalling
> performance) it checks rectangle intersections between the 
> query lat/long range and that of each area to determine which 
> areas need to be checked, then does binary searches through 
> the ordered array of quakes within an area for the start/end 
> times in the query. Once it has the range of possible 
> matching quakes, it does the final checks on lat/long and 
> magnitude for each individual quake. I suspect the binary 
> search part is more than you want to take on in XSLT, so we 
> can try comparisons both with the search part enabled in the 
> Java code and with it disabled (instead doing a check on each 
> quake within the area).

Ideally one would have an XQuery implementation that optimizes using
multi-dimensional indexes so that all of this is taken care of beneath the
covers. I don't know of an implementation that does that, unfortunately,
though some might give you access to the spatial data support in an
underlying RDBMS. 

Short of that, there's a danger here that you end up comparing two different
search algorithms both implemented at application level, rather than two
different technologies/languages for writing the application. But it should
be an interesting exercise all the same.

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