This is the mail archive of the xsl-list@mulberrytech.com mailing list .


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Seeking help on Grouping distingt sub-elements


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]