[XSL-LIST Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: removing final space from node tree
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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|