[xsl] intersection puzzle

Subject: [xsl] intersection puzzle
From: Sean Whalen <seanwhalen@xxxxxxxxxxx>
Date: Tue, 05 Apr 2005 21:08:25 -0400
Hi:
As a revisit of a recent xslt app I posted about I did some work trying to redo the intersection code in one of the stylesheets. I ended up not making any change to the basic syntax of the intersection approach I already had, but I wanted to show some of the approaches that worked, and didn't work, and ask some questions. At this point, I understand empirically what works and what doesn't, but I was curious about some of the reasons under the hood for the results I got.


this is the XML
http://seanwhalen.home.comcast.net/intersection/datasource.xml
and the XSLT:
http://seanwhalen.home.comcast.net/intersection/picknodes.xsl
(note that Comcast doesn't send XML files the way firefox expects)


The first example (*intersection_ConCat_and_IDs*) gets the right answer, and is pretty close to what I'm really using. That template takes 2 attributes and concats them to match the key in a separate nodeset.


I spent a lot of time with the second example (*intersection_XY*) but could not get the syntax to work. This template tries to match the individual H and V attributes without concating them, but it gets the wrong answer because it matches attributes from different nodes in the set I'm trying to search. This is the core of the template:

<xsl:variable name = "intersection" select = "$polo/square[ @h =$marco/square/@h and @v = $marco/square/@v ] " />
My question is, is there a practical way to get this syntax to work?


An alternative to adding offsets to find nodes with neighboring attribute values would be to subtract the attributes from the 2 nodesets and consider a match anything where the absolute value of the difference was less than or equal to one, <= 1 but the problem above got in the way.

The third example (*intersection_X_Plus_1*) is the same as the previous except that I added "1" to the H attribute in the test, which is what the actual Minesweeper code does in order to test squares that boarder the one that was clicked:

<xsl:variable name = "intersection" select = "$polo/square[@h = $marco/square/@h + 1 and @v = $marco/square/@v ] " />
that code doesn't behave anything like the example it is based on. The " + 1" limited the search to just the first "H" value. There was a brief comment about how nodesets behave in expressions like this, but a I could use a deeper explanation.


The last two (*intersection_Count*) use the standard counting method for determining the intersection.

<xsl:variable name = "intersection" select ="$polo[count(. | $marco) = count($marco )] " />
This is successful, but I don't see a good way to manipulate the individual attributes (again, to add 1 to a value to find nodes with neighboring values).


This is all related to trying to speed up the Minesweeper app at http://seanwhalen.home.comcast.net/sweeperscript/

Any thoughts or feedback would be appreciated.

Regards,

Sean

Current Thread