EXPRESS 1.0 FTF Avatar
  1. OMG Issue

EXPRESS_ — EXPRESS Metamodel Enumeration Issue

  • Key: EXPRESS_-22
  • Legacy Issue Number: 13663
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    Issue Submitter: David Price, Eurostep

    Document: EXPRESS Metamodel, Beta Version


    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

    Proposed Solution : None.

  • Reported: EXPRESS 1.0b2 — Fri, 23 Jul 2010 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    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.

  • Updated: Sun, 8 Mar 2015 18:08 GMT