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 7749 - [XPath 2.0] derives-from() and union types
Summary: [XPath 2.0] derives-from() and union types
Status: RESOLVED FIXED
Alias: None
Product: XPath / XQuery / XSLT
Classification: Unclassified
Component: XPath 2.0 (show other bugs)
Version: Recommendation
Hardware: PC Windows NT
: P2 normal
Target Milestone: ---
Assignee: Jonathan Robie
QA Contact: Mailing list for public feedback on specs from XSL and XML Query WGs
URL:
Whiteboard:
Keywords: needsDrafting
Depends on:
Blocks:
 
Reported: 2009-09-29 09:01 UTC by Michael Kay
Modified: 2010-02-09 16:27 UTC (History)
0 users

See Also:


Attachments

Description Michael Kay 2009-09-29 09:01:19 UTC
We allow an ItemType in a SequenceType to take the form element(N, U) or attribute(N, U) where U is a union type defined in the schema. But under the rules for the derives-from() function, no element or attribute will ever match such a sequence type, because the type annotation of the element or attribute will never be a union type (it will always be one of its member types), and derives-from() requires derivation by restriction or extension: a member type of a union is not derived by restriction or extension from the union type.

This also affects schema-element(N) or schema-attribute(N) if the element or attribute declaration for N has a declared type that is a union type.

In 2.5.4, the first rule "1. AT is a schema type found in the in-scope schema definitions, and is the same as ET or is derived by restriction or extension from ET" should be changed to "1. AT is validly derived from ET given the empty set [of blocked derivation methods] as defined in [XSD 1.0] by Type Derivation OK (Complex) (§3.4.6) or Type Derivation OK (Simple) (§3.14.6), as appropriate." This also affects the rule numbered 1 in the second list.

Note that the schema rules for Type Derivation OK allow transitive derivation, thus obviating the need for our rule 3.

Complicating matters, there is a bug in XSD 1.0 whereby the rules for simple type substitutability do not correctly take account of a union type that is derived by restriction from another union. This bug is fixed in XSD 1.1.
Comment 1 Michael Kay 2009-11-17 13:59:47 UTC
A proposal to address this problem (along with bug 7860) is at

http://lists.w3.org/Archives/Member/w3c-xsl-query/2009Oct/0133.html

(member-only)
Comment 2 Michael Kay 2010-01-13 14:00:44 UTC
Specific textual changes to implement the solution proposed in 

http://lists.w3.org/Archives/Member/w3c-xsl-query/2009Oct/0133.html (member-only) are as follows, based on the Dec 2009 XQuery 1.1 Working Draft:

In 2.5.4, SequenceType matching, replace the entirety of the second bullet of the definition of derives-from (which starts "derives-from( AT, ET ) returns true [if] AT and ET are both present in S, and if one or more of the following three conditions is true:...", other than the Note, by:

<new>
derives-from( AT, ET ) returns true if AT and ET are both present in S and AT is validly derived from ET given the empty set, as defined in [XML Schema Pt 1] constraints Type Derivation OK (Complex) (§3.4.6) (if AT is a complex type), or Type Derivation OK (Simple) (§3.14.6) (if AT is a simple type).

Note: effectively this means that AT must either be derived from ET by restriction or extension, or ET must be a union type of which AT is a member type. The phrase "given the empty set" is used because the rules in the XML Schema specification are parameterized: the parameter is a list of the kinds of derivation that are not allowed, and in this case the list is always empty.

Note: The current (second) edition of XML Schema 1.0 contains an error in respect of the substitutability of a union type by one of its members: it fails to recognize that this is unsafe if the union is derived by restriction from another union. This problem is fixed in the current working draft of XML Schema 1.1, and implementers are advised to adopt the solution given there. It is likely that this specification will be updated to refer normatively to XML Schema 1.1 when that specification reaches Recommendation status. 
</new>

I leave the question open as to whether the bug should be fixed in XQuery 1.0. It's a serious bug that affects type soundness, especially for static typing implementations, so in principle I think it should.

Comment 3 Jonathan Robie 2010-01-19 16:39:14 UTC
I would like to turn this around to make it a little more user-friendly:


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

Formally, it returns true if AT and ET are both present in S and
AT is validly derived from ET given the empty set, as defined in
[XML Schema Pt 1] constraints Type Derivation
OK (Complex) (§3.4.6) (if AT is a complex type), or Type
Derivation OK (Simple) (§3.14.6) (if AT is a simple type). The
phrase "given the empty set" is used because the rules in the XML
Schema specification are parameterized: the parameter is a list
of the kinds of derivation that are not allowed, and in this case
the list is always empty.

Note: The current (second) edition of XML Schema 1.0 contains an error in
respect of the substitutability of a union type by one of its members: it fails
to recognize that this is unsafe if the union is derived by restriction from
another union. This problem is fixed in the current working draft of XML Schema
1.1, and implementers are advised to adopt the solution given there. It is
likely that this specification will be updated to refer normatively to XML
Schema 1.1 when that specification reaches Recommendation status. 
</new>