This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 29094 - [xslt 3.0] conflict between xsl:accept and xsl:override
Summary: [xslt 3.0] conflict between xsl:accept and xsl:override
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Last Call drafts
Hardware: PC All
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-28 08:32 UTC by Michael Kay
Modified: 2015-10-29 12:42 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2015-08-28 08:32:30 UTC
Consider:

<xsl:use-package name="Q">
  <xsl:accept component="variable" name="v" visibility="hidden"/>
  <xsl:override>
    <xsl:variable name="v" select="93.7"/>
  </xsl:override>
</xsl:use-package>

The current spec suggests that the xsl:override wins (xsl:accept says "In the absence of a matching xsl:override element ...) and essentially assigns no semantics to the xsl:accept declaration in this case.

I think it would be consistent with the decision on bug #26781 to raise an error in the case where xsl:accept names a component explicitly (not by wildcard) and there is an xsl:override for the same component.
Comment 1 Abel Braaksma 2015-09-30 02:19:19 UTC
An alternative thought is: the user wants to hide this component from his current stylesheet (principal package), but override the value for the used package. Which I think is a valid thought in and of itself.
Comment 2 Michael Kay 2015-10-07 21:06:36 UTC
Comment #1 suggests a possible interpretation of my example, but I think if we wanted to provide that particular capability it would make more sense to do so by allowing the declaration within xsl:override to specify visibility="hidden". But that's new functionality that I think we can live without. I therefore propose the rule:

It is a static error if a token in the names attribute of an xsl:accept element, other than a wildcard, matches the symbolic name of a component declared within an xsl:override element that is a sibling of the xsl:accept element.
Comment 3 Michael Kay 2015-10-09 11:32:57 UTC
The WG accepted the proposed change. New text added as follows:

<item diff="add" at="S-bug29094">
    <p>If a component is explicitly accepted from a used package (by name, rather
        than by a matching wildcard, and if the same component is the subject
        of an <elcode>xsl:override</elcode> declaration, then a static error
        occurs (see below). There is no conflict, however, if a component declared
        within <elcode>xsl:override</elcode> also matches a wildcard in an <elcode>xsl:accept</elcode>
        element.</p>
    <p>
        <error spec="XT" type="static" class="SE" code="3051">
            <p>It is a <termref def="dt-static-error">static error</termref> if
                a token in the <code>names</code> attribute of <elcode>xsl:accept</elcode>,
                other than a wildcard, matches the symbolic name of a component declared
                within an <elcode>xsl:override</elcode> child of the same
                <elcode>xsl:use-package</elcode> element.</p>
        </error>
    </p>
</item>