This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
I believe this test is incorrect. The top-level package (m-016) does: <xsl:use-package name="m-001"> <xsl:accept component="mode" names="m3" visibility="final"/> <xsl:override> <xsl:template match="..." mode="m3">...</xsl:template> </xsl:override> </xsl:use-package> and expects an error on the grounds that a template rules cannot be added to a "final" mode. However, I think that override is only disallowed if the mode is final in the used-package m-001. Accepting it as final in m-016 does not prevent rules being added within m-016, it only prevents them being added in a package that uses m-016. I have to say that this is not clearly explained in the spec. However, it seems the most reasonable interpretation. The difference between declaring something "public", "private", and "final" is not what you can do yourself, it's what your clients (using packages) can do. (However, accepting as "hidden" affects what you can do yourself...)
I agree that this test is incorrect (but I can't test it, I'm currently revisiting the xsl:override implementation), however, for different reasons. I think it should raise: [ERR XTSE3051] It is a static error if a token in the names attribute of xsl:accept, other than a wildcard, matches the symbolic name of a component declared within an xsl:override child of the same xsl:use-package element. This error also prevents programmers from getting into the quagmire of both accepting something with a certain visibility and overriding it with a different visibility. But, careful reading of this error (and remembering a previous discussion with you about it in bug#30399), we say here "declared within", while modes are not declared inside xsl:override. That said, I would argue that the same error *should* also apply for modes, just as it applies to any other component currently. This would remove the problem caused by mixing xsl:accept and xsl:override on the same component, which was never supposed to happen: you either accept, *or* override a component, but not both.
Sorry I failed to spot the overlap with bug #30399. I don't think XTSE3051 is intended to apply here. If we're dealing with a named component taken from a used package, then the 3051 rule makes sense: if you want to override the component and make the new version final, then you can do that all within xsl:override and you don't need xsl:accept. But with xsl:mode you don't get a chance to re-declare the mode as final within xsl:override, so the only way to do it is in xsl:accept, and it seems unreasonable to disallow adding rules to a mode and also saying that it's now final.
> But with xsl:mode you don't get a chance to re-declare the mode as final > within xsl:override, so the only way to do it is in xsl:accept, and it seems > unreasonable to disallow adding rules to a mode and also saying that it's now > final. I can see how this is beneficial (if we were to treat XTSE3051 as I explained in comment#1, or XTSE3060 as in this test, it would require a user to write an indirect package for the xsl:override and another one for the visibility="final"). But we are not explicit about this in the spec. Would you agree that we should treat this as a spec bug, perhaps as an additional Note in the section around XTSE3051 or XTSE3060?