This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Should this test raise XTSE3080 (and -043c, -045c, -047c likewise)? Section 3.5.3.3 says (just below the definition of error 3060): A package is executable if and only if it contains no component whose visibility is abstract. A package that is not executable is not a stylesheet, and therefore cannot be nominated as the stylesheet to be used when initiating a transformation. This statement has no associated error code. The definition of XTSE3080 is in 3.5.3.5, and reads: [ERR XTSE3080] It is a static error if a top-level package (as distinct from a library package) contains symbolic references referring to components whose visibility is abstract. Note that XTSE3080 suggests it's only an error if there is a reference to the abstract component, whereas the statement in 3.5.3.3 suggests it's an error whether or not the component is referenced. Leaving this as a test suite bug for the moment, but we may need some clarification in the spec.
I remember looking this up recently and thought to recollect that we decided (in Prague?) that abstract components can exists *as long as they are not invoked*. Then I found the section on xsl:accept and "absent", which seems to be a feature to explicitly say that you do not expect to give an implementation for such components, if they are referenced, it is then a dynamic error (this is a nuisance to do if you have abstracts of all kinds, which requires at least five xsl:accept just to be able to run whenever you reference such package) I'm not sure for the rationale behind this. It seems to make more sense to allow abstract components to exist, just with a default implementation of xs:error / fn:error. Unless we want to give library builders the tools to write "interface-style" code, where it is required to implement the whole interface (abstract components) (where "absent" is a kind of implementation), regardless of whether the code is referenced/used etc. With large packages where many components are defined as abstract, this can become quite a pain.
I'm converting this to a spec bug as I think it needs technical discussion.
We decided it should be an error to have abstract components whether or not they are referenced. The wider topic of the usability of xsl:accept will be raised as a separate issue.
The necessary clarification has been added to the spec.
(In reply to Michael Kay from comment #3) > The wider topic of the usability of xsl:accept will be raised as a separate > issue. For reference, that is Bug 29478.