Subject: Re: Feature Request - Node Set Processing (long) From: "G. Ken Holman" <gkholman@xxxxxxxxxxxxxxxxxxxx> Date: Sun, 17 Jan 1999 18:06:21 -0500 |
At 99/01/16 16:13 +0700, James Clark wrote: >"G. Ken Holman" wrote: > >> Does this explanation make more sense than my first explanation? > >Not really. You are explaining your proposed solution to a >transformation problem, without really explaining the transformation >problem itself. I apologize I didn't include sufficient information. >What does your source tree look like, and what is the >result tree you are trying to get from it? Without knowing this, it is >not possible to evaluate your proposed solution and to consider >alternative solutions. I agree, and I'm sorry to be taking your time. I usually take the time for a working example to illustrate my problem, but since I (think I) didn't have the syntax to do that, I mocked something up, and I realize from your snippet that my live data would not have matched. >For example, when I see: > > <xsl:choose select="/course/intro| > /course/lesson| > /course/exit" Unfortunately, this particular snippet *doesn't* illustrate my problem completely because it showed all items at the same depth in the source tree; it should have read: <xsl:choose select="/course/intro| /course/module| /course/module/lesson| /course/exit" ... the source tree has elements at different depths, plus intervening elements not pertinent to the buttons; my source tree looks like: /course /course/intro id=intro /course/info /course/module id=m1 /course/module/lesson id=m1l1 /course/module/lesson id=m1l2 /course/module/lesson id=m1l3 /course/module/assessment /course/module id=m2 /course/module/lesson id=m2l1 /course/module/lesson id=m2l2 /course/module/assessment /course/assessment /course/exit id=exit ... but I see from your example of "walking" the source tree using nextelement() that as long as I don't have nested elements with the same generic identifier I can walk down the tree (using children) and back up again (I wonder if this will be difficult), skipping elements that aren't important (doing both by having tested the current location using ancestor-or-self(name) ... ancestors not being a problem here because of no nesting, though I still think a self(name) function would be handy) using various modes to find the "next" construct (at whatever level) with which to render my "active-right-arrow", or finally reaching the end of the siblings indicating I need to render my "inactive-right-arrow". So, as usual, your example was very informative, and I think I'm okay on my non-iterative problem ... I will know more when I get time to recode. As for my iterative problem, I will *not* attempt to describe a solution, but will (appropriately chastised) try to illustrate my transformation problem as currently implemented in my DSSSL back end post process of my XSL transformed node information: (1) - consider the significant elements of my source tree being as described above (2) - consider the transformation of the third lesson of module 1 (id=m1l3), where (as with all frames rendered), I need to render two navigation button bars at the bottom of the screen: x o x x x x o x x - the top bar of buttons is for navigating the intro, module and exit nodes (4 total) - the bottom bar of buttons is for navigating the lessons (5 total) - the buttons for the current lesson and the current module are rendered differently than for the other lessons and modules - when on a module page, none of the lesson bar buttons shows as "current" (3) - each "x" button is an <img> within an <a> element, with href="{@id}.htm", with the src= attribute pointing to a blue dot - each "o" button is an <img> without an <a> element, with the src= attribute pointing to a green dot - the "o" button in the bottom represents the current lesson - the "o" button in the top represents the module in which the current lesson resides (4) - so, I need to walk the source tree at each level of interest and determine if where I am (or my ancestor module is) is where I was before I started walking, and at each step render different information calculated from where I am walking: current node = page being rendered current module node = ancestor-or-self(intro|module|exit) For each node in (/course/intro /course/module /course/exit) ;first button bar { if( node = current module node ) render green button without hyperlink else render blue button with hyperlink } For each node in (/course/module/lesson) ;second button bar { if( node = current node ) render green button without hyperlink else render blue button with hyperlink } (BTW, my current XSL encodes an element recognized by the back end that includes the specification of the current node as one subelement, and the set of nodes to choose from as another subelement, thus implementing the above pseudo-code) I can't think of anything more to add as a description of what I need. I will gladly accept an existing solution rather than insisting on new functionality, but my enthusiasm for my earlier proposed solution is based on what I had thought was not just an "easier" (admittedly subjective) approach, but an approach that would work where there isn't sufficient expressive ability right now. Thanks for your patience with me. .......... Ken -- G. Ken Holman mailto:gkholman@xxxxxxxxxxxxxxxxxxxx Crane Softwrights Ltd. http://www.CraneSoftwrights.com/s/ Box 266, V: +1(613)489-0999 Kars, Ontario CANADA K0A-2E0 F: +1(613)489-0995 Training: http://www.CraneSoftwrights.com/s/schedule.htm Resources: http://www.CraneSoftwrights.com/s/resources.htm Shareware: http://www.CraneSoftwrights.com/s/shareware.htm Next XSL Training (see training link): WWW8 - 1999-05-11 XSL-List info and archive: http://www.mulberrytech.com/xsl/xsl-list
Current Thread |
---|
|
<- Previous | Index | Next -> |
---|---|---|
Re: Feature Request - Node Set Proc, James Clark | Thread | Re: Feature Request - Node Set Proc, James Clark |
referencing XML tag name in XSL, Larry Chen | Date | Re: Feature Request - Node Set Proc, James Clark |
Month |