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 3716 - Editorial: clarify that none is subtype of all types
Summary: Editorial: clarify that none is subtype of all types
Status: CLOSED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: Formal Semantics 1.0 (show other bugs)
Version: Candidate Recommendation
Hardware: Other Linux
: P2 minor
Target Milestone: ---
Assignee: Jerome Simeon
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords: editorial
Depends on:
Blocks:
 
Reported: 2006-09-13 11:28 UTC by Frans Englich
Modified: 2006-09-27 09:48 UTC (History)
0 users

See Also:


Attachments

Description Frans Englich 2006-09-13 11:28:17 UTC
For an expression such as "zero-or-one(error())", where the fn:error() is exclusively an operand to an expression instead of for example zero-or-one((1, error())), seems to meet the reactions that it should work, but that the formal semantics doesn't allow it to. See discussion in #3675:

http://www.w3.org/Bugs/Public/show_bug.cgi?id=3675


Frans
Comment 1 Frans Englich 2006-09-19 10:53:50 UTC
Jerome clarified this in #3675:

"The type 'none' is a subtype of every type. See subtyping Section 8.3.2-- t1 is a subtype of t2 iff every value v, v matches t1 implies v matches t2. Since no value matches 'none', none <: t for every t."

Tim suggests the editorial change that:

"Might it be worth spelling that out for clarity in the notes of
section 8.3.2?"
Comment 2 Jerome Simeon 2006-09-26 14:06:16 UTC
Frans,
Thanks for your comment.
The XSLT and XML Query working group has decided to
close that comment, without changes to the normative
part of the text, but adding a clarification in
Section 8.3.2 on subtyping to indicate that 'none'
is a subtype of every type.
This comment is reclassified as editorial.
Best,
- Jerome
On Behalf of the XSLT and XML Query WGs
Comment 3 Frans Englich 2006-09-27 09:48:13 UTC
Yes, an editorial clarification was what was needed here.