- From: <bugzilla@jessica.w3.org>
- Date: Thu, 12 May 2016 11:41:29 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29574 --- Comment #12 from Michael Kay <mike@saxonica.com> --- >I'd say the component is absent. Section 3.5.3.2 as currently written suggests that the component exists and has a visibility property and the value of the visibility property is "absent". But 3.5.3.1 doesn't list that as one of the possible values of the visibility property, and the table in 3.5.3.2 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:override> <xsl:C name="N" visibility="V"> <xsl:sequence select="error()"/> </xsl:C> </xsl:override> 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 closely. So the effect is to create a component in the using package with visibility="private". 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