Editing Virtually Formatted XSLT

CoherentWeb's XSLT editor uses vitual formatting, where the XSLT is always properly indented, but without using tab or space characters. This absence of formatting characters allows us to write XSLT with much greater control of whitespace, without resorting to methods that affect the clarity and maintainability of the XSLT.

In the screenshots posted here, all characters except line-feeds are highlighted in yellow, so the space characters are clearly visible. (To highlight elements in this way in the XSLT editor, I just selected the document element in the outline treeview).

First, lets have a look at XSLT as edited in CoherentWeb:

Original XSLT - Clean of formatting characters

Before going on to review the output, lets switch the view to the left-justified, so we can check the alignment of text, no characters are modified for the view here, the left-margin is just collapsed. We can see clearly that 'Books' along with the '------' underline are going to be indented in the output, with the rest of the output text aligned to the left margin:

Now for the output which produces no surprises. The Books title is indented with space characters that were in the XSLT, all other lines are left-justified. The line-breaks are all output because they are in the XSLT as 'naked' text. The one exception is the line following ISBN, this is inserted using the value of $lf which has a line-feed \n as its string value. This is required because XSLT won't copy the whitespace-only node preceding the end tag into the result-tree.

Original Output

So, the above XSLT was relatively simple because there were no extra formatting characters that other XSLT editors use. To emulate their behaviour, I opened the orginal XSLT file in another XSLT editor and then just saved it again. When this did was insert formatting characters into content because the other editor needed to render it in a formatted way and didn't have virtual formatting. Now, to be fair, I could have modified the settings of this editor so that it didn't format the XSLT when opened, but then it wouldn't have been rendered properly.

Temporarily disabling CoherentWeb's normal trim behaviour (which would detect and selectively removed formatting characters), I then opened the file modified by the other editor and it looked like this:

The yellow highlighting shows us what the other XSLT editor did to our nice trim XSLT, look at all those space characters added for formatting!. Now, that other editor has been reasonably smart, because it knew the element must preserve whitespace, so thankfully it didn't insert formatting characters here. It did however ignore the whitespace preceding the Books line, choosing instead to pad the line for XML formatting purposes as if the leading whitespace wasn't there. This means we can't just trim the XML to get back what we started with, because the information about the extra whitespace has been lost by that editor. 

Now we have the file from the other editor, let's see what output we would get:

So, the extra space characters in the input are now being copied into the output.  The Books title is also no longer centered in the output formatting. This is expected behaviour for XSLT of course, all whitespace within a sequence contructor is significant unless it's within a whitespace-only node. The xsl:text element already mentioned is one way of remedying this, the extra effort required isn't too onerous, but for more complex XSLT it will affect readability:

The XSLT above has been modified to produce the required output, even when the XSLT has formatting whitespace characters inserted. The xsl:text element effectively turns the formatting characters into white-space only nodes which are not added to the result-tree. We also have to use instructions to insert line-feeds more frequently, I've used concat($lf, $lf) to this end.

So, the XSLT is no longer susceptible to formatting characters, but the cost is more complex XSLT. With CoherentWeb, I would strongly advise that your XSLT is ultimately hardened to work with editors that don't have Virtual formatting capabilities. But at least while doing initial design and development you have the option to use XSLT that more closely resembles the output you need.