Community
Participate
Working Groups
Created attachment 246061 [details] Example where the xs:list using FaceType is not msapped to int or Integer. ecore:type="ecore:Exxxxx" can be used in attributes and types to force non-default mapping. This is particularly useful in not-so-well-designed schemas using too wide types. This works well for simple attributes, but does not work for lists: <xs:simpleType name="FaceType" ecore:type="ecore:EInt"> <xs:list itemType="xs:integer" ecore:type="ecore:EInt"/> </xs:simpleType> A typical example is xs:integer which maps by default to BigDecimal. In many cases, it is preferable to map to int or long. In the example above, "FaceType" is still mapped to list of java.lang.BigInteger. BTW, it would be *much* nicer to be able to put such definitions in an external file, like it is possible with JAXB.
The same bug is present in restrictions: <xs:simpleType name="zoneNumberType" ecore:type="ecore:EInt"> <xs:restriction base="xs:positiveInteger" ecore:type="ecore:EInt"> <xs:minInclusive value="1"/> <xs:maxInclusive value="99"/> </xs:restriction> </xs:simpleType> The "zoneNumberType" gets implemented as "BigInteger" instead of "int".
The enhancement is committed to master: https://git.eclipse.org/c/xsd/org.eclipse.xsd.git/commit/?id=afe6a50f0bb4de1b7192a57dfcb229ebda8213a5 Both the restriction element and list element of a simple type now support ecore:type to override the value of the base attribute or the itemType attribute. In your sample, the use of ecore:type on the simpleType element itself makes no sense. Here you are always defining a new data type and you can only control things like the name and the instance class/type of the corresponding EDataType. On a restriction element or list element you are referencing some other type, and here it makes sense to be able to redirect/override it. Note that in your sample, the use of ecore:type on the restriction below is not sensible and will lead to an Ecore model with validation constraint problem (because the extended metadata annotations are validated as of EMF 2.15): <xs:element name="F"> <xs:simpleType ecore:type="ecore:EInt"> <xs:restriction base="FaceType" ecore:type="ecore:EInt"> <xs:minLength value="3"/> <xs:maxLength value="4"/> </xs:restriction> </xs:simpleType> </xs:element> In particular here you redirect the base to a type that is not a list type so the length facets do no sensibly apply. Of course with the FaceType being generated as a list of Integer, you'd not want/need this ecore:type annotation here and would want to leave the restriction to constrain the size of the list.
The changes are available in the 2.16 release: http://download.eclipse.org/modeling/emf/emf/builds/release/2.16
