Thank you Abel for your understanding :-) and thank you Mike for pointing
out how the combined condition/predicate was actually being handled in
Saxon. By a fluke the "wrong" evaluation was actually leading to the "right"
output in the first test case I looked at.

But the biggest clue that something else was wrong was that when I separated
that expression into two ANDed conditions and tried passing that through
Saxon I got the "wrong" answer after all.

So (as I'm sure you all knew all along) this was obviously going to be an
error somewhere else in the stylesheet, and it was something silly: all
these named templates have a parameter named Arg which (at the beginning of
the pipeline) is "." and which progressively may or may not lose characters
from front or rear. In one place the "." slipped into the code instead of
"$Arg", and the template operated on the original text node instead of the
partly processed one.

It roundtrips beautifully now, thank you for your assistance.

Cheers
Trevor

-----Original Message-----
From: Abel Braaksma [mailto:abel.online@xxxxxxxxx] 
Sent: Thursday, 3 July 2008 2:42 a.m.
To: xsl-list@xxxxxxxxxxxxxxxxxxxxxx
Subject: Re: [xsl] invalid xpath?

Hi Trevor,

You do not show how you want the output of your samples, i.e., with or 
without preserved whitespace (the leading/trailing space). Like Michael 
Ludwig, I think it easiest both for you and for us to extract the 
(included) stylesheets that together do your whitespace handling and 
post that. It should work standalone and if it does, it will be easier 
to put back in.