This is the mail archive of the
xsl-list@mulberrytech.com
mailing list .
Re: Seeking help on Grouping distingt sub-elements
- From: jestoll at crtnet dot com
- To: xsl-list at lists dot mulberrytech dot com
- Date: Mon, 6 May 2002 15:06:16 -0400
- Subject: Re: [xsl] Seeking help on Grouping distingt sub-elements
- Reply-to: xsl-list at lists dot mulberrytech dot com
Jeni and Ken,
First and foremost - a heartfelt THANK YOU - you both have resloved the problem I was having! (And, with two different methods, really made things clear!) You don't know how much I appreciate you two taking the time to help me out on this!
Secondly, HOLY COW!!! I can't believe I banged my skull against a brick wall (figuratively) for most of an evening and you guys came up with solutions in practically no time at all! :-)
Thirdly, THANK YOU!!
I'm trying to work my way through both examples - I really want to understand what's going on in them ("Teach a man to fish..." and all that... :-) I started with Ken's, as it appears to be the simpler to understand of the two.
Ken, on your statement:
<xsl:if test="generate-id(.)=generate-id($chassis[commonid=current()/commonid])">
is there an implied [1] on the end of the $chassis[...] piece? ie,
<xsl:if test="generate-id(.)=generate-id($chassis[commonid=current()/commonid][1])">
By default, its clearly bringing one element back from $chassis, despite the fact that there are multiple matching members for a given commonid (at least in the given XML). I experimented with putting a [1], [2] and [3] at the end and the behavior was as I would expect it to be (again, based on knowing there are only 2 values in my XML), thus my wondering if there is an implicit [1] there...
Having looked at Ken's, Jeni's was a bit more aproachable (still a little wierded out by the key thing after the recent head-bashing...) - it appears that they're doing the exactly the same thing - Ken's is using a for-each immediately followed by an if that compares the generate-id values, while Jeni's uses a for-each with the equivalent key-based approach - is that correct?
Jeni, in yours, I've not seen the "parent::shipment" style use of the parent axis previously - I've only ever seen it used as ".." or "parent::node()" - it appears that "parent::shipment" is equivalent to "parent::node()" is equivalent to "..", as I put one of each in (ie, mixed and matched) and everything went file. Is "parent::shipment" just a very clear method of saying "I know that shipment is the parent of my current node"? I presume that things would be more flexible using ".." or "parent::node()" vs "parent::shipment", such as if the <shipment> node were to change name, but the remaining structure stayed the same?
I like the simplicity and clearness of Ken's method, but like the compactness of Jeni's.
Thanks Again to both of you - you've really helped me out immensely on this! I think its actually making some sense now!!! :-)
Jim
XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list