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

[Bug 29574] Default visibility of accepted components

From: <bugzilla@jessica.w3.org>
Date: Thu, 12 May 2016 11:41:29 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-29574-523-3X241P1apu@http.www.w3.org/Bugs/Public/>

--- Comment #12 from Michael Kay <mike@saxonica.com> ---
>I'd say the component is absent.

Section as currently written suggests that the component exists and has
a visibility property and the value of the visibility property is "absent".

But doesn't list that as one of the possible values of the visibility
property,  and the table in doesn't have a column for components in the
used package whose visibility is "absent".

I think the simplest model is to treat

<xsl:accept component="C" names="N" visibility="absent"/>

as equivalent to

  <xsl:C name="N" visibility="V">
    <xsl:sequence select="error()"/>

What should "V" be? If it is "absent", then we need to increase the value-set
of the visibility property. If it is "private", then we have a change in
behaviour, because the using package is now allowed to contain static
references to N (though executing those references will give a dynamic error).
If it is "hidden", then I think we reproduce the current behaviour very

So the effect is to create a component in the using package with

This then leaves the question, what if there's an abstract component with
visibility="abstract" and you neither accept it nor override it? I stick with
the view in comment #10 that the best solution is to implicitly accept it as
absent, which means you get a static error if you try to invoke it directly by
name, and you get a dynamic error if you try to invoke it indirectly via a
component in the used package.

You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 12 May 2016 11:41:32 UTC

This archive was generated by hypermail 2.3.1 : Thursday, 12 May 2016 11:41:32 UTC