Saxon

I ran this stylesheet:

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet exclude-result-prefixes="#all" version="3.0"
   xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
   
   <xsl:param name="p1" select="4, 4"/>
   <xsl:param name="p2" select="88, 6"/>
   <xsl:template name="xsl:initial-template">
    <out>
       <xsl:value-of select="1 , $p1 eq $p2"/>
    </out>
 </xsl:template>
   
</xsl:stylesheet>

and got this output:

Type error at char 5 in expression in xsl:value-of/@select on line 9 column 47 of test.xsl:
  XPTY0004  A sequence of more than one item is not allowed as the first operand of 'eq' (4, 4) 
at variable vv:gg854487022 on line 9 column 0 of test.xsl:
     invoked by optimizer-generated global variable select="fn:string-join(...)" at file:/Users/mike/Desktop/temp/test.xsl#9
at template xsl:initial-template on line 7 column 46 of test.xsl:
A sequence of more than one item is not allowed as the first operand of 'eq' (4, 4)

The error information displayed by the standard error reporter includes the character offset within the XPath expression (5), the attribute in which this expression appears (xsl:value-of/@select), and the SAX-reported line and column of the stylesheet for the xsl:value-of element (line 9, col 47). So I don't think we're losing anything.

The above example forced the error to be detected at run time (by using xsl:param).

If we change this to a type error detected statically by changing xsl:param to xsl:variable, then we get a different message:

Error in xsl:value-of/@select on line 9 column 47 of test.xsl:
  XPTY0004  Required cardinality of first operand of 'eq' is zero or one; supplied value has
  cardinality more than one
Errors were reported during stylesheet compilation

which does indeed drop the character position within the XPath expression.

There are some complications here. The main one is attribute value normalization: the XSLT processor only gets to see the value of the attribute after the XML parser has applied AVN, which means everything is on one line and the character positions do not reflect the original. So we can't produce line/column positions within the attribute value, and character positions can be misleading. For this reason, with compile time errors we generally prefer to display nearby text (error near {$p1 * $p2} in xsl:value-of/@select at line X...) rather than character offset within the XPath expression text. This example, however, is a statically-reported semantic error, and for those cases we don't have the "nearby text" information, so perhaps reporting the character offset (as we do with dynamic errors) would be useful even though it is in general inaccurate.