W3C home > Mailing lists > Public > public-qt-comments@w3.org > July 2016

[Bug 29763] New: [XSLT30] overriding xsl:param with xsl:variabe or vice versa should be disallowed

From: <bugzilla@jessica.w3.org>
Date: Sun, 31 Jul 2016 14:09:47 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29763-523@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29763

            Bug ID: 29763
           Summary: [XSLT30] overriding xsl:param with xsl:variabe or vice
                    versa should be disallowed
           Product: XPath / XQuery / XSLT
           Version: Candidate Recommendation
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: XSLT 3.0
          Assignee: mike@saxonica.com
          Reporter: abel.braaksma@xs4all.nl
        QA Contact: public-qt-comments@w3.org
  Target Milestone: ---

We say in xsl:override that you can override when two components are
homonymous. That term is defined with reference to *symbolic identifier*, which
reads:

[Definition: The symbolic identifier of a component is a composite name used to
identify the component uniquely within a package. The symbolic identifier
comprises the kind of component (stylesheet function, named template,
accumulator, attribute set, global variable, key, or mode), the expanded QName
of the component (namespace URI plus local name), and in the case of stylesheet
functions, the arity.]

We mention here "global variable", which refers to both xsl:variable and
xsl:param. But we also say "the same kind of component", and I think that the
component declared with xsl:param is different (not homonymous) from one
defined with xsl:variable.

Max Toro reported this in Bug 29574, comment 18, claiming you can *convert* a
variable into a parameter this way (or vv). I don't think this was an intended
behavior and if the WG agrees, I would like this behavior to be an error
scenario: an xsl:param cannot be overridden by an xsl:variable, or the other
way around.

Note also that an xsl:param is implicitly public and has no @visibility. An
xsl:variable has a visibility. I don't think we need the complexity of the
interactions of these rather confusing/conflicting declarations if you try to
override them.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Sunday, 31 July 2016 14:09:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:58:01 UTC