WSO2 XSLT Mediator substring-before tab separated string - xslt

Question

I'm trying to split a tab separated value string using substring-before I'm having a hard time because the XSLT mediator does not work as it should.
The xslt stylesheet:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:p576="http://p576.test.ws" version="1.0">
<xsl:output encoding="UTF-8" method="xml" indent="yes"></xsl:output>
<xsl:param name="NAMESPACE"></xsl:param>
<xsl:param name="LOG_ID"></xsl:param>
<xsl:template match="/">
<xsl:element name="Response" namespace="{$NAMESPACE}">
<xsl:if test="$LOG_ID">
<xsl:element name="LogId" namespace="{$NAMESPACE}">
<xsl:value-of select="$LOG_ID"></xsl:value-of>
</xsl:element>
</xsl:if>
<xsl:element name="Text" namespace="{$NAMESPACE}">
<xsl:value-of select="substring-before(//p576:execMRPCResponse/p576:execMRPCReturn, ' ')"></xsl:value-of>
</xsl:element>
</xsl:element>
</xsl:template>
</xsl:stylesheet>
The string:
999900418559 59 4730 Payment Created & Posted
Instead of cutting the string "999900418559" it cuts it here: "999900418559 59 4730 Payment" where a space is. The same result is achieved if you use substring-before '$#32;' meaning tab and space are converted to space when looking into the string.
Is there any way to keep this from happening? or if the problem is with the version of saxon used by wso2, should I update it (I'm using WSO2ESB v4.8.1)?

Answer 1

If tabs in the source document are being converted to spaces, then this is happening before Saxon gets to see the data. It could happen, for example, if the data is put through a schema validator and the type of the relevant element uses a whitespace facet of "collapse".
To prevent it happening, you first need to find out when and where it is happening, and there are no clues to that in your post (at least for someone who has never heard of WSO2ESB).
As a first diagnostic step, try to capture the exact form of the source document supplied as input to the transformation, and check the state of the whitespace it contains.
Having written that, I think there is another possibility, which is that the character reference in your stylesheet is being corrupted by whatever process it is that compiles the stylesheet. You could defend against that by replacing ' ' with codepoints-to-string(9).