469,927 Members | 1,672 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,927 developers. It's quick & easy.

Select Node Using position or value of another node.

Hi,

I'm trying to get the value of another node using the position of
another node or the name of the tag.
Such that the current node is one of the contacts child nodes sec or
prim
and doing
<xsl:value-of select="//cust[seq = position()]/name"/>
Should return jon for the prim tag and peter for the sec tag, but
fails as position() appears to resolve to the position of cust not the
contacts node

alternatively I would like to do something like

<xsl:value-of select="//cust[seq = [name()='prim' then 0 else
1]]/name"/>

<custs>
<cust>
<seq>0</seq>
<name>jon</seq>
</cust>
<cust>
<seq>1</seq>
<name>peter</seq>
</cust>
<contacts>
<prim>
<message>hello</message>
</prim>
<sec>
<message>hello</message>
</sec>
</contacts>
</custs>

Oct 14 '05 #1
6 1718
Eddy C wrote:
Hi,

I'm trying to get the value of another node using the position of
another node or the name of the tag.
For the difference between tags and elements, see the XML FAQ at
http://xml.silmaril.ie/authors/makeup/
Such that the current node is one of the contacts child nodes sec or
prim
and doing
<xsl:value-of select="//cust[seq = position()]/name"/>
Should return jon for the prim tag and peter for the sec tag, but
fails as position() appears to resolve to the position of cust not the
contacts node
In cust[...position()...], the value of position() refers to the position of
the cust among its siblings, starting at 1.
alternatively I would like to do something like

<xsl:value-of select="//cust[seq = [name()='prim' then 0 else
1]]/name"/>
This is not a well-formed document. I assume you meant to use </name>
after jon and peter.

If so, cust[position()=seq+1]/name will return jon and peter.
<custs>
<cust>
<seq>0</seq>
<name>jon</seq>
</cust>
<cust>
<seq>1</seq>
<name>peter</seq>
</cust>
<contacts>
<prim>
<message>hello</message>
</prim>
<sec>
<message>hello</message>
</sec>
</contacts>
</custs>


I'm not clear what you want from this. Are you trying to access the
message belonging to each name, or the name belonging to each message?

///Peter

Oct 15 '05 #2
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>hello</message>
</sec>
</contacts>
</custs>

Oct 15 '05 #3
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
Oct 16 '05 #4
Peter,

Its not my design, I'm just the consumer and needed to find a way to
come up with a single XPath query to get the associated bit of data.

Also the example I gave is very stripped down. Looking at the Schema
doc prim and sec have very different attributes but the record we are
trying to join to has the same attributes for both.

So it looks like its not going to be simple to do this in one single
XPath query.

Oct 17 '05 #5
Eddy C wrote:
Peter,

Its not my design, I'm just the consumer and needed to find a way to
come up with a single XPath query to get the associated bit of data.

Also the example I gave is very stripped down. Looking at the Schema
doc prim and sec have very different attributes but the record we are
trying to join to has the same attributes for both.

So it looks like its not going to be simple to do this in one single
XPath query.


OK, if it has to be done that way...
If your current element is either prim or sec, then

/custs/cust[seq=count(current()/preceding-sibling::*)]/name

will return the name of the matching customer.

///Peter
Oct 17 '05 #6
Very nice, I really appreciate your help.

Oct 17 '05 #7

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

15 posts views Thread by TJ Walls | last post: by
3 posts views Thread by Matthew Woods | last post: by
3 posts views Thread by Andy | last post: by
2 posts views Thread by naima.mans | last post: by
1 post views Thread by Zachary Turner | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.