Steve,
I'm sorry we all seem to be having such a hard time with this.
The reason, to me, appears to be that your presentation of your
problem is falling into a gap between two useful approaches:
1. Asking a general question, considering the responses, and if
necessary reframing the question and pursuing open-ended dialogue.
(Not "moving the goalposts" or expressing unhappiness with anyone's responses.)
2. Presenting a complete encapsulated problem, including source,
attempted stylesheet, and stated requirements probably including the
form of desired output. "Complete and encapsulated" means the problem
is trimmed down, ideally to a single screen, so an expert can survey
it and pull out the problem quickly. If it requires any guessing at
all, we are not likely to do anything with it since who wants to
offer an answer and then be wrong?
In your post below, I can see several possible difficulties, but I
can't be sure which is the culprit since the entire problem isn't
presented explicitly.
For one thing, you tell us your problem is with the key, but without
key declarations we have no way of knowing with any certainty how
your keys work or are supposed to. Also, the sample data you provide
doesn't match up: there's no complete problem here.
To make things a bit worse -- I'm about to get scarce for a few hours
or days, so I'm relying on others on the list to step in and help (as
we all must do sometimes). Accordingly, when you do your homework and
present a problem succinctly and completely you do us all a favor,
since you enable such handoffs. (In great part the list is driven by
a friendly competition to come up with good answers.) And just so,
since we rely on each other, disrespect (or even the unintended
appearance of it) towards any contributor amounts to disrespect to
all of us, and lessens the chances of a questioner's getting prompt
help in future. I don't say this to be punitive, but rather to draw
attention to one potential difficulty that can fairly easily be
avoided or dealt with.
Regards,
Wendell
At 01:41 PM 7/24/2006, you wrote:
The below represents my attempts to create a table which looks something like
Cognitive --- 26
Hearing --- 17
*type3* --- X
X = times which a disability of type=type3 appears in
$vP2/Records/Record as disabPrimary
My understanding of key breaks down somewhere. If you see what I am
doing wrong, please let me know.
Thanks,
-Steve
-------------------------------------------------------
XSL version = 1.0
XSL------------
<xsl:template match="/" >
<xsl:apply-templates
select="document('../../Consumer.xml')/disabilities" />
<table>
<xsl:for-each
select="document('../../Consumer.xml')/disabilities/option[generate-id(.)=generate-id(key('options',@type)[1])]">
<xsl:sort select="@type"/>
<xsl:apply-templates mode="x" select="$vP2/Records">
<xsl:with-param name="type" select="@type" />
</xsl:apply-templates>
</xsl:for-each>
</table>
</xsl:template>
<xsl:template match="Records" mode="x">
<xsl:param name="type" />
<tr>
<td>
<xsl:value-of select="$type" />
</td>
<td>
<xsl:value-of select="count(key('oldID',Record))" />
</td>
</tr>
</xsl:template>
Variable $vP2 contains via document()-----------
<Records>
<Record>
<disabPrimary>101</disabPrimary>
</Record>
<Record>
<disabPrimary>201</disabPrimary>
</Record>
<Record>
<disabPrimary>151</disabPrimary>
</Record>
.....etc
And consumer.xml disabilties are like----------
<option oldID="413" type="Physical" name="Cancer"/>
<option oldID="400" type="Cognitive" name="Cerebral Palsy"/>
<option oldID="410" type="Physical" name="Chronic Fatigue Syndrome"/>
<option oldID="305" type="Cognitive" name="Cognitive-Other"/>
--~------------------------------------------------------------------
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
To unsubscribe, go to: http://lists.mulberrytech.com/xsl-list/
or e-mail: <mailto:xsl-list-unsubscribe(_at_)lists(_dot_)mulberrytech(_dot_)com>
--~--