[XSL-LIST Mailing List Archive Home] [By Thread] [By Date]

Re: [xsl] removing final space from node tree


Subject: Re: [xsl] removing final space from node tree
From: Lars Huttar <lars_huttar@xxxxxxx>
Date: Mon, 20 Apr 2009 16:40:47 -0500

On 4/20/2009 3:18 PM, Michael Ludwig wrote:
> Lars Huttar schrieb am 20.04.2009 um 15:09:31 (-0500):
> 
>> Unfortunately, this means that the text content of each output
>> <lanuguage-desc> element often ends with an unwanted space. Worse, this
>> extra space causes confusion downstream. So the question is, how to get
>> rid of this extra space (if any)?
> 
>> My concern is that this seems like a very complex way to have to
>> eliminate a final space.
> 
> Hi Lars,
> 
> sounds like you should be able to solve this using normalize-space().
> 
> Michael Ludwig
> 

Thanks, Michael. How would you apply normalize-space()? As far as I
recall, it only outputs a single string, right? So if I applied it to
the whole output of the initial transformation, I would lose all element
structure. If I applied it to each text node of the initial
transformation, I would lose the spaces that separate each bit of text
from the next.

On 4/20/2009 3:38 PM, Wendell Piez wrote:
> Lars,
>
> How about, instead of post-processing the results of processing, you
> simply don't add the spaces the first time through, and then you add
> them in as a post-process?
>
> This would borrow from both your solutions -- like your first solution,
> it divides the task into two phases. But like the second, it determines
> whether to add the space to begin with -- not whether to remove it after
> it's been added. It would do this, however, not by examining the source
> to say "do I want a space here", but by examining the result (where this
> determination will be much easier).

Thanks, Wendell.
That certainly makes sense.
However I'm not sure I see a significant win over my existing solution.
I would still be adding a post-processing phase that recurses over  the
initial output tree and reconstructs it most of the time.
Please clue me in if I've missed something big...

Also, I'm pretty sure the initial output tree doesn't always contain
enough markup to determine where boundaries between output phrases are.
The initial transformation sometimes just outputs bare strings.

On the other hand, if it's true that Wendell Piez couldn't immediately
see a much more elegant way to accomplish this task, that would increase
my confidence that my current solution is pretty decent.  :-)

Lars


Current Thread