Re: [xsl] $variables with xsl:key()

[Wendell Piez <wapiez@xxxxxxxxxxxxxxxx>]

Steve,

First, if it were my stylesheet I'd start by binding the secondary 
input document to a variable:

<xsl:variable name="lookup" select="document('fileonyoursystem.xml')"/>

That would both make the code more succinct and legible, and prevent 
naive processors from parsing that document many times (since we'll 
be reaching into it many times).

Then:

<xsl:template match="/" >
        <xsl:apply-templates select="$lookup/disabilities" />
        <table>
        <xsl:for-each 
select="$lookup/disabilities/option[generate-id(.)=generate-id(key('options',@type)[1])]">
                <xsl:sort select="@type"/>
                <xsl:apply-templates mode="x" select="$vP2/Records/Record">

<!-- reaching in and applying templates to each individual Record,
     not to their Records wrapper; also assuming you've declared $vP2 so those
     nodes actually get selected -->

                        <xsl:with-param name="type" select="@type" />
                </xsl:apply-templates>
        </xsl:for-each>
        </table>
</xsl:template>

<xsl:template match="Record" mode="x">
<!-- matching each individual Record -->
        <xsl:param name="type" />
        <tr>
                <td>
                        <xsl:value-of select="$type" />
                </td>
                <td>
                  <xsl:variable name="thisRecord" select="disabPrimary"/>
                  <!-- binding the current node's identifier to a variable
                       so we can get it after we change contexts again -->
                    <xsl:for-each select="$lookup">
                       <!-- switching context back to the lookup document
                            so we can retrieve nodes from it -->
                        <xsl:value-of 
select="count(key('oldID',$thisRecord))" />
                       <!-- using the variable since this node isn't available
                            in the immediate context -->
                    </xsl:for-each>
                </td>
        </tr>
</xsl:template>

Note: this is totally untested, just groping in the dark. If it 
doesn't work, maybe it's at least enough to give the idea. In the 
real world, I might be able to make this more concise and more 
efficient, switching between contexts less or optimizing my keys for 
more direct traversals.

FWIW, most lately you offered us a key declarations for one named 
'oldID' and one named 'types', but the code you offered has one named 
'options' whose declaration we can only assume will work for the 
nodes you want from it. If I could read your screen I might be able 
to correct for this; as it is I'm only trying to tie this thread off.

If after trying at this it's still not working and you can't figure 
out why, please try posting with complete sample document and 
stylesheet, not fragments requiring guesswork and deduction from your 
volunteer helpers. We get frustrated too.

Cheers,
Wendell

Then, since you're trying to At 02:57 PM 7/25/2006, you wrote:
> On 7/25/06, Wendell Piez <wapiez@xxxxxxxxxxxxxxxx> wrote:
> > In the best case, we'd have a complete if reduced sample where
> > records would appear matching oldIDs you actually represented ...
> > this makes it much easier to run the XSLT engines we keep in our
> > heads, or even engines we run in our computers, to test everything.
> > (List participants have been known to test each other's code in live
> > processors from time to time.)
>
> The numbers are hypothetical. Let it suffice that at the end of the
> day I need @oldID to match disabPrimary.
>
> > >What do you mean by "key declarations"?
> >
> > By "key declaration" I mean the top-level element that sets up the
> > key and assigns it a name, as in
> >
> > <xsl:key name="things-by-id" match="thing" use="@id"/>
>
> Here goes....
>
> <xsl:key name="types" match="option" use="@type" />
> <xsl:key name="oldID" match="Record" use="disabPrimary" />
>
> So, now that that obstacle is out of the way, howto match up to these
> keys in a meaingful way?
>
> -S