DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
<http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17265>.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17265

substring-before and substring-after

[EMAIL PROTECTED] changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED



------- Additional Comments From [EMAIL PROTECTED]  2003-02-21 22:36 -------
Hi Henry,

This is fixed -- we missed several errata in the XPath recommendation regarding 
substring-after() and substring-before() when the second string is of length 
0.  However, I just want to make sure you understand the implications of how 
you're passing the parameter which is the second string.

This:

<xsl:with-param name="split">&#xA;</xsl:with-param>

creates a param that is a result tree fragment.  Furthermore, its string value 
is an empty string, because of the whitespace stripping rules of stylesheets.  

Thus, this version:

   <xsl:with-param name="split">&#xA;&#xA;</xsl:with-param>

is identical -- the string value is an empty string.  Contrast that with this:

  <xsl:with-param name="split"><xsl:text>&#xA;&#xA;</xsl:text></xsl:with-param>

which will have a string value of 2 newline characters.

It's far more efficient to do the following:

  <xsl:with-param name="split" select="'&#xA;'"/>
  <xsl:with-param name="split" select="'&#xA;&#xA;'"/>

and it has the added benefit of being more predictable.

Hope that makes sense...

Reply via email to