This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
When xsl:stylesheet was a child of xsl:package it seemed to make sense to have an extra layer of indirection for exposing elements of that child to the outside world. Now that xsl:stylesheet is not a child anymore, I think the need for xsl:expose is gone. The only things xsl:expose can do is hide things: - change public to private or final - change final to private These options are already available in the visibility attribute of the declarations. Having the visibility attribute present, exposes them. If someone wants a declaration hidden, they can change that attribute. I don't see the need (anymore) for having an extra declaration that can change the already statically present visibility. The biggest use-case, I think, was to allow, at package level, to hide parts that were introduced with xsl:use-package. However, that declaration has an xsl:accept (by using hidden or absent), in which the user can decide to accept or not certain items. Again, two ways to achieve, I think, exactly the same. In short: my proposal is to drop xsl:expose. It also gets rid of potential vs exposed visibility, which I think is a good thing.
I don't think the use case for xsl:expose has gone away. The rationale was to allow an existing collection of stylesheet code to be packaged without modifying the code, by writing a package manifest which you now write in the form <xsl:package ...> <xsl:import href="existing-code.xsl"/> <xsl:expose ...> </xsl:package> Using xsl:expose here is more self-contained than trawling through all the code adding visibility attributes; it's more appropriate when you don't own that code, and it's probably a sensible approach if that code has to continue working under XSLT 2.0. The removal of the xsl:stylesheet level changes the way this manifest is written, but it doesn't alter the need for the feature. We could argue that the facility is "a bridge too far" and that the need is not strong enough to justify the complexity, but that's a different argument. I'm very reluctant to spend time on re-examining requirements at this stage, or we will never finish.
> I'm very reluctant to spend time on re-examining requirements at > this stage, or we will never finish. I understand, and I feel the same. However, I think that either the requirement is not met (in which case we should fix it, either by removing it, if the requirement has gone, or by amending it), or I misread the spec. If you do as you say: <xsl:package ...> <xsl:import href="existing-code.xsl"/> <xsl:expose ...> </xsl:package> you end up with the default potential visibility, which is private. It is only permitted, with xsl:expose, to change the potential visibility *down* (less public), not *up*. That means that private can be "changed" to private, but cannot be made public. In other words, using xsl:expose in the above example has no effect, unless we change the default visibility from private to public (I'd probably argue against that, but it would, as a by-product, solve the issues with xsl:param's visibility).
As per the minutes of the XSL WG of telcon 2014-09-25 (https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0053.html, members only), the recorded decision was: <quote> RESOLVED: to close bug 26781 by adopting proposal (a) of ABr's message [1]: if no visibility attribute is present on a declaration, the visibility of a component is determined by the xsl:expose declarations at the package level; expose can lower but not raise the level of visibility (retaining current rules). However, we did not adopt the proposal to rename xsl:expose. [1] https://lists.w3.org/Archives/Member/w3c-xsl-wg/2014Sep/0032.html The result of this is that the priority of visibility specifications is: - xsl:expose with explicit name (if more restrictive than the explicit value on the declaration) - visibility on the declaration itself - xsl:expose with wildcard - private We agreed to mark bug 26781 as RESOLVED. </quote> This means that, given: <xsl:function name="my:fun">...</xsl:function> that the following will make this public: 1) <xsl:expose names="*" visibility="public" /> 2) <xsl:expose names="my:*" visibility="public" /> 3) <xsl:expose names="my:fun" visibility="public" /> This also means that, given: <xsl:function name="my:fun" visibility="private">...</xsl:function> that the same statements (1) and (2) above have no effect, and (3) will raise an error (TBD).
Marking this resoved (see comment #3)