Re: [xsl] Unexpected result from <a href="...">...</a> in some cases

Subject: Re: [xsl] Unexpected result from <a href="...">...</a> in some cases
From: Quinn Taylor <quinntaylor@xxxxxxx>
Date: Tue, 19 Aug 2008 21:02:56 -0600
On Aug 19, 2008, at 6:50 PM, G. Ken Holman wrote:

What result to you expect for your test string "/path/to/resource"?

<a href="../../../">[root]</a> / <a href="../../">path</a> / <a href="../">to</a> / resource

What result to you expect for "/to/resource"?

<a href="../../">[root]</a> / <a href="../">to</a> / resource


What result to you expect for "/resource"?

<a href="../">[root]</a> / resource

Got it.



I also got lost in your code with the definition of the variable "recursiveResult" and pulling it apart again ... I couldn't see why the variable would be necessary and not just generate each step as required.

Below is what I think is a complete result, without the need for such a variable. I've tried to document it to explain the approach.

I hope this helps.

. . . . . . . . . . . Ken

<snip>

Ken, thanks so much for taking the time to help out. Sure enough, your solution works as advertised. :-)


One thing I'd like to simplify/optimize is the number of recursive descents. It seems that your code recurses all the way down to the base case and back up for each path element to correctly construct the parent href. This is certainly not an O(n^3) algorithm, but it seems like a triangular number (http://mathworld.wolfram.com/TriangularNumber.html ). For very long paths, this creates more work than necessary. Even so, I'll take what works over what doesn't. :-)

- Quinn

Current Thread