30390 2019-01-14 14:27:01 +0000 [XSLT30] xsl:accept influences the declared visibility, but this is not specified in the section on xsl:expose 2019-02-15 20:34:16 +0000 1 1 1 Unclassified XPath / XQuery / XSLT XSLT 3.0 Recommendation PC Windows NT NEW P2 normal --- 1 abel.online mike public-qt-comments oldest_to_newest 129474 0 abel.online 2019-01-14 14:27:01 +0000 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. 129507 1 mike 2019-02-15 20:34:16 +0000 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.