Saxon

If the two xsl:mode declarations are reordered to have the one with the explicit streamable="yes" last, as in

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
  version="3.0"
  xmlns:xs="http://www.w3.org/2001/XMLSchema"
  exclude-result-prefixes="#all"
  expand-text="yes">

  <xsl:mode on-no-match="shallow-copy"/>

  <xsl:template match="/" name="xsl:initial-template">
    <xsl:next-match/>
    <xsl:comment>Run with {system-property('xsl:product-name')} {system-property('xsl:product-version')} {system-property('Q{http://saxon.sf.net/}platform')}</xsl:comment>
  </xsl:template>

  <xsl:mode streamable="yes"/>

</xsl:stylesheet>

then both Saxon EE 10.6 Java and SaxonCS EE 11 stream.

So the order seems to perhaps in the first, not streamed test case make Saxon use the implicit default of streamable="no" of the second xsl:mode declaration.

But my reading of the spec's text "For the unnamed mode, the effective value of each attribute is taken from an xsl:mode declaration that has no name attribute, and that specifies an explicit value for the required attribute. If there is no such declaration, the default value of the attribute is used. If there is more than one such declaration, the one with highest import precedence is used." is that, as long as there is an xsl:mode with an explicit streamable="yes" and no later, higher import precedence explicit streamable="no", that the explicit streamable="yes" defines the effective value.

The following query:

-qs:"collection('/Users/mike/GitHub/xslt30-test/tests/attr/mode?select=*.xsl')[count(distinct-values(//*:mode/string(@name))) lt count(//*:mode)]/base-uri(.)"

demonstrates that there is only one test (mode-1502) that has more than one mode with the same name; and that is testing the error case where there are conflicting values for the same attribute.

So the whole area is grossly under-tested.

The Saxon implementation in XSLMode (a) succeeds in creating a single Mode object corresponding to the multiple xsl:mode elements, and (b) (in the validate() method) creates a data structure representing the properties of these modes, identifying conflicts and identifying the one with highest import precedence. But the prepareAttributes() method updates the properties of the mode directly, ignoring this data structure, and the properties are also accessed directly.

Fixed this by moving the call on ruleManager.checkConsistency() to come earlier in the sequence of tasks performed by PrincipalStylesheetModule.compile().

Now getting xslt30 test failures:

Failures by Test Set: 
  error : 1 (error-0540a)
  match : 3 (-082b, -082c, -260)

That's now fixed - I overlooked on-multiple-match="fail" in the checkConsistency() logic.

The other thing missing from that code is handling of the visibility attribute. I think that needs some extra tests.

Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.