https://saxonica.plan.io/https://saxonica.plan.io/favicon.ico2021-10-08T11:49:55ZSaxonica Developer CommunitySaxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186012021-10-08T11:49:55ZMartin Honnenmartin.honnen@gmx.de
<ul></ul><p>If the two <code>xsl:mode</code> declarations are reordered to have the one with the explicit <code>streamable="yes"</code> last, as in</p>
<pre><code class="xml syntaxhl" data-language="xml"><span class="cp"><?xml version="1.0" encoding="utf-8"?></span>
<span class="nt"><xsl:stylesheet</span> <span class="na">xmlns:xsl=</span><span class="s">"http://www.w3.org/1999/XSL/Transform"</span>
<span class="na">version=</span><span class="s">"3.0"</span>
<span class="na">xmlns:xs=</span><span class="s">"http://www.w3.org/2001/XMLSchema"</span>
<span class="na">exclude-result-prefixes=</span><span class="s">"#all"</span>
<span class="na">expand-text=</span><span class="s">"yes"</span><span class="nt">></span>
<span class="nt"><xsl:mode</span> <span class="na">on-no-match=</span><span class="s">"shallow-copy"</span><span class="nt">/></span>
<span class="nt"><xsl:template</span> <span class="na">match=</span><span class="s">"/"</span> <span class="na">name=</span><span class="s">"xsl:initial-template"</span><span class="nt">></span>
<span class="nt"><xsl:next-match/></span>
<span class="nt"><xsl:comment></span>Run with {system-property('xsl:product-name')} {system-property('xsl:product-version')} {system-property('Q{http://saxon.sf.net/}platform')}<span class="nt"></xsl:comment></span>
<span class="nt"></xsl:template></span>
<span class="nt"><xsl:mode</span> <span class="na">streamable=</span><span class="s">"yes"</span><span class="nt">/></span>
<span class="nt"></xsl:stylesheet></span>
</code></pre>
<p>then both Saxon EE 10.6 Java and SaxonCS EE 11 stream.</p>
<p>So the order seems to perhaps in the first, not streamed test case make Saxon use the implicit default of <code>streamable="no"</code> of the second <code>xsl:mode</code> declaration.</p>
<p>But my reading of the spec's text "For the unnamed mode, the <strong>effective value of each attribute</strong> is taken from an xsl:mode declaration that has no name attribute, and that <strong>specifies an explicit value for the required attribute</strong>. 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 <code>xsl:mode</code> with an explicit <code>streamable="yes"</code> and no later, higher import precedence explicit <code>streamable="no"</code>, that the explicit <code>streamable="yes"</code> defines the effective value.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186402021-10-17T21:28:57ZMichael Kaymike@saxonica.com
<ul></ul><p>The following query:</p>
<pre><code>-qs:"collection('/Users/mike/GitHub/xslt30-test/tests/attr/mode?select=*.xsl')[count(distinct-values(//*:mode/string(@name))) lt count(//*:mode)]/base-uri(.)"
</code></pre>
<p>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.</p>
<p>So the whole area is grossly under-tested.</p>
<p>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.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186412021-10-18T09:05:32ZMichael Kaymike@saxonica.com
<ul><li><strong>Status</strong> changed from <i>New</i> to <i>In Progress</i></li></ul><p>I'm tackling this by moving some of the logic for setting properties of a mode from <code>XSLMode.prepareAttributes()</code> to <code>SimpleMode.checkForConflictingProperties()</code>.</p>
<p>I'm now getting a couple of test failures because <code>TemplateRule.isDeclaredStreamable()</code> is (apparently) being called before the relevant property of the Mode object has been computed.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186422021-10-18T09:26:39ZMichael Kaymike@saxonica.com
<ul></ul><p>Fixed this by moving the call on <code>ruleManager.checkConsistency()</code> to come earlier in the sequence of tasks performed by <code>PrincipalStylesheetModule.compile()</code>.</p>
<p>Now getting xslt30 test failures:</p>
<pre><code>Failures by Test Set:
error : 1 (error-0540a)
match : 3 (-082b, -082c, -260)
</code></pre> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186432021-10-18T10:02:24ZMichael Kaymike@saxonica.com
<ul></ul><p>That's now fixed - I overlooked <code>on-multiple-match="fail"</code> in the <code>checkConsistency()</code> logic.</p>
<p>The other thing missing from that code is handling of the visibility attribute. I think that needs some extra tests.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186442021-10-18T10:13:06ZMichael Kaymike@saxonica.com
<ul><li><strong>Subject</strong> changed from <i>Saxon builds tree although there is an explicit xsl:mode streamable="yes"</i> to <i>Incorrect handling of multiple xsl:mode declarations for the same mode</i></li></ul> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=186452021-10-18T16:20:18ZMichael Kaymike@saxonica.com
<ul><li><strong>Status</strong> changed from <i>In Progress</i> to <i>Resolved</i></li><li><strong>Assignee</strong> set to <i>Michael Kay</i></li><li><strong>Fix Committed on Branch</strong> <i>10, trunk</i> added</li></ul> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=192132022-02-01T17:58:11ZO'Neil Delprattoneil@saxonica.com
<ul><li><strong>% Done</strong> changed from <i>0</i> to <i>100</i></li><li><strong>Fixed in Maintenance Release</strong> <i>11.1</i> added</li><li><strong>Platforms</strong> <i>.NET, Java</i> added</li></ul><p>Bug fix applied in the Saxon 11.1 release.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=192832022-02-01T21:08:32ZO'Neil Delprattoneil@saxonica.com
<ul></ul><p>Leaving bug as resolved until fix applied to the Saxon 10 maintenance release.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=197172022-03-01T14:53:58ZDebbie Lockettdebbie@saxonica.com
<ul><li><strong>Status</strong> changed from <i>Resolved</i> to <i>Closed</i></li><li><strong>Fixed in Maintenance Release</strong> <i>10.7</i> added</li><li><strong>Fixed in Maintenance Release</strong> deleted (<del><i>11.1</i></del>)</li></ul><p>Bug fix applied in the Saxon 10.7 maintenance release.</p> Saxon - Bug #5118: Incorrect handling of multiple xsl:mode declarations for the same modehttps://saxonica.plan.io/issues/5118?journal_id=197962022-03-01T15:18:23ZDebbie Lockettdebbie@saxonica.com
<ul><li><strong>Fixed in Maintenance Release</strong> <i>11.1</i> added</li></ul>