- From: <bugzilla@jessica.w3.org>
- Date: Wed, 12 Feb 2014 11:45:21 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=24545 C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cmsmcq@blackmesatech.com --- Comment #2 from C. M. Sperberg-McQueen <cmsmcq@blackmesatech.com> --- The WG discussed this during the ftf meeting in Prague and noted that the initial comment appears to have been resolved; the problems noted in comment 1 remain to be fixed. We spent some time worrying at the problem that the default initial mode is the unnamed mode (for backward compatibility), and the unnamed mode is necessarily private in packages. Among the ideas floated: a) allow invocation with initial-mode = #default-initial-mode (invoking it by role and not by name); this doesn't seem to answer questions about the desired relation between the visibility and initial attributes (are both needed?). a') allow invocation with initial-mode = "". b) make the unnamed mode in the top-level package be visible to the calling application; this means the unnamed mode is treated differently from other private components. c) make the private components in the top-level package visible to the calling application; this means the calling application has access to names not accessible to other packages using this one as a library package. d) make the unnamed mode visible in stylesheet modules which lack xsl:package, but invisible in packages; this means that wrapping a stylesheet in xsl:package can mean it no longer works in contexts where it used to work. e) remove the visibility attribute from the unnamed mode. f) remove the 'initial' attribute; all public modes are eligible to be the initial mode; special-case the unnamed mode, which is always eligible to be the initial mode despite being private. We took a straw poll; the strong preponderance of sentiment was in favor of f). We'll need to see this again because there will be interactions with our resolutions of other bugs. -- You are receiving this mail because: You are the QA Contact for the bug.
Received on Wednesday, 12 February 2014 11:45:28 UTC