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 30391 - [XSLT30] Conflicting statements on abstract components; they make stylesheet non-executable (3.5.3.3) or raise dynamic error (3.5.3.2)
Summary: [XSLT30] Conflicting statements on abstract components; they make stylesheet ...
Status: NEW
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XSLT 3.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 minor
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-15 22:17 UTC by Abel Braaksma
Modified: 2019-01-16 22:14 UTC (History)
0 users

See Also:


Attachments

Description Abel Braaksma 2019-01-15 22:17:27 UTC
I happened upon this line today in section 3.5.3.3 Overriding Components:

"A package is executable if and only if it contains no component whose visibility is abstract. A package that is not executable is not a stylesheet, and therefore cannot be nominated as the stylesheet to be used when initiating a transformation."

But in section 3.5.3.2 Accepting Components we iterate over three options, including that remaining abstract components will raise an error: 

"[ERR XTDE3052] It is a dynamic error if an invocation of an abstract component is evaluated."

I think we have two options:

   a) We accept the line in 3.5.3.3 and abstract components cannot linger or the 
      stylesheet as a whole cannot be executed.

   b) We accept the sections in 3.5.3.2 and the stylesheet can always be 
      executed, but if you hit on an abstract component, XTDE3052 is raised.


My recollection from discussing this says it is option (b), in which case the simple solution is to delete the paragraph in 3.5.3.3.
Comment 1 Abel Braaksma 2019-01-16 14:25:12 UTC
This was a case of not seeing the wood for the trees. We don't use the term "executable" anywhere else and as a result I didn't see a corresponding section under 3.5.3.5 Binding References to Components.

That section has the following error:

"[ERR XTSE3080] It is a static error if a top-level package (as distinct from a library package) contains components whose visibility is abstract."

This error description also clarifies the perceived ambiguity from the section on accepting components. To sum it up:

* Library package can reference abstract components
* Invoking an abstract component can happen even after the lib package is used, but with xsl:accept declaring it "hidden". This invocation would happen in the lib package itself.
* The principal package (top-level package) cannot have any unresolved abstract components, i.e. by not overriding / not accepting (with "hidden").
* The principal package can only reference abstract components if a concrete implementation is available through xsl:override

While I think the text could be clarified somewhat, for instance by referencing the relevant error, or repeating the error in the xsl:accept section, I don't think anymore that there's a bug.
Comment 2 Abel Braaksma 2019-01-16 22:14:13 UTC
Btw, I found a previous discussion related to this, bug #30142, in particular the last line:

"I think that XTSE3080 can now arise only if the top-level package explicitly declares an abstract component."