-
Key: EXPRESS_-18
-
Legacy Issue Number: 14184
-
Status: closed
-
Source: Eurostep Group AB ( Phil Spiby)
-
Summary:
I am starting to have doubts about the way InterfaceElements are handled in the EXPRESS meta-model. At present David's comments about not being able to re-generate the EXPRESS from the XMI appear to be true. The spec is also self contradictory, for example it states that an InterfacedElement is unique over (interfacing-schema, refers-to) it then goes on to say no two InterfaceElements (notice difference in spelling here also!!) can point to the same (interfacing-schema, refers-to) if they have different values for isImplicit, implying that if they have the same value they are allowed! How isImplicit=true is handled is giving me some problems also, if an interface is implicit it may come in through any number of routes, but the model specifies that it MUST indicate the interface in which it is defined.
-
Reported: EXPRESS 1.0b2 — Fri, 7 Aug 2009 04:00 GMT
-
Disposition: Resolved — EXPRESS 1.0
-
Disposition Summary:
It is not clear that the ability to regenerate the EXPRESS source from the metamodel is a requirement, since there are several ways in which some model information can be expressed in EXPRESS, and several model concepts that must be deduced by the EXPRESS compiler from multiple syntactic statements.
The stated uniqueness constraint in the text for InterfacedElement is in error. (It was not corrected when the other syntax-oriented changes were made in beta-2.)
There was agreement that the proper handling of "implicit interfacing" is to treat it as a separate Interface that does not correspond to an EXPRESS interface statement (USE/REFERENCE). This requires Interface:isUSE to be replaced by an attribute with three possible values: Use, Reference, Implicit; and eliminates the isImplicit attribute of InterfacedElement. -
Updated: Fri, 6 Mar 2015 21:48 GMT
EXPRESS_ — EXPRESS MM Issue -- Contradictory InterfacedElement rules
- Key: EXPRESS_-18
- OMG Task Force: 2nd EXPRESS Metamodel FTF