Saxon

If I do something similar by making transform() call a template instead of a function, I do not see this problem.

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>

target-stylesheet-template.xsl containing named template¶

<?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="template-to-call">
    <xsl:sequence select="'output'"/>
  </xsl:template>
  
</xsl:stylesheet>

Well-formed trace result¶

<trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
 <xsl:template name="xsl:initial-template" line="8" column="45" module="parent-stylesheet-template.xsl">
  <xsl:variable name="transform-options" line="9" column="73" module="parent-stylesheet-template.xsl">
   <trace text="target-stylesheet-template.xsl" line="12" column="52" module="parent-stylesheet-template.xsl">
   </trace>
   <trace name="x" line="13" column="48" module="parent-stylesheet-template.xsl">
   </trace>
<trace saxon-version="12.4" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
    <xsl:template name="template-to-call" line="7" column="41" module="target-stylesheet-template.xsl">
    </xsl:template>
</trace>
  </xsl:variable>
 </xsl:template>
</trace>

Yes, I'm aware that the trace output is "pseudo-XML". There are cases I know about where namespace prefixes aren't declared. It would probably be a good idea to push the output through a proper serializer, but I've been a bit reluctant because the serializer is likely to do some buffering and it's important not to lose anything if the transformation terminates abruptly.

The issue I'm seeing is about a "trace" start tag without a matching end tag. I just wanted to point that out in case it isn't part of what you're already aware of.

For the missing trace end tag, I think I would need a repro. There are two possible causes: either the transformation is somehow being run using an API method that fails to write the end tag (and I can't find such a path), or the end tag is being written but not flushed to the output destination.

More generally, I think guaranteeing well-formed output from the trace is going to be a bit of a challenge. The most obvious case where we (apparently) make no attempt currently to achieve this is with try/catch. The other cases that are difficult are where the stylesheet uses multi-threading. Generally the combination of tracing and multi-threading is not going to produce comprehensible output, so the only options are (a) to disallow it, or (b) to produce output that is going to be hard to interpret (and probably ill-formed).

For the missing trace end tag, I think I would need a repro.

The "Sample XSLT 1, transform-function.xsl", "Sample XSLT 2, target-stylesheet-small.xsl", and "Saxon Command" sections of this issue writeup don't enable you to reproduce the problem with Saxon-HE 12.4? In case platform matters, I am using Windows. If there's other information I should provide, let me know.

Thanks for the observations about try/catch and multi-threading. Though they're not related to my specific reproduction steps here, they're useful to know. Anytime the trace isn't well-formed will be a situation where the code coverage feature in XSpec won't work, and maybe the XSpec documentation should describe limitations on the code coverage feature. So, if you think of any other situations where the trace from Saxon won't be well-formed or won't be accurate, I'd appreciate knowing the information.

I'm wondering whether code coverage shouldn't be using a completely different trace listener, which rather than trying to produce a sequential execution trace as output, maintains a histogram of which instructions have been executed how many times? Rather like the TimingTraceListener (-TP option), in fact, but without the timings?

That sounds like very good news. Thanks!

For Saxon 13, the standard trace listener now handles try/catch, so the output remains well-formed when dynamic errors are caught.