Eclipse Community Forums: Modeling (top-level project) » XSD to Ecore

Help

Home

Home » Modeling » Modeling (top-level project) » XSD to Ecore - Enumeration Problem

Show: Today's Messages :: Show Polls :: Message Navigator

XSD to Ecore - Enumeration Problem [message #380806]

Fri, 22 June 2007 15:05

Andy Hoffman

Messages: 8
Registered: July 2009

Junior Member

Folks,

I'm working on upgrading our current EMF/SDO environment from EMF 2.1 to
2.2 (finally moving upwards to Eclipse 3.2 in a large devel group). We do
a large amount of model generation from XML schemas, but for some reason,
the code that is generated from EMF 2.2 is *NOT* compatible with the model
code generated from EMF 2.1. In particular, when I use XSD as source for
ecore/genmodel creation, some enumeration values in the XSD are coming out
DIFFERENTLY within the ecore literals under EMF 2.2 vs. EMF 2.1. For
example, I have an AccountType enumeration in XSD that looks like this:

<xs:simpleType name="AccountType">
<xs:restriction base="xs:string">
<xs:enumeration value="HRA"/>
<xs:enumeration value="HRA_ROLLOVER"/>
...
<xs:enumeration value="HRA_RETIREMENT"/>
</xs:restriction>
</xs:simpleType>

And when I run it through EMF 2.1 XSD ecore/genmodel generation, I get
mappings to literals that match the same names (from genmodel)...

<genEnums ecoreEnum="saeob.ecore#//AccountType">
<genEnumLiterals ecoreEnumLiteral="saeob.ecore#//AccountType/HRA"/>
<genEnumLiterals
ecoreEnumLiteral="saeob.ecore#//AccountType/HRA_ROLLOVER"/ >
...
<genEnumLiterals
ecoreEnumLiteral="saeob.ecore#//AccountType/HRA_RETIREMENT"/
</genEnums>

But when I run it through EMF 2.2 XSD ecore/genmodel generation, I get a
renaming of the literals, where the underscore characters are removed...

<genEnums ecoreEnum="saeob.ecore#//AccountType">
<genEnumLiterals ecoreEnumLiteral="saeob.ecore#//AccountType/HRA"/>
<genEnumLiterals
ecoreEnumLiteral="saeob.ecore#//AccountType/HRAROLLOVER"/>
...
<genEnumLiterals
ecoreEnumLiteral="saeob.ecore#//AccountType/HRARETIREMENT"/ >
</genEnums>

And thus, when the model code is generated, what WAS a public literal
object reference AccountType.HRA_ROLLOVER_LITERAL through EMF 2.1
(referenced within many parts of non-EMF/SDO codebase), is now
AccountType.HRAROLLOVER_LITERAL through EMF 2.2 (and obviously causes
compile issues with the rest of my codebase.

Also, not sure if this is related, but the *Package classes no longer seem
to be generated (scratching my head on that one) - I get the *Factory
classes by no *Package (???)

Is this simply a configuration issue on my end? Am I missing some
property/preference setting within EMF?

Report message to a moderator

Re: XSD to Ecore - Enumeration Problem [message #380809 is a reply to message #380806]

Fri, 22 June 2007 17:32

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Andy,

Please use the EMF newsgroup, which I've added to the "to" list of the
reply, for future postings that are specifically about EMF.

Andy Hoffman wrote:
> Folks,
>
> I'm working on upgrading our current EMF/SDO environment from EMF 2.1
> to 2.2 (finally moving upwards to Eclipse 3.2 in a large devel group).
To bad you aren't moving to 2.3...
> We do a large amount of model generation from XML schemas, but for
> some reason, the code that is generated from EMF 2.2 is *NOT*
> compatible with the model code generated from EMF 2.1. In particular,
> when I use XSD as source for ecore/genmodel creation, some enumeration
> values in the XSD are coming out DIFFERENTLY within the ecore literals
> under EMF 2.2 vs. EMF 2.1. For example, I have an AccountType
> enumeration in XSD that looks like this:
>
> <xs:simpleType name="AccountType">
> <xs:restriction base="xs:string">
> <xs:enumeration value="HRA"/>
> <xs:enumeration value="HRA_ROLLOVER"/>
> ...
> <xs:enumeration value="HRA_RETIREMENT"/>
> </xs:restriction>
> </xs:simpleType>
>
> And when I run it through EMF 2.1 XSD ecore/genmodel generation, I get
> mappings to literals that match the same names (from genmodel)...
>
> <genEnums ecoreEnum="saeob.ecore#//AccountType">
> <genEnumLiterals ecoreEnumLiteral="saeob.ecore#//AccountType/HRA"/>
> <genEnumLiterals
> ecoreEnumLiteral="saeob.ecore#//AccountType/HRA_ROLLOVER"/ >
> ...
> <genEnumLiterals
> ecoreEnumLiteral="saeob.ecore#//AccountType/HRA_RETIREMENT"/
> </genEnums>
>
> But when I run it through EMF 2.2 XSD ecore/genmodel generation, I get
> a renaming of the literals, where the underscore characters are
> removed...
>
> <genEnums ecoreEnum="saeob.ecore#//AccountType">
> <genEnumLiterals ecoreEnumLiteral="saeob.ecore#//AccountType/HRA"/>
> <genEnumLiterals
> ecoreEnumLiteral="saeob.ecore#//AccountType/HRAROLLOVER"/>
> ...
> <genEnumLiterals
> ecoreEnumLiteral="saeob.ecore#//AccountType/HRARETIREMENT"/ >
> </genEnums>
>
> And thus, when the model code is generated, what WAS a public literal
> object reference AccountType.HRA_ROLLOVER_LITERAL through EMF 2.1
> (referenced within many parts of non-EMF/SDO codebase), is now
> AccountType.HRAROLLOVER_LITERAL through EMF 2.2 (and obviously causes
> compile issues with the rest of my codebase.
In 2.2 we generalized the support for converting any enumeration
restriction to an EEnum by adding a EEnumLiteral.literal as a way to
record the original value. In 2.1, we converted to EEnums only for the
case that all the restrictions were valid Java identifiers and then
preserved exactly that name. In 2.2 we record the original value as the
literal and process the value in the same way as we process the names of
other XML Schema named components to ensure that we end up with a well
formed Java identifier. This "name mangling" algorithm strips out "_"
and rejects characters that are not valid Java identifier characters.
So that explains the difference, but clearly breaking your API is highly
undesireable. The best I can suggest at this point is to use an
ecore:name annotation in the schema to explicitly set the name to be
like you had before. Sorry we didn't anticipate that stripping "_" from
a string that consists of all capital letters does not produce a nice
result. :-( It's just not a common pattern for other named elements in
a schema...
>
> Also, not sure if this is related, but the *Package classes no longer
> seem to be generated (scratching my head on that one) - I get the
> *Factory classes by no *Package (???)
For this you can change the GenModel's "Suppress EMF Metadata" to be
false instead of true.
>
> Is this simply a configuration issue on my end? Am I missing some
> property/preference setting within EMF?
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: XSD to Ecore - Enumeration Problem [message #380812 is a reply to message #380809]

Mon, 25 June 2007 18:29

Andy Hoffman

Messages: 8
Registered: July 2009

Junior Member

Ed Merks wrote:

> Andy,

> Please use the EMF newsgroup, which I've added to the "to" list of the
> reply, for future postings that are specifically about EMF.

No problem, caught that on another post RIGHT AFTER I sent this one (blush)

> Andy Hoffman wrote:
>> Folks,
>>
>> I'm working on upgrading our current EMF/SDO environment from EMF 2.1
>> to 2.2 (finally moving upwards to Eclipse 3.2 in a large devel group).
> To bad you aren't moving to 2.3...

We will be eventually... depends on the timing. I'll be updating my own
install to Europa probably first thing next week, but it takes time for
everyone else (ha-ha). Would 2.3 within Europa handle these differences
better?

> In 2.2 we generalized the support for converting any enumeration
> restriction to an EEnum by adding a EEnumLiteral.literal as a way to
> record the original value. In 2.1, we converted to EEnums only for the
> case that all the restrictions were valid Java identifiers and then
> preserved exactly that name. <snip> The best I can suggest at this point is
to use an
> ecore:name annotation in the schema to explicitly set the name to be
> like you had before.

I found the XSD to Ecore PDF online and tried the ecore:name attribute
which overcomes the issue within EMF 2.2 (now generates matching
enumeration names :))... however (and isn't there always a however), I now
have another enumeration value related issue within 2.1 and difference
within 2.2 that's a bit trickier.

I also have an enumeration for listing valid countries, such as "UNITED
STATES", "CANADA", etc., which I'm only NOW discovering was causing an
oddity within EMF 2.1...

<xs:simpleType name="CountryType">
<xs:restriction base="xs:string">
<xs:enumeration value="$$$NULL$$$"/>
<xs:enumeration value="UNITED STATES"/>
<xs:enumeration value="CANADA"/>
<xs:enumeration value="MEXICO"/>
</xs:restriction>
</xs:simpleType>

... where the EEnum is not being generated (as you stated in your reply).
I understand why it isn't, as the "UNITED STATES" value has a SPACE within
it, and this isn't a valid Java literal name, and the generated code just
leaves it as a string value (with no EEnum).

But when I generate the code out of EMF 2.2, it now does the automatic
renaming, and NO LONGER has a problem with the value, and generates the
EEnum, which then invalidates the rest of my existing source code as well,
which is using only the "String" values.

I know there were trade-offs when moving from 2.1 to 2.2 in making
improvements. Just wanted to know if there's a recommended solution for
this situation (particularly regarding "space" characters in the literal
value within 2.1 - or perhaps how to force 2.2 to just use a string value
and ignore the enumeration in the meantime. Any futher thoughts would be
appreciated.

>>
>> Also, not sure if this is related, but the *Package classes no longer
>> seem to be generated (scratching my head on that one) - I get the
>> *Factory classes by no *Package (???)
> For this you can change the GenModel's "Suppress EMF Metadata" to be
> false instead of true.

Yes, I found that one, and the Package classes are now being generated...
however, there's one additional tweak I needed to make to the JET emitter
template, since ONE difference that happened between 2.1 and 2.2 was that
the SDO-defaults now use "INSTANCE" instead of "eINSTANCE" within the
Factory classes to return the default factory instance, and that broke my
existing code as well - but changing the 2.2 template to continue using
"eINSTANCE" did the trick :)

Report message to a moderator

Re: XSD to Ecore - Enumeration Problem [message #380813 is a reply to message #380812]

Mon, 25 June 2007 20:12

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Andy,

You can use ecore:enum="false" to turn off the generation of an EEnum.
Note that the factory eINSTANCE verses INSTANCE is directly related to
this same property (and it's easy to provide both manually).

Andy Hoffman wrote:
> Ed Merks wrote:
>
>> Andy,
>
>> Please use the EMF newsgroup, which I've added to the "to" list of
>> the reply, for future postings that are specifically about EMF.
>
> No problem, caught that on another post RIGHT AFTER I sent this one
> (blush)
>
>> Andy Hoffman wrote:
>>> Folks,
>>>
>>> I'm working on upgrading our current EMF/SDO environment from EMF
>>> 2.1 to 2.2 (finally moving upwards to Eclipse 3.2 in a large devel
>>> group).
>> To bad you aren't moving to 2.3...
>
> We will be eventually... depends on the timing. I'll be updating my
> own install to Europa probably first thing next week, but it takes
> time for everyone else (ha-ha). Would 2.3 within Europa handle these
> differences better?
>
>> In 2.2 we generalized the support for converting any enumeration
>> restriction to an EEnum by adding a EEnumLiteral.literal as a way to
>> record the original value. In 2.1, we converted to EEnums only for
>> the case that all the restrictions were valid Java identifiers and
>> then preserved exactly that name. <snip> The best I can suggest at
>> this point is
> to use an
>> ecore:name annotation in the schema to explicitly set the name to be
>> like you had before.
>
> I found the XSD to Ecore PDF online and tried the ecore:name attribute
> which overcomes the issue within EMF 2.2 (now generates matching
> enumeration names :))... however (and isn't there always a however), I
> now have another enumeration value related issue within 2.1 and
> difference within 2.2 that's a bit trickier.
>
> I also have an enumeration for listing valid countries, such as
> "UNITED STATES", "CANADA", etc., which I'm only NOW discovering was
> causing an oddity within EMF 2.1...
>
> <xs:simpleType name="CountryType">
> <xs:restriction base="xs:string">
> <xs:enumeration value="$$$NULL$$$"/>
> <xs:enumeration value="UNITED STATES"/>
> <xs:enumeration value="CANADA"/>
> <xs:enumeration value="MEXICO"/>
> </xs:restriction>
> </xs:simpleType>
>
> ... where the EEnum is not being generated (as you stated in your
> reply). I understand why it isn't, as the "UNITED STATES" value has a
> SPACE within it, and this isn't a valid Java literal name, and the
> generated code just leaves it as a string value (with no EEnum).
>
> But when I generate the code out of EMF 2.2, it now does the automatic
> renaming, and NO LONGER has a problem with the value, and generates
> the EEnum, which then invalidates the rest of my existing source code
> as well, which is using only the "String" values.
>
> I know there were trade-offs when moving from 2.1 to 2.2 in making
> improvements. Just wanted to know if there's a recommended solution
> for this situation (particularly regarding "space" characters in the
> literal value within 2.1 - or perhaps how to force 2.2 to just use a
> string value and ignore the enumeration in the meantime. Any futher
> thoughts would be appreciated.
>
>>>
>>> Also, not sure if this is related, but the *Package classes no
>>> longer seem to be generated (scratching my head on that one) - I get
>>> the *Factory classes by no *Package (???)
>> For this you can change the GenModel's "Suppress EMF Metadata" to be
>> false instead of true.
>
> Yes, I found that one, and the Package classes are now being
> generated... however, there's one additional tweak I needed to make to
> the JET emitter template, since ONE difference that happened between
> 2.1 and 2.2 was that the SDO-defaults now use "INSTANCE" instead of
> "eINSTANCE" within the Factory classes to return the default factory
> instance, and that broke my existing code as well - but changing the
> 2.2 template to continue using "eINSTANCE" did the trick :)
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator

Re: XSD to Ecore - Enumeration Problem [message #380815 is a reply to message #380813]

Tue, 26 June 2007 16:48

Andy Hoffman

Messages: 8
Registered: July 2009

Junior Member

Ed Merks wrote:

> Andy,

> You can use ecore:enum="false" to turn off the generation of an EEnum.
> Note that the factory eINSTANCE verses INSTANCE is directly related to
> this same property (and it's easy to provide both manually).

Ed, that did the trick. I now have EMF 2.2 generating model code that
exactly matches what we had within 2.1 (and 2.1 is continuing to generate
matching code with the 2.2 schema changes). Many thanks for your help
with that last attribute.

Question, is there any way to override the "Set SDO Defaults" settings
within EMF 2.2? I would like to stop "Set SDO Defaults" command from
changing the "Suppress EMF Metadata" to "true" (as I need "false" when I
generate my models). I just don't want to have to REMEMBER to switch that
every time I generate the model on schema changes - cause I'll forget :)

Andy

Report message to a moderator

Re: XSD to Ecore - Enumeration Problem [message #380816 is a reply to message #380815]

Tue, 26 June 2007 17:16

Ed Merks

Messages: 33133
Registered: July 2009

Senior Member

Andy,

It's best just to keep the .genmodel and .ecore around and then
Reload... the GenModel when the schema changes. This way all your
settings are preserved forever.

Andy Hoffman wrote:
> Ed Merks wrote:
>
>> Andy,
>
>> You can use ecore:enum="false" to turn off the generation of an
>> EEnum. Note that the factory eINSTANCE verses INSTANCE is directly
>> related to this same property (and it's easy to provide both manually).
>
> Ed, that did the trick. I now have EMF 2.2 generating model code that
> exactly matches what we had within 2.1 (and 2.1 is continuing to
> generate matching code with the 2.2 schema changes). Many thanks for
> your help with that last attribute.
>
> Question, is there any way to override the "Set SDO Defaults" settings
> within EMF 2.2? I would like to stop "Set SDO Defaults" command from
> changing the "Suppress EMF Metadata" to "true" (as I need "false" when
> I generate my models). I just don't want to have to REMEMBER to
> switch that every time I generate the model on schema changes - cause
> I'll forget :)
>
> Andy
>

Ed Merks
Professional Support: https://www.macromodeling.com/

Report message to a moderator