Re: [xsl] flatened hiearchies for xslt2

[ac <ac@xxxxxxxxxxxxx>]

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"/>
to
<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:

<dimitri>
   <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 -->
                   </task>
                   <!-- all level="5" tasks, but the first -->
               </task>
               <!-- all level="4" tasks, but the first -->
           </task>
           <!-- all level="3" tasks, but the first -->
       </task>
       <!-- all level="2" tasks, but the first -->
   </task>
   <!-- all level="1" tasks, but the first -->
</dimitri>

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,
Andre