Saxon

Nathan Claeys wrote:

Example: concat('A', ' ', ' ', 'B') results in 'A B' and not the expected 'A B'

Ok so I should have put this into a code block, the tracker platform does its own formatting on spaces

Example:
concat('A', '         ', ' ', 'B') results in 'A B' and not the expected 'A          B'

Thanks for reporting it.

I seem to be getting the incorrect results when I run from the command line in a terminal, but correct results when I run from my development environment under exactly the same conditions. It does seem to be highly dependent on the exact execution scenario -- and difficult to debug if I can't reproduce it in my normal debugging environment.

The arguments to concat() are all string literals so the actual concatenation is done at compile time, which makes it particularly hard to see how it can depend on anything in the run-time environment.

A puzzle.

I got it to fail in the IDE by running without a Saxon-EE license.

Which (a) explains the difference, and (b) gives me an easy route forward for debugging.

OK, got it. The problem is in the XML indenter - which explains why there's no problem when writing to a DOM.

With optimization suppressed, we are not pre-evaluating the concat() calls, rather we are evaluating concat() in push mode, effectively writing each of the arguments to concat() as a separate text node, rather than building the concatenated string and sending it to the serializer as a unit.

The indenter is buffering whitespace text nodes, on the grounds that in some circumstances (but not here) it can drop whitespace text nodes in order to improve the indented output.

But it only buffers one whitespace text node, and if it receives a second, the first is simply discarded.

So the effect is that if you write two consecutive whitespace text nodes to an indenting serializer (using concat or otherwise), the first one is discarded.

Remarkable how that hasn't been noticed before.