Eddy C wrote:
Sorry Peter, I'll try and be a little clearer. There was a mistake in
the XML, which you correclty identified.
The idea is to fetch the name from the cust node, where the seq equals
the position-1 of the prim and sec nodes within the customers tag. i.e
prim is at position 1 and cust is at position 2.
Therefore the primary (prim) customer would have a name of Jon and the
secondary (sec) customer would have a name of peter.
<custs>
<cust>
<seq>0</seq>
<name>jon</name>
</cust>
<cust>
<seq>1</seq>
<name>peter</name>
</cust>
<contacts>
<prim>
<message>hello</message>
</prim>
<sec>
<message>hi</message>
</sec>
</contacts>
</custs>
OK, but if you are already distinguishing between prim and sec, and you know
they map directly to seq=0 and seq=1 respectively, I don't see the problem:
<xsl:choose>
<xsl:when test="name()='prim'">
<xsl:value-of select="//cust[seq=0]/name"/>
</xsl:when>
<xsl:when test="name()='sec'">
<xsl:value-of select="//cust[seq=1]/name"/>
</xsl:when>
</xsl:choose>
The only reason for doing it by counting would be if you had far more
(other) element content in contacts or cust than you are showing us.
In which case the content of contacts would surely not be prim and sec
but some other element which could be enumerated. Usually the reason for
naming element types a certain way is because it describes *different*
types of data, whereas here the element content of prim and sec is
identical.
This appears to be a peculiarly obtuse piece of design. Why not
<customers>
<customer n="0" type="primary" name="jon" message="hello"/>
<customer n="1" type="secondary" name="peter" message="hello"/>
</customers>
By all means give the customer element subelement content if the character
data content of name and message is more complex, but I see no value in
segmenting the primary/secondary classification from the customer data.
///Peter