Re: [xsl] flatened hiearchies for xslt2

Subject: Re: [xsl] flatened hiearchies for xslt2
From: "Dimitre Novatchev" <dnovatchev@xxxxxxxxx>
Date: Thu, 8 Mar 2007 06:35:08 -0800
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>

Hmm, I usually reply to messages very early in the morning, possibly sometimes feeling sleepy.

Just change in my code:

<xsl:key name="kChildren" match="section"
  use="generate-id(preceding::section
                        [@level = current()/@level - 1]
                        [last()]
                   )"
/>

With:

<xsl:key name="kChildren" match="section"
  use="generate-id(preceding::section
                        [@level = current()/@level - 1]
                        [1]
                   )"
/>


and now you'd be getting the correct results.


Hope this helped.


-- Cheers, Dimitre Novatchev --------------------------------------- Truly great madness cannot be achieved without significant intelligence. --------------------------------------- To invent, you need a good imagination and a pile of junk ------------------------------------- You've achieved success in your field when you don't know whether what you're doing is work or play



On 3/7/07, ac <ac@xxxxxxxxxxxxx> wrote:
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

Current Thread