Re: [xsl] flatened hiearchies for xslt2

Subject: Re: [xsl] flatened hiearchies for xslt2
From: ac <ac@xxxxxxxxxxxxx>
Date: Wed, 07 Mar 2007 23:44:14 -0500
Hi everyone, and especially David, Patrick, and Dimitri who each proposed different and interesting solutions for a question that I had,

I tried all 3 approaches in a test bed integrated with our applications and I have a few comments and additional questions:

First David, yours works fine, but I had to modify

<xsl:param name="s" select="section"/>
<xsl:param name="s" select="following-sibling::*"/>

as recursive template invocation would try to go down a hierarchy that does not exists in the source sequence.

Patrick, I could not get yours to work properly and it unfortunately seems to depend on the ID structure (ex: starts-with(@id, $parentID), which I mentioned could not be relied upon. Also, every time makeLevel is called recursively, it tries to get the child::section, but the source is a plain sequence not a recursive structure, except maybe for an initial all containing section. I am not sure how to fix this and would appreciate your help, if you feel.

Dimitri, your solution seems quite ingenious and compact, except maybe for the potential size of the key. The main issue though is that it is not currently maintaining the logical structure integrity. What I am currently getting looks like:

   <task id="0" level="1">
       <task id="1-1" level="2">
           <task id="1-1-1" level="3">
               <task id="1-1-1-1" level="4">
                   <task id="1-1-1-1-1" level="5">
                       <task id="1-1-1-1-3-1" level="6"/>
                       <!-- all level="6" tasks, but the first -->
                   <!-- all level="5" tasks, but the first -->
               <!-- all level="4" tasks, but the first -->
           <!-- all level="3" tasks, but the first -->
       <!-- all level="2" tasks, but the first -->
   <!-- all level="1" tasks, but the first -->

Where the first node of every level is in the right section but where others are grouped by level, irrespective of their family (parent/child) relationships, as if they had lost their source document order. While it may seem ok on the small sample I had provided, it does not yet restore any initial logical structure. I have not yet figured out how to rectify this but you can possibly give me a clue.

In any case, for Dimitri and Patrick, if I can get your versions to work properly, I would like to then compare performance in a real application, and return the results.

I very much appreciate your support and interesting solutions.

Thank you,

Current Thread