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 4438 - Restriction then extension
Summary: Restriction then extension
Status: CLOSED FIXED
Alias: None
Product: XML Schema
Classification: Unclassified
Component: Structures: XSD Part 1 (show other bugs)
Version: 1.1 only
Hardware: All All
: P2 normal
Target Milestone: ---
Assignee: C. M. Sperberg-McQueen
QA Contact: XML Schema comments list
URL:
Whiteboard:
Keywords: resolved
Depends on:
Blocks:
 
Reported: 2007-03-29 20:25 UTC by Sandy Gao
Modified: 2007-04-09 19:57 UTC (History)
0 users

See Also:


Attachments

Description Sandy Gao 2007-03-29 20:25:02 UTC
Consider

<xs:complexType name="base">
  <xs:sequence>
    <xs:element name="dummy"/>
    <xs:element name="e" type="xs:string" fixed="abc" minOccurs="0"/>
  </xs:sequence>
</xs:complexType>

<xs:complexType name="restriction">
  <xs:complexContent>
    <xs:restriction bsae="base">
      <xs:sequence>
        <xs:element name="dummy"/>
      </xs:sequence>
    <xs:restriction>
  <xs:complexContent>
</xs:complexType>

<xs:complexType name="extension">
  <xs:complexContent>
    <xs:extension bsae="restriction">
      <xs:sequence>
        <xs:element name="e" type="xs:string" fixed="def" minOccurs="0"/>
      </xs:sequence>
    <xs:restriction>
  <xs:complexContent>
</xs:complexType>

Note the different "fixed" values.

Schema 1.0 has a rule like "all derivation can be done by doing all extensions first and restriction later". This makes the above invalid. Schema 1.1 plans to abandon this rule, which would allowed the above derivation. Should it be allowed?
Comment 1 Sandy Gao 2007-04-09 19:54:08 UTC
The working group adopted a proposal that restored the rule in section 3.4.6 (which effectively makes the example invalid).