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 that test case package-017 should fail because both the functions function1 and function2 appear in the using package as duplicates. The xsl:accept has no effect (it accepts one of the functions explicitly, but this is exactly the same as the default action, and the other function is accepted implicitly). So both use-package declarations create a pair of functions function1 and function2, as a result of which the using package contains duplicate components.
The same problem affects package-018
For some reason I thought that if you have a list of xsl:accepts that it implies that you only accept the explicitly mentioned components. This test failed with my implementation for the reasons you mentioned. I found the rule: <quote> For every component CQ in package Q that is not matched by any xsl:override or xsl:accept element in the package manifest of P, there will be a corresponding component CP in package P that has the same symbolic identifier and declaration as CQ. The visibility of CP will be the same as the visibility of CQ, except that where the visibility of CQ is private, the visibility of CP will be hidden. </quote> In other words, the default is that if you don't explicitly hide something, everything is accepted. ## Package-017 The reason behind making this test was to find out what happens if you have two xsl:use-package pointing to the same package, whether or not this is possible at all and if so, how it should behave. I think the intended effect can be found by writing the stylesheet as follows: <xsl:use-package name="urn:use-me" package-version="*"> <xsl:accept component="function" names="pkg:function1" visibility="public"/> <xsl:accept component="function" names="*" visibility="hidden" /> </xsl:use-package> <xsl:use-package name="urn:use-me" package-version="0.1"> <xsl:accept component="function" names="pkg:function2" visibility="public"/> <xsl:accept component="function" names="*" visibility="hidden"/> </xsl:use-package> Since the wild-card matches components unless a specific match is available, I think this is legal, and the effect should be that there is no conflict or error. ## Package-018 A similar effect can be reached with package-018, where the attempt was instead to try to create two conflicting xsl:accepts that are not really conflicting (components are not conflicting if they are hidden). Reading the rules again, I am not sure this is allowed: <xsl:use-package name="urn:use-me" package-version="*"> <xsl:accept component="function" names="pkg:function1" visibility="public"/> <xsl:accept component="function" names="pkg:function2" visibility="hidden"/> </xsl:use-package> <xsl:use-package name="urn:use-me" package-version="0.1"> <xsl:accept component="function" names="pkg:function2" visibility="public"/> <xsl:accept component="function" names="pkg:function1" visibility="hidden"/> </xsl:use-package>
(PS: we don't specifically say that it is allowed or disallowed to have two xsl:use-packages pointing to the same package, and if not disallowed, it is allowed, I think and their contents merged)
I think it definitely IS allowed to have two use-package elements identifying the same package provided that it doesn't result in any duplicate declarations. Unless the package exposes nothing, the only way you can avoid duplicate declarations is by selectively accepting the components it exposes. So it's legal to do: <xsl:use-package name="math"> <xsl:accept component="function" name="*" visibility="hidden"/> <xsl:accept component="function" name="sine" visibility="public"/> </xsl:use-package> <xsl:use-package name="math"> <xsl:accept component="function" name="*" visibility="hidden"/> <xsl:accept component="function" name="cosine" visibility="public"/> </xsl:use-package> I can certainly see the utility in saying that if there is at least one xsl:accept element, then everything that is not accepted is hidden. But that's not the way it is currently defined.
As discussed today, we decided to close this bug as it was resolved in the committed changes of 29 Oct 2016.