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 30389 - [XSLT30] rules on components not matched by xsl:accept are unclear: hidden, private, or as declared?
Summary: [XSLT30] rules on components not matched by xsl:accept are unclear: hidden, p...
Status: RESOLVED INVALID
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 major
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-10 17:33 UTC by Abel Braaksma
Modified: 2019-01-14 14:16 UTC (History)
0 users

See Also:

Attachments

Description Abel Braaksma 2019-01-10 17:33:44 UTC 
Whether or not a component matches in xsl:accept is specified in reference to the xsl:expose rules. But those rules end with "otherwise private".

Furthermore, the section explains what allowed combinations are of visibilities in the used package and in the xsl:accept declaration, but not what the resulting visibility would be when they are non-matching.

The rules for "no xsl:accept declarations" are clear: visibility is as exposed in the used package.

The question is, what happens to components not matched if there are one-or-more declarations of xsl:accept?

I see several possibilities:

a) anything not matched is private to the using package (similar to xsl:expose)
b) anything not matched has the same visibility as declared in the used package
c) anything not matched is hidden to the using package

My instinct is (b). However, with that rule, some tests should fail (i.e. package-022).

Another way of reading xsl:accept declarations is "I'm specifying what I want to accept, the rest should be ignored". That would mean (c) above.

I don't know which I would prefer, though from a programmer's perspective, rule (c) seems most logical.
Comment 1 Abel Braaksma 2019-01-10 17:41:01 UTC 
Please retract. I overlooked the section in the introduction of xsl:accept. The part of interest is:

"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. "

and

"In other cases, the visibility of CP depends on the visibility of CQ, as defined by the following table:"

Don't know how I could've missed that. Basically: anything not matched that is public/final is private to the using package. The rest is hidden.
Comment 2 Abel Braaksma 2019-01-14 14:16:35 UTC 
Marking this as INVALID, as it is not a bug, nor is their any ambiguity in the text.