Saxon

I'm not sure if this is related but decided to add it here (I can raise another issue if required).

I sometimes get the following java.lang.StringIndexOutOfBoundsException when using fn:transform():

java.lang.StringIndexOutOfBoundsException: start 0, end -1, length 16
        at java.base/java.lang.AbstractStringBuilder.checkRangeSIOOBE(AbstractStringBuilder.java:1724)
        at java.base/java.lang.AbstractStringBuilder.substring(AbstractStringBuilder.java:1017)
        at java.base/java.lang.StringBuilder.substring(StringBuilder.java:89)
        at net.sf.saxon.trace.AbstractTraceListener.spaces(AbstractTraceListener.java:251)
        at net.sf.saxon.trace.AbstractTraceListener.leave(AbstractTraceListener.java:190)
        at net.sf.saxon.expr.instruct.TraceExpression$TraceExpressionElaborator.lambda$elaborateForPush$3(TraceExpression.java:459)
        at net.sf.saxon.expr.instruct.Block$BlockElaborator.lambda$elaborateForPush$4(Block.java:895)
        at net.sf.saxon.expr.instruct.TraceExpression$TraceExpressionElaborator.lambda$elaborateForPush$3(TraceExpression.java:457)
        at net.sf.saxon.expr.instruct.ComponentTracer$ComponentTracerElaborator.lambda$elaborateForPush$2(ComponentTracer.java:344)
        at net.sf.saxon.expr.instruct.NamedTemplate.expand(NamedTemplate.java:247)
        at net.sf.saxon.trans.XsltController.callTemplate(XsltController.java:872)
        at net.sf.saxon.s9api.Xslt30Transformer.callTemplate(Xslt30Transformer.java:503)
        at net.sf.saxon.Transform.processFile(Transform.java:1391)
        at net.sf.saxon.Transform.doTransform(Transform.java:894)
        at net.sf.saxon.Transform.main(Transform.java:84)
Fatal error during transformation: java.lang.StringIndexOutOfBoundsException: start 0, end -1, length 16

It seems to happen when fn:transform() is called multiple times in quick succession. It does happen using the test case from issue 6302 if the following line is duplicated multiple times (I had it 3 times):

<xsl:sequence select="transform($transform-options)?output"/>

The stylesheet from the issue is:

Parent stylesheet that calls transform()¶

<?xml version="1.0" encoding="UTF-8"?>
<xsl:stylesheet
  xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="#all"
  version="3.0">
  
  <xsl:template name="xsl:initial-template">
    <xsl:variable name="transform-options" as="map(xs:string, item()*)">
      <xsl:map>
        <xsl:map-entry key="'delivery-format'" select="'raw'"/>
        <xsl:map-entry key="'stylesheet-location'">target-stylesheet-template.xsl</xsl:map-entry>
        <xsl:map-entry key="'source-node'"><x/></xsl:map-entry>
        <xsl:map-entry key="'initial-template'" select="QName('', 'template-to-call')"/>
      </xsl:map>
    </xsl:variable>
    <xsl:sequence select="transform($transform-options)?output"/>
  </xsl:template>
  
</xsl:stylesheet>

We're aware of a number of things that cause the trace output not to be well-formed:

• try-catch - there's no attempt to close tags relating to instructions that failed
• multi-threading (e.g. on xsl:result-document)

These are pretty fundamental, and difficult to fix.

We're getting a series of bugs relating to tracing in the context of XSpec, and it's increasingly clear to me that the feature as designed isn't fit for the purpose you are trying to use it for, and that incremental fixing of bugs isn't going to get you there. Perhaps it's time we had a rethink about exactly what you are trying to achieve, and see if we can find a better way?

Michael,

Putting Saxon and XSpec heads together to see if we can find a better way sounds good. Do you think we could try to schedule an interactive conversation? If not, do you want me to write up a little background about what XSpec is trying to achieve (and is there a better place for that content than this issue)? I believe you have my email address based on my saxonica.plan.io account, in case you want to contact me by email.

Thanks, Amanda

Let's try and schedule a Zoom call next week. Tuesday 15:00 UTC perhaps?. I think it would be useful to include Norm from our side.

That date and time work for me. Thank you.

Me too.