This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 30390 - [XSLT30] xsl:accept influences the declared visibility, but this is not specified in the section on xsl:expose
Summary: [XSLT30] xsl:accept influences the declared visibility, but this is not speci...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Michael Kay
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-01-14 14:27 UTC by Abel Braaksma
Modified: 2019-02-15 20:34 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2019-01-14 14:27:01 UTC 
Consider:

* Package P having a public function (declared or via xsl:expose) p:myFunction
* Package Q uses P and has <xsl:accept visibility="public" name="p:myFunction" />
* There is no xsl:expose in Q
* Package R uses Q

The question arises whether p:myFunction is visible from R. The text under xsl:accept suggests it is, but under the xsl:expose section (3.5.3.1 Visibility of Components), we write:

"When a component is declared within a particular package, its visibility, which affects how it can be used in other (using) packages, depends on two factors: the value of the visibility declaration on the declaration itself (if present), and the rules given in the xsl:expose declarations of the package manifest."

The following paragraphs go into more detail, but we mention nowhere (I think) what happens when none of this is true (that is: when it is not declared 'on the component declaration' *and* there is no matching xsl:expose), but xsl:accept is present.

I think the section on xsl:accept makes clear that "public" in a valid xsl:accept declaration means "public to the current package and its using packages".

We may benefit from explicitly stating that "on the declaration itself" includes when declared through xsl:accept and the declaration itself is not available anymore (because it is used from a deeper linked package).

An alternative is that we write the section on xsl:accept in terms of changing the "declared visibility", which itself could be defined recursively.

I don't think the spec intended to *require* an extra xsl:expose when you already use xsl:accept on a component from a used package.
Comment 1 Michael Kay 2019-02-15 20:34:16 UTC 
I'm not convinced there is a bug here.

If there is no xsl:expose in Q, then (a) it's hard to see how the xsl:expose rules are relevant, and (b) the component isn't declared within Q, so rules starting "When a component is declared within [Q]..." are clearly immaterial.

Most of the section on xsl:expose discusses how it applies to components declared within the package containing xsl:expose, but we also have a paragraph explaining how it affects components brought in from a used package. Inverting P and Q to match the terminology of this bug report, we say:

For a component accepted into a package Q from another package P, the visibility of the component in Q (which primarily affects how it can be used in a package R that uses Q) depends on the visibility declared in the relevant xsl:accept or xsl:override element in Q (see 3.5.3.2 Accepting Components); this in turn has a default that depends on the visibility of the corresponding component in P. In this case the visibility is unaffected by any xsl:expose declaration in Q.

That last sentence suggests to me that xsl:expose ONLY applies to components actually declared within the containing package. This means that perhaps

[ERR XTSE3020] It is a static error if a token in the names attribute of xsl:expose, other than a wildcard, matches no component in the containing package.

should say

[ERR XTSE3020] It is a static error if a token in the names attribute of xsl:expose, other than a wildcard, matches no component that is declared in the containing package.