4

All XSLT editors I've tried till now add tab or space characters to the XSLT to indent it for formatting. This is done even in places within the XSLT where these characters are significant to the XSLT processor.

XSLT modified for formatting in this way can produce output very different to that of the original XSLT if it had no formatting. To prevent this, xsl:text elements or other XSLT must be added to a sequence constructor to help separate formatting from content, this additional XSLT impacts on maintainability. Formatting characters also adversely impact on general usability of the tool in a number of ways (this is why word-processors don't use them I guess) and add to the size of the file.

As part of a larger project I've had to develop a light-weight XSLT editor, it's designed to format XSLT properly, but without tab or space characters, just a dynamic left-margin for each new line. The XSLT therefore doesn't need additional elements to separate formatting tab or space characters from content. The problem with this is that if XSLT from this editor is opened in other XSLT editors, characters will be added for formatting reasons and the XSLT may therefore no longer behave as intended.

Why then do existing XSLT editors use tabs or spaces for formatting in the first place?

I feel there must be valid reasons, perhaps historical, perhaps practical. An answer will help me understand whether I need to put compatibility options in place in my XSLT editor somehow, whether I should simply revert to using tabs or spaces for both XSLT content and formatting (though this seems like a backwards step to me), or even whether enough XSLT users might be able to persuade their tools vendors to include alternative formatting methods to tabs or spaces.

Note: I provided an XSLT sample demonstrating formatting differences in this answer to the question: Tabs versus spaces—what is the proper indentation character for everything, in every situation, ever?

Community
  • 1
pgfearo
  • 944
  • 4
  • 11
  • 19

3 Answers3

3

Why then do existing XSLT editors use tabs or spaces for formatting in the first place?

I would imagine because

  • This feature was already default in HTML, XML, and similar editors on which the XSLT editing environment is based
  • Spaces/Tabs improve legibility of the file, and adding actual spaces is easier than adding virtual spaces
  • Users may have opinions about how much whitespace to put where, and these opinions are sometimes informed.
  • Line breaks mean line-based error messages are meaningful
  • In most contexts, extra whitespace in XSLT has no effect on the resulting document
  • In the contexts where it does have an effect on the resulting document, in at least some cases the semantics of that document won't change.

The only real problem for XSLT is whitespace in mixed content. In this case, as you note, you can use xsl:text. Yes, it adds overhead, and it's annoying at times.

But in several years of working with XSLT in practice (including using it to do lots of fiddly punctuation-related tasks), my impression is that, on balance, it's not a bad thing. In fact, I would generally discourage entry of raw text in any context other than xsl:text because of the danger of the significant whitespace issue.

Insertion of plain static text in XSLT is generally something you want to do only sparingly and after careful consideration. Most of XSLT's power and expressiveness is in its ability to reshape data, rather than its text-processing capabilities. Deciding to do add whole text nodes is worthy of an extra tag to flag up 'this is deliberately doing something slightly unusual'.

Because of this and because of the nature of markup and text in XML and XSLT, text processing tasks need to be done carefully. Putting each text node in its own element on its own line, on a par with other nodes and instructions helps in that conscious process.

Finally, it's worth bearing in mind that XSLT is not terse to begin with. An extra bit of overhead is therefore not a big deal. Storage on this level is cheap, and even if used frequently, additional transfer costs will be negligible once gzipping is taken into account.

I would encourage you to think again about the "a dynamic left-margin for each new line" solution, and suggest that you instead code something which gracefully handles mixed content by automatically wrapping the necessary elements in xsl:text (which you could hide). This would make the XSLT you generate more resilient to other tools.

user52889
  • 1,683
  • 11
  • 13
  • Line breaks I'm more than happy with,I also use extra space chars for special formatting of long xpath expressions, but the indentation proportional to nesting could (and should in my view) be fully automated. Do you know of an editor that doesn't corrupt intricate xpath formatting when you press the reformat button? – pgfearo Oct 02 '15 at 04:25
  • "Adding actual spaces is easier than adding virtual spaces" - my experience from writing an xslt editor is the reverse. To behave well, code editors have to track all the white space they've added, but this is non-trivial. With virtual spaces the editor knows that all white space chars have been explicitly added by the user and should therefore always be kept. – pgfearo Oct 02 '15 at 04:44
  • I should add that I'm resigned to the fact that current indentation methods will prevail for a long while, to help remedy their inevitable formatting issues, I use (and develop) XMLSpectrum - this tries to understand the different kinds of white space before reformatting it – pgfearo Oct 02 '15 at 04:54
1

Everyone building editors for the last 20 years has started from the perspective of vi, Emacs, Visual Studio, or one of their equivalents. Back in 1985, when Mike Cowlishaw wrote one of the first SGML editors (LEXX) for the Oxford English Dictionary's digitalization project, he did exactly what your XSLT editor does - separate visualization from representation. It's a shame that never really caught on.

Ross Patterson
  • 10,277
  • 34
  • 43
  • To promote the idea, a few years ago I developed a free XML editor, XMLquire that does this, it still gets 100 or so downloads a week but never made it into the main stream, being Windows-only didn't it's cause – pgfearo Oct 02 '15 at 04:31
0

Because those writing the XSLT editor, don't use it themselves to write XSLT, and confuse it with plain XML where whitespace matters less.

  • I think most developers of XSLT editors will ultimately listen to what there users ask them for. So perhaps, perhaps people aren't asking for a solution to this whitespace problem loud enough? – pgfearo Sep 16 '11 at 20:09
  • 2
    In fact, the people of oXygen, Stylus Studio and others are active members of the XSLT community. In mailing groups, on discussion forums and even in the standardization committees. They do use it themselves. How otherwise would they be able to know how a good tool is supposed to behave? – Abel Sep 16 '15 at 23:17