> -----Original Message-----
> From: David Carlisle [mailto:davidc@xxxxxxxxx]
> > So b elements can have description children (desc), and so can their
> bChild
> > children.
> 
> do any descendents of b have text content other than the desc elements?
> in your example it is the case that all the text is in desc but may be
> that is just because you cut it down for posting.

Yes, I did cut it down.  A full example is this:

 <a>
 	<b>
 		<desc>some text</desc>
		<qty>5</qty>
		<priority>1</priority>
 		<bChild>
 			<desc>some other text</desc>
			<qty>7</qty>
			<index>12</index>
 		</bChild>
 	</b>
 	<b>
 		<desc>some text</desc>
		<qty>1</qty>
		<priority>2</priority>
 		<bChild>
 			<desc>some other text</desc>
			<qty>2</qty>
			<index>1</index>
 		</bChild>
 		<bChild>
 			<desc>maybe some more text</desc>
			<qty>9</qty>
			<index>44</index>
 		</bChild>
 	</b>
 </a>

> As posted you could just sort on the string value of b.
> <xsl:key name="x" match="b" use="."/>
> together with zapping some white space
> <xsl:strip-space elements="*"/>

Hmm.  For our purposes, a <b> node is the same as another <b> node if the
concatenation of the text value of its <desc> child with the text value of
all of its <bChild> <desc> children is the same as the concatenation of
these things from another <b> node.  So, in the example xml above, those <b>
nodes are not the same.

We're trying to sum the <qty> values across (what we've defined as) like
nodes, and output just one <b> node for each group of like nodes, with the
summed <qty>.  The <index> value isn't important in this transform.

If I just match on the /b/desc text, then I'll get dissimilar (by our
definition) b nodes, won't I?

It seems like I should be able to do this in XSLT 1.0, but if all the great
xslt minds on this list say no, then I'm sure I'm wrong.

I'll look into the node-set exslt, and thanks to everyone

E