- From: <bugzilla@jessica.w3.org>
- Date: Fri, 29 Apr 2016 08:41:26 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29574 --- Comment #10 from Michael Kay <mike@saxonica.com> --- visibility=absent ================= I think the way to handle this is that the effect of saying xsl:accept visibility=absent (in a module P that uses Q) is that the component C(P) (corresponding to the abstract component C(Q)) behaves as follows: (a) C(P) has visibility="hidden", meaning that component references to this symbolic name cannot be resolved (b) any attempt to invoke C(P) causes a dynamic error XTDE3952 (c) (in consequence of the above) P cannot expose C(P) with a visibility other than hidden, and a module R that uses P cannot accept or override C(P). Here (a) and (b) represent no change from existing behaviour, while (c) fills a current gap in the specification. Accepting components with visibility="abstract" =============================================== If P uses Q and Q contains an abstract component C(Q), then the options available in P are: (i) accept C with visibility="abstract" (ii) accept C with visibility="absent" (see above) (iii) override C with a concrete implementation (iv) do nothing. We need to decide what happens in case (iv). Previously this would be the same as case (i), but that's not consistent with downgrading components from public to private. The choice, I think, is between (ii) and a static error. Generally we have adopted the stance that adding new components to a library package should not force existing users of that library package to make any changes or cause them to fail. This argues in favour of (ii). Failure to acknowledge the existence of a new abstract function in the library package will cause no failure unless you actually invoke something that uses that function. PROPOSAL ======== (A) Change the second para of 3.5.3.2 to read: For every component CQ in package Q that is not matched by any xsl:override or xsl:accept element in the package manifest of P, there will be a corresponding component CP in package P that has the same symbolic identifier and declaration as CQ. The visibility of CP will be as follows: Visibility of CQ Visibility of CP public private private hidden final private abstract hidden (see Note 1) hidden hidden Note 1: If an abstract component CQ is not explicitly accepted or overridden, the effect is the same as accepting it with visibility="absent" as described below. (B) Under "The value visibility="absent", change list item 1 from: Any component reference to the component within the using package is a static error, as if the component were hidden: in effect, the name of the component is not in scope in the using package. to The component within the using package has visibility hidden. This means that any reference to this component within the using package is a static error: in effect, the name of the component is not in scope in the using package. It also means that the using package cannot expose this component with a different visibility. (C) Add at the end of 3.5.3.1 (for avoidance of doubt): A component in package Q that has visibility "hidden" cannot be exposed by Q with a different visibility; xsl:expose declarations never match such components. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Friday, 29 April 2016 08:41:29 UTC