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 14442 - over013 - Overriding a complex type with a simple type
Summary: over013 - Overriding a complex type with a simple type
Status: CLOSED WORKSFORME
Alias: None
Product: XML Schema Test Suite
Classification: Unclassified
Component: Saxon tests (show other bugs)
Version: 2006-11-06
Hardware: PC All
: P2 normal
Target Milestone: XSD 1.1 PR
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema Test Suite mailing list
URL:
Whiteboard:
Keywords: needsAgreement
Depends on:
Blocks:
 
Reported: 2011-10-12 22:32 UTC by Michael Kay
Modified: 2011-11-29 21:48 UTC (History)
1 user (show)

See Also:


Attachments

Description Michael Kay 2011-10-12 22:32:33 UTC
Test over013 has this:

<xs:override schemaLocation="over012a.xsd">
   <xs:simpleType name="structuredDate">
      <xs:restriction base="xs:date"/>
   </xs:simpleType>
 </xs:override>

overriding this:

<xs:schema ...>
  <xs:element name="doc">
    ...
  </xs:element>
  <xs:complexType name="structuredDate">
     <xs:sequence>
        ...
     </xs:sequence>
  </xs:complexType>
</xs:schema>

and has an expected result of invalid, on the grounds that a simpleType cannot override a complexType. In fact, following the rules in the spec more closely, there appears to be no such error condition. Instead the simpleType simply fails to override anything, and is therefore ignored.

Can the WG confirm that this is the intent of the specification?
Comment 1 David Ezell 2011-11-04 15:51:50 UTC
After study, WG notes that the behavior seems OK. Warnings might be issued by an agressive implementation, but are not required. The behavior of doing nothing is expected. In any case, the behavior of the stylesheet is within the boundaries of what is defined.

Further, the situation should not result in indication of an error in the schema.

MSM: if we made any change here, I fear we'd have to go back to last call.
MSM:  I do think MK is right to ask: was that really what we intended?  But I think that it's too late to make design changes at that level.  We either go to Rec with essentially what we've got, or we go out of business without a Rec.

Resolved: mark as WORKSFORME but give Michael Kay a chance to redirect.
Comment 2 Michael Kay 2011-11-04 16:25:32 UTC
That's the decision I was expecting, and it seems prudent given the stage we're at.
Comment 3 Michael Kay 2011-11-29 21:48:29 UTC
I have changed the expected result of the test to "valid"