Hi Marcus,
This kind of problem can be a fun challenge.
If you don't have a lot of XSLT experience (and sometimes even if you do),
the hard part of a problem like this is knowing which are the hard bits,
and which not.
In this case, it's the node selection logic that is the hard part: how do
you traverse the tree including just the nodes you want? The easy part is
rendering those nodes as you select them. (Indenting can readily be
achieved by iterating over ancestors of a node and putting out whitespace
for each ancestor.)
So how to select the nodes? One clue can be gotten by keeping in mind that
by default the XSLT processor goes top-down, and in fact since this is how
you want your rendition to appear, this is the right way to go.
This means translating your logic specifying which nodes you want to
include to a top-down model. As it happens, this is pretty straightforward:
starting at the document element (not the root node)
A. process all its children
with each child encountered:
if it is an ancestor-or-self of your target node
mark with 'minus', and
if it's an ancestor, return to A
if it's the target node, just write the children
if not
if it has children, mark with 'plus'
in any case, write it out
This reduces the logic to a recursive process that is easily enough
achieved using XSLT's processing model. The only trick is in that test:
when processing a node, how do you know it's an ancestor of your target
node (or the target node itself)?
Assume you have bound your target node to a variable:
<xsl:variable name="target" select="//*[(_at_)id='somethingorother']"/>
In this case, a current node "." is among the ancestor elements of the
target, or the target itself, if it passes the following test:
count($target/ancestor-or-self::*) = count(. | $target/ancestor-or-self::*)
(If you want to improve efficiency a mite you can bind the left side to a
variable, since it's always the same.)
Likewise, the current node "." is the target when
count(. | $target) = 1
(XSLT 1.0 idiom for testing node identity.)
I hope that's enough to get you moving.
Hint: don't traverse up from the target node. Instead, traverse down from
the document element, testing as you go. The tests will determine whether
to descend any particular branch of the tree.
Another hint: modes are your friends.
Ask again if I'm being too sketchy here. And good luck,
Wendell
At 04:16 PM 5/4/2004, you wrote:
Hi gurus
I want to generate an "unfolded" tree down to a selected element. So I
want to render all ancestors to the selected element and all their
siblings but not the siblings children. Also, the root shouldn't be
included and I don't want the siblings to the top-level (below the root
element) ancestor to be included. Another wish is that if the selected
element is a section element I also want to render it's children (just one
level though).
Example source XML:
<site>
<section name="level1_1">
<section name="level2_1>
<page name="level3_1"/>
</section>
<section name="level2_2"/>
<page name="level2_3"/>
<page name="level2_4"/>
<section name="level2_5">
<section name="level3_1">
<page name="level4_1"/>
</section>
<page name="level3_2"/>
<section name="level3_3"> <-- Selected element
<page name="level4_1"/>
<page name="level4_2"/>
</section>
<page name="level3_4"/>
</section>
</section>
<page name="level1_2"/>
<section name="level1_3">
...
</section>
</site>
Wanted result (with indents and everything :) :
node name="level1_1"
node name="level2_1"
node name="level2_2"
node name="level2_3"
node name="level2_4"
node name="level2_5"
node name="level3_1"
node name="level3_2"
node name="level3_3"
node name="level4_1" //shouldn't be rendered if page
node name="level4_2" //shouldn't be rendered if page
node name="level3_4"
It would also be nice if one could draw something extra to indicate
whether the node has children or not (like a plus or minus...).
How would you do it? I've made a couple of tries with
anscestor-or-self::etc but I just tangle myself into hairy loops.
The template/templates that will do this will be called on the selected
element level.
/Marcus
ps. I'm using MSXML so node-set() is available.
======================================================================
Wendell Piez
mailto:wapiez(_at_)mulberrytech(_dot_)com
Mulberry Technologies, Inc. http://www.mulberrytech.com
17 West Jefferson Street Direct Phone: 301/315-9635
Suite 207 Phone: 301/315-9631
Rockville, MD 20850 Fax: 301/315-8285
----------------------------------------------------------------------
Mulberry Technologies: A Consultancy Specializing in SGML and XML
======================================================================