Bug 20643 - [XP3.0] Formal and informal definitions of derives-from() do not match
[XP3.0] Formal and informal definitions of derives-from() do not match
Status: CLOSED FIXED
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 3.0
Last Call drafts
PC All
: P2 normal
: ---
Assigned To: Jonathan Robie
Mailing list for public feedback on specs from XSL and XML Query WGs
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-01-11 09:51 UTC by Michael Kay
Modified: 2013-06-19 10:07 UTC (History)
0 users

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Michael Kay 2013-01-11 09:51:45 UTC
This is transferred from the comment made by email here:

https://lists.w3.org/Archives/Member/w3c-xsl-query/2013Jan/0003.html

We say in 2.5.5

derives-from( AT, ET ) returns true if AT is derived from ET by 
restriction or extension, or if ET is a union type of which AT is a 
member type.

If this were the case, then when a function expects union(xs:string, 
xs:decimal), it would be a type error to supply an xs:integer. 
Furthermore, "union type" should be "pure union type".

This sentence is immediately followed by a paraphrase that says 
"formally, ...", and the paraphrase gives the a more complete definition. But 
there is no indication that the sentence quoted is to be regarded as 
incomplete or informal.

A better definition might be:

derives-from( AT, ET ) returns true if any of the following conditions 
applies:

* AT is ET
* ET is the base type of AT
* ET is a pure union type of which AT is a member type
* There is a type MT such that derives-from(AT, MT) and derives-from(MT, ET)

The problem is exemplified by test instanceof138. The expected result 
for this test assumes that restrictedDate is substitutable for a union 
type that includes the base type of restrictedDate as one of its members.
Comment 1 Jonathan Robie 2013-01-22 17:34:36 UTC
The Working Group accepted the proposed change.