EXPRESS_ — EXPRESS Metamodel Enumeration Issue

Issue Submitter: David Price, Eurostep

Document: EXPRESS Metamodel, Beta Version

Issue:

The way the metamodel is structured, to map enums to UML I am required to
bring in part of the Instances package to get the literals. As the
EXPRESS/UML mapping spec is a modeling/structural level mapping I was
surprised to need something from Instances (in fact I first thought there was
an error in the metamodel and the Enum Items were missing).

We need to understand a bit more on why enum items are in Instances. The UML
metamodel doesn't seem to split the enum literals from the enum wrt which
package owns it.

Related Discussion Summary:

>From Ed Barkmeyer: I don't remember. Â Constants and EnumLiterals got stuck
into Instances after some discussion once, and I could probably find my
notes with a little effort. Â I do see that the XML Schema and EDI views of
enums are a bit different. Â They treat the datatype as string/code with a
list of allowed values, and they allow it for Integer and other types as
well. And the OWL, Java and Eclipse EMF models treat enums as "objects" –
instances of an enumeration class. Â Both of those approaches give you
"extensibility" for free, and I have found it to be the useful model for
ontologies. Â But EXPRESS is based on the Pascal/C model of enums as the
fixed values of a type, which leads to an efficient implementation
mechanism (C used 8-bit integers, Pascal used bit positions).

I would not be surprised to find that the OWL/Java/EMF approach was being
pushed, and thus thought EnumItems should be Instances.

I don't know whether there would be objection to moving Constants and
EnumItems into the Core Package, but it can't hurt to create the issue
and run it up a flagpole.

I should mention, BTW, that enums have been a problem in my current
(Message Metamodel) project. Â The problem is that you want a uniform way
of looking up values of datatypes, but you don't want to put the runtime
values in the schema, and in EMF, this creates a problem for the "value
ownership" relation. Â The EnumItems are owned by the datatype in the
schema, but the runtime values are owned by the entity instances. Â I
didn't know about that problem when we did the EXPRESS MM.

It occurs to me that EnumItem is several levels of hierarchy down in
Instances, which means that moving it into the Core Package requires
moving the intermediate classifiers – ConcreteValue (for
fundamental-type) and TypedInstance (for satisfies-(select-)type) – as
well.

Proposed Solution : None.

The real concern here is about requiring support of the entire Instances compliance point in order to require support for EnumerationItem. Accordingly, the consensus is to create a new Package for EnumerationItem and a new Compliance point that is Core+Enumerations.
As observed in the discussion above, the consistent solution is to move ConcreteValue into the Enumerations Package as well. It is not necessary to move TypedInstance, as long as the Instances Package merges the Enumerations Package. Other alternatives are more complex.