Express Metamodel Avatar
  1. OMG Specification

Express Metamodel — Closed Issues

  • Acronym: EXPRESS
  • Issues Count: 6
  • Description: Issues resolved by a task force and approved by Board
Closed All
Issues resolved by a task force and approved by Board

Issues Descriptions

Choose a term for "referent" of VARExpression

  • Key: EXPRESS-5
  • Legacy Issue Number: 13712
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In 13.10 VARExpressions, there does not seem to be a consistent term for the "referent" of a VAR-expression, what EXPRESS calls a "variable" and C calls an "lvalue" - an identifiable place that holds a value. It is the analog to the "evaluation" of an Expression, which is an Instance. In the metamodel, the term Variable here seems to have a more restricted meaning, and the term "referent" is used in multiple ways, most egregiously in the definition of AliasRef:refers-to. Some term should be chosen and used consistently for this purpose, and any conflicting use in the metamodel should be renamed. It appears that the term being used in this section (only) is "Cell". For consistency with Part 11, the term should be "Variable", but using that term might also be confusing.

  • Reported: EXPRESS 1.0b1 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    There is no inconsistency in the use of "referent"; the inconsistency is in the term for the thing that is a "referent" - "object", "place", "variable", "cell", etc. All of these will be changed to "cell".
    AliasRef:refers-to can be changed to "referent", although the text is clear that the referent of the AliasRef is self->refers-to->referent, and the "refers-to" contrasts with VariableCell:referent.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

What is a GenericElement?

  • Key: EXPRESS-2
  • Legacy Issue Number: 13687
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In 10.4.11 Generic Element
    Is every GenericType or AGGREGATEType that has a type_label a GenericElement? It seems that that is the rule, but the definition in 10.4.11 is not clear on this point.

  • Reported: EXPRESS 1.0b1 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    GenericElements are syntactically represented as parts of a data type specification, but they are not GenericTypes or AGGREGATETypes. They are separate semantic concepts that are related to type specifications. A data type represented as GENERIC:tag, for example, is a reference to the GENERIC type, and it also represents an ActualDataType whose id is the "tag".
    For each syntactic occurrence of GENERIC, GENERIC_ENTITY or AGGREGATE that defines a type_label, there is a corresponding GenericEntity that has that type_label. Other syntactic occurrences with that type_label represent ActualTypes and ActualTypeConstraints that refer to that GenericEntity.
    The model of GenericElements will be corrected in this regard. The relationship between GenericElements and GeneralizedTypes is dealt with more extensively in the resolution to Issue 14068, and the model elements that can have GeneralizedTypes and GenericElements are corrected in Issue 14194.
    Revised Text:
    The corresponding model and text changes are included under Issue 14194.

    Disposition: Merged into Issue 14194

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Correct/explain the type model for InParameter

  • Key: EXPRESS-1
  • Legacy Issue Number: 13686
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In Figure 26, InParameter inherits :formal-parameter-type (ParameterType) from Parameter. In Figure 27, InParameter inherits variable-type (VariableType) from NamedVariable. InParameter cannot have both.
    Proposed Resolution:
    Actually it can. The problem is that InParameter has two faces: the formal parameter has a ParameterType, but the corresponding internal Variable in each invocation has a VariableType - any GeneralizedType becomes the ActualType of the actual parameter. And VARParameter has the same behavior - the Parameter can have a GeneralizedType, but each instantiation refers to a "variable" that has an ActualType. Modify the text to explain this better.

  • Reported: EXPRESS 1.0b1 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    After some discussion of elaborating the model, the FTF concluded to adopt the proposed resolution and modify the text to explain the two relationships for InParameter.
    But VARVariables do not have variable-types; VARVariables only have referents. Also, ControlVariables are Variables (they can be passed to VAR Parameters, even though they cannot be assigned to). This all means that variable-type should be an attribute of Variable instead of NamedVariable. QueryVariables do have variable-types, and in order to simplify the model, they are to become a subclass of Variable, instead of NamedVariable, although it is syntactically impossible for a QueryVariable to be the referent of a VARCell.
    Finally, 10.2.5.3 documents Parameter:variable, an association that no longer exists with the Beta-2 model of InParameter and VARParameter. This will also be corrected.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

Two Subtypes of ActualParameter

  • Key: EXPRESS-4
  • Legacy Issue Number: 13698
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In 12.7 Function Calls and 13.7 Procedure Calls, it becomes clear that ActualParameter (12.7.1) is an abstraction of two distinct concepts: One associates an Expression with an InParameter (and behaves like an Assignment) and the other associates a VARExpression with a VARParameter (and behaves more like an AliasStatement). Procedures have both, but Functions have only InParameters, and thus only associations of the first kind. Splitting this concept into its two subclasses would simplify clause 12.7 and clarify clause 13.7.

  • Reported: EXPRESS 1.0b1 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    There is consensus that explicitly modeling "call by value" and "call by reference", which are the two concepts to which the issue refers, is a minor technical change. This change is an improvement in the model that removes a (compliance point) packaging problem, simplifies the text and assists in mappings.

  • Updated: Fri, 6 Mar 2015 20:58 GMT

AttributeRef/GroupRef:id subsets Expression:text

  • Key: EXPRESS-3
  • Legacy Issue Number: 13692
  • Status: closed  
  • Source: Thematix Partners LLC ( Mr. Edward J. Barkmeyer)
  • Summary:

    In 12.5, the id attribute of AttributeRef and GroupRef should be documented as subsets Expression:text, and not as derived from it, in both the text and the class diagram (figure 36).

  • Reported: EXPRESS 1.0b1 — Thu, 12 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    Merged into Issue 13689

    Disposition: See issue 13689 for disposition

  • Updated: Fri, 6 Mar 2015 20:58 GMT

EXPRESS MM issue: Correct definition of E

  • Key: EXPRESS-6
  • Legacy Issue Number: 14071
  • Status: closed  
  • Source: THALES ( Hugues Vincent)
  • Summary:

    Clause 9.8.2 I don't know what the "Napierian exponential function" is. Perhaps it is more usual to native English speaker? Yet I didn't find anything worthwhile when I googlized it (is Google anyway a reference?). I just know the "exponential function" and the "naperian logarithm function" which is the inverse of the preceding.
    Yet defining e from one of these functions whose definitions are, AFAIK, based on e itself doesn't make sense.
    I'd recommand to use the original Euler's definition: see http://en.wikipedia.org/wiki/E_(mathematical_constant)#History
    If agreed, that could be handled through an issue for the 2nd FTF.

  • Reported: EXPRESS 1.0b1 — Tue, 23 Jun 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0b2
  • Disposition Summary:

    The definition of E in the specification was taken verbatim from ISO 10303-11 Clause 14.2. However, the issue is correct: Napier published a table of natural logarithms, but the exponential function is credited to Euler. The specification should use one of Euler's definition (based on the area under the curve 1/x), or Bernoulli's definition (the limit of (1+1/n)n).

  • Updated: Fri, 6 Mar 2015 20:58 GMT