Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 359949

Summary: Multiple xsd:restrictions not correctly propagated
Product: [Modeling] EMF Reporter: Hauke Fuhrmann <haf>
Component: CoreAssignee: Ed Merks <Ed.Merks>
Status: CLOSED FIXED QA Contact:
Severity: normal    
Priority: P3    
Version: unspecified   
Target Milestone: ---   
Hardware: PC   
OS: Windows 7   
Whiteboard:

Description Hauke Fuhrmann CLA 2011-10-05 04:35:53 EDT
Build Identifier: 20110916-0149

Using multiple successive restrictions in an XSD, from the second restriction they are not anymore propagated in the Genmodel.

Example:

<xs:complexType name="Foo">
<xs:sequence>
  <xs:element name="E1" type="foo:T1"/>
  <xs:element name="E2" type="foo:T2"/>
  <xs:element name="E3" type="foo:MyEnum"/>
</xs:sequence>
</xs:complexType>

<xs:simpleType name="T1">
  <xs:restriction base="foo:T2"/>
</xs:simpleType>
<xs:simpleType name="T2">
  <xs:restriction base="foo:MyEnum"/>
</xs:simpleType>
<xs:simpleType name="MyEnum">
  <xs:restriction base="xsd:String">
    <xs:enumeration value="e1"/>
    <xs:enumeration value="e2"/>
  </xs:restriction>
</xs:simpleType>

The result is that E3 and E2 correctly have the Type MyEnum, but E1 only has the Type Enumerator.

Comment by Ed Merks:

EEnums are a bit special; they're the only EDataType that actually generate a corresponding class.  The full name of that class is only known to the GenModel (by virtue of the GenPackage's Base Package) so likely there is some issue propogating the placeholder type name from one EDataType to another (which isn't a problem when propagating from an EEnum to an EDataType).  It's just a theory...

Reproducible: Always
Comment 1 Ed Merks CLA 2011-10-27 06:51:10 EDT
The fix is committed to CVS for 2.8.
Comment 2 Ed Merks CLA 2011-11-22 05:26:28 EST
The changes are available in builds.