[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Seeking help on Grouping distingt sub-elements

Subject: Re: Seeking help on Grouping distingt sub-elements
From: jestoll@xxxxxxxxxx
Date: Mon, 6 May 2002 15:06:16 -0400
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


Current Thread

PURCHASE STYLUS STUDIO ONLINE TODAY!

Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
Email
First Name
Last Name
Company
Subscribe in XML format
RSS 2.0
Atom 0.3
Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.