[Bug 29574] Default visibility of accepted components

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