- From: <bugzilla@jessica.w3.org>
- Date: Tue, 03 Nov 2015 00:33:07 +0000
- To: public-qt-comments@w3.org
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29256
Abel Braaksma <abel.braaksma@xs4all.nl> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |abel.braaksma@xs4all.nl
--- Comment #1 from Abel Braaksma <abel.braaksma@xs4all.nl> ---
I remember looking this up recently and thought to recollect that we decided
(in Prague?) that abstract components can exists *as long as they are not
invoked*.
Then I found the section on xsl:accept and "absent", which seems to be a
feature to explicitly say that you do not expect to give an implementation for
such components, if they are referenced, it is then a dynamic error
(this is a nuisance to do if you have abstracts of all kinds, which requires at
least five xsl:accept just to be able to run whenever you reference such
package)
I'm not sure for the rationale behind this. It seems to make more sense to
allow abstract components to exist, just with a default implementation of
xs:error / fn:error. Unless we want to give library builders the tools to write
"interface-style" code, where it is required to implement the whole interface
(abstract components) (where "absent" is a kind of implementation), regardless
of whether the code is referenced/used etc.
With large packages where many components are defined as abstract, this can
become quite a pain.
--
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Tuesday, 3 November 2015 00:33:12 UTC