- From: <bugzilla@jessica.w3.org>
- Date: Sun, 31 Jul 2016 14:09:47 +0000
- To: public-qt-comments@w3.org
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