W3C home > Mailing lists > Public > public-qt-comments@w3.org > November 2014

[Bug 27175] subtype-itemtype

From: <bugzilla@jessica.w3.org>
Date: Thu, 20 Nov 2014 11:51:05 +0000
To: public-qt-comments@w3.org
Message-ID: <bug-27175-523-f0sn77hHAZ@http.www.w3.org/Bugs/Public/>
https://www.w3.org/Bugs/Public/show_bug.cgi?id=27175

Michael Kay <mike@saxonica.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mike@saxonica.com

--- Comment #3 from Michael Kay <mike@saxonica.com> ---
I think Benito is correct in the sense that rule 14 is incomplete. However, I
think the missing case is covered by rule 16:

16. Bi is element(Bn, Bt?), the expanded QName of An equals the expanded QName
of Bn, Ai is either element(An, At) or element(An, At?), and derives-from(At,
Bt) returns true.

If we set Bt = xs:anyType, then for any type T we know that derives-from(At,
Bt) is true, so rule 16 becomes

16a. Bi is element(Bn, xs:anyType?), the expanded QName of An equals the
expanded QName of Bn, Ai is either element(An, T) or element(An, T?) for any
type T

which is identical to the amended rule 14 proposed by Benito. Except that rule
14 also covers the case where there is no type name.

I think therefore that rule 14 could be replaced with the rule

14. Bi is element(N), and Ai is either element(N) or element (N, T) or
element(N, T?), where N is any QName and T is any schema type.

leaving rule 16 to take care of the case element(Bn, xs:anyType?).

Note, I've simplifed the rule by assuming that we can take it as read that the
QName N can be written in different ways and still be the same QName - but
perhaps we shouldn't do that here unless we do it throughout all the rules.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.
Received on Thursday, 20 November 2014 11:51:07 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:45:59 UTC