Express Metamodel Avatar
  1. OMG Specification

Express Metamodel — Closed Issues

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

Issues Summary

Key Issue Reported Fixed Disposition Status
EXPRESS_-78 InstantiableType:fundamental-type should be derived EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-77 Correct indexing/selector text EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-76 Correct Figure references EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-75 Use consistent class diagram style EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-74 Correct UML qualified name syntax EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-73 SizeConstraint/LengthConstraint subset ParameterType:constraints EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-72 Literal:refers-to subsets Expression:evaluation EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-71 Wording of Redeclaration:lower-/upper-bound EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-70 Nature of InstantiableType EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-69 Text of Definition of RangeRole:range EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-68 Attribute:attribute-type is not a DataType EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-67 Figure 28 is the wrong figure EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-66 Distinguish AliasRef from VariableRef in text EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-65 Correct semantics of optional RETURN value EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-64 Correct the properties of Alias-binds-variable EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-63 Correct model of AliasStatement and AliasVariable EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-62 Statements can appear outside StatementBlocks EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-61 in 12.11 most values not specified as an instance object in the Instances package (Clause 9) EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-60 Indeterminate literal is not documented EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-59 Delete associations to Instance classes in 12.10 EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-58 PartialEntityConstructor attributes subset Expression attributes EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-57 Incorrect model of AggregateInitializer EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-56 AggInitializer:result-value subsets evaluation EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-55 12.8, Query expressions EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-54 Provide link for actual-referent EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-52 Correct text of Operations and FunctionCalls EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-51 AttributeRef/GroupRef:id subsets Expression:text EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-53 Clarify ActualParameter:inFunctionCall EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-50 Delete ParameterRef:id EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-49 id attributes in 12.3 subset Expression:text EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-45 id attributes in 12.3 subset Expression:text EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-44 GenericElement:source is not composite EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-48 GenericElement:source is not composite EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-47 Delete ParameterRef:id EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-46 Literal refers-to SimpleValue is not abstract EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-43 correct documentation of extent-within-population EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-42 Correct documentation of Extent:content EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-41 True, False and Unknown are not defined EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-40 Constrain of-type for SimpleValue subclasses EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-37 Remove instance-of-type EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-39 Correct derivation for value-of-EnumerationType EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-38 derivation of Redeclaration:refined-role EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-36 Derivation of redeclaration bounds EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-34 derivation of role bounds EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-35 remove "derivedFrom" dependency EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-32 Correct derivation of plays-domain-role EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-31 Scope of Attribute is not modeled EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-30 entity-has-attributes documentation EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-29 EnumerationType:values is derived EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-33 Parameter:explicit-role is not defined EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-28 Some ActualTypes have namespaces EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-27 Associations that should be composite EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-26 The metamodel doesn't seem to support a Schema -> Interface -> Schema relationship EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS11-13 Constructs that have no containers EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-16 type-specializes-type is broader than AnonymousType EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-15 Exchange of AnonymousTypes and Expressions is not possible EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-14 Many 'subsets' properties should be 'redefines' EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-17 Schema does not have a URI EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-12 Derivation of Relationships is unimplementable EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-11 Conflicting compositions involving ParametricElement EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-10 The INDETERMINATE instance cannot have a type EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-9 No way to distinguish GenericTypes EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-8 The two generalization sets for NamedType are inconsistent EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-7 Change the term 'dependency' to 'package import/merge' EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-6 replace {disjoint, total} in diagrams with generalization sets EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-5 EXPRESS MM MOF model does not include the UML InstanceSpecifications in the specification EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-4 Use UML PrimitiveTypes and not MOF: types EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS11-3 Correct CMOF file to MOF/XMI version 2.4 EXPRESS 1.0 EXPRESS 1.1 Resolved closed
EXPRESS_-25 Excess text in schema-interfaces-elements Definitions EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-24 Question on InvertibleAttribute subclass of ExplicitAttribute EXPRESS 1.0b1 EXPRESS 1.0 Resolved closed
EXPRESS_-23 The EntityType class has two properties with the same name 'attributes' EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-22 EXPRESS Metamodel Enumeration Issue EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-21 EXPRESS MM Issue -- InverseAttribute isUnique property not fully described EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-20 Generic_entity usage in Abstract entity not supported EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-19 EXPRESS MM Issue: Repair clause 6 EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-18 EXPRESS MM Issue -- Contradictory InterfacedElement rules EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-17 Singleton is not supported by CMOF EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-16 EnumerationItem has no name EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-15 EXPRESS MM Issue: correct definition of StringValue:of-type EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-14 EXPRESS MM Issue: (more) Missing subsets documentation EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-13 EXPRESS MM Issue: Built-in constants are Constants EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-12 EXPRESS MM Issue: Definition of Constant EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-10 EXPRESS MM Issue: Rename GenericElements EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-9 EXPRESS MM Issue: ActualType doesn't have a namespace EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-8 Distinguishing instances of AGGREGATEType EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-11 EXPRESS MM issue: Definition of Instance EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-7 Clarify rule for SupertypeRule:id EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-6 complete fixes for Issue 13916 EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-5 Obsolete Note in 8.13 EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-4 Define SpecializedType EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-3 EXPRESS MM Issue - Missing subsets documentation EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-2 Fix derivation on EnumerationType:values EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS_-1 Correct reference to ISO 10303-11 EXPRESS 1.0b2 EXPRESS 1.0 Resolved closed
EXPRESS-5 Choose a term for "referent" of VARExpression EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed
EXPRESS-2 What is a GenericElement? EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed
EXPRESS-1 Correct/explain the type model for InParameter EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed
EXPRESS-4 Two Subtypes of ActualParameter EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed
EXPRESS-3 AttributeRef/GroupRef:id subsets Expression:text EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed
EXPRESS-6 EXPRESS MM issue: Correct definition of E EXPRESS 1.0b1 EXPRESS 1.0b2 Resolved closed

Issues Descriptions

InstantiableType:fundamental-type should be derived

  • Legacy Issue Number: 13929
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.6.7.3, InstantiableType:fundamental-type has multiplicity 1..1. This is semantically correct, but it has the effect of requiring the fundamental-type association to be instantiated for every InstantiableType in every Schema, even though it is only used in evaluating Expressions involving SpecializedTypes. The EXPRESS rule is given in the Definition, and it can be considered to be a (recursive) derivation rule. Making the attribute "derived" in this way removes the requirement for it to be instantiated.

    Proposed change: Make InstantiableType:fundamental-type a derived association.

  • Reported: EXPRESS 1.0b1 — Tue, 12 May 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    From a semantic point of view, it is a derived attribute, and the derivation rule is stated in the definition. So the change is appropriate in all cases.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct indexing/selector text

  • Legacy Issue Number: 13919
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The introductory text of sections 12.4 and 12.5 is identical, but section 12.4 is about indexing operations, and 12.5 is about selectors. This should be cleaned up

  • Reported: EXPRESS 1.0b1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Rewrite the introductions to match the section content

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct Figure references

  • Legacy Issue Number: 13918
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    All of the Figure references in the Beta-1 text are broken. They have been replaced by the section number in which the Figure is to be found. And in most cases, the reference immediately precedes the figure in that section. For example, on p.37, the second line of the first paragraph of section 8.5 (Remarks) reads: "8.5 depicts the Remark concept...". In the Alpha version it read: "Figure 5 depicts the Remark concept...".

    There are two other Figure reference errors: In 12.8, the reference is missing entirely; the second sentence begins "depicts...". In 10.5, paragraph 1, "yyy" should be a reference to Figure 30.

  • Reported: EXPRESS 1.0b1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the references to Figures to match the Alpha text. The error in clause 12.8 is resolved by Issue 13701.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Use consistent class diagram style

  • Legacy Issue Number: 13917
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The UML class diagrams were drawn with two different tools, with the consequence that the diagrams have two radically different styles. This causes the reader to wonder whether there is a meaning to the difference in style. Change all the class diagrams to use the same style

  • Reported: EXPRESS 1.0b1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The appearance of the specification is improved by using a common diagram style. Replace all the large-font black and white figures that are not being updated by other issue resolutions, specifically Figures 1, 5, 6, 17, 18, 24, 35, 37, 43, 45, 46, 47, 48, 50.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct UML qualified name syntax

  • Legacy Issue Number: 13916
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In many places, the specification uses the EXPRESS convention for qualified names (owner.element) instead of the UML convention (owner:element). These should be changed to use the UML convention

  • Reported: EXPRESS 1.0b1 — Tue, 5 May 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the text to use the UML convention in all cases

  • Updated: Wed, 11 Mar 2015 01:54 GMT

SizeConstraint/LengthConstraint subset ParameterType:constraints

  • Legacy Issue Number: 13904
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.8.1.3 BinaryType:binary-length-constraint says that it refines InstantiableType.constraints. In clause 8.8.7.3 StringType:string-length-constraint says that it refines InstantiableType.constraints. In clause 8.9.1.3 AggregationType:lower-bound and :upper-bound say that they refine. InstantiableType.constraints.

    Actually, they all subset ParameterType:constraints and should be documented as such.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Change documentation of BinaryType:binary-length-constraint, StringType:string-length-constraint, AggregationType:lower-bound, and AggregationType:upper-bound to specify them as “subsets: ParameterType:constraints”.
    Change Figures 9 and 10 to show the subset properties.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Literal:refers-to subsets Expression:evaluation

  • Legacy Issue Number: 13903
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 12.3.2.3 EnumerationItem:refers-to says that it specializes Expression:evaluation. In clause 12.3.4.3 IndeterminateRef:refers-to says that it specializes Expression:evaluation. In clause 12.3.5.3 Literal:refers-to says that it specializes Expression:evaluation.

    These should be documented as "subsets: Expression:evaluation" instead of being derived from it.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Change documentation of EnumerationItem:refers-to, IndeterminateRef:refers-to, and Literal:refers-to from a derivation to "subsets: Expression:evaluation". Figure 34 is correct.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Wording of Redeclaration:lower-/upper-bound

  • Legacy Issue Number: 13902
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.13.1.3 under lower-bound, the Definition reads:
    "represents a restriction on the minimum cardinality of the role that is stated by the Redeclaration." And upper-bound is similarly defined. But the lower-bound represents the minimum cardinality, which is a restriction on the cardinality. It should be reworded: "represents the minimum cardinality of the role that is constrained by the Redeclaration." And similarly for upper-bound.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the wording

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Nature of InstantiableType

  • Legacy Issue Number: 13901
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.6, the 6th paragraph begins: "InstantiableTypes represent all of the data types that have actual Instances." This is incorrect, since PartialEntityValues are instances of PartialEntityTypes, which are DataTypes but not InstantiableTypes. Clause 8.6.7 correctly says that InstantiableTypes cover the data types of all objects and property values.

    In clause 8.6.7, the second sentence of the definition reads: "InstantiableType is a proper subtype of DataType (which includes classifiers that represent conformance rules for InstantiableTypes)." The parenthetical clause is wrong or at least misleading, and in any case the intent here was probably to mention PartialEntityTypes.

    The text of these two paragraphs should be corrected.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct/clarify the text of 8.6 and 8.6.7.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Text of Definition of RangeRole:range

  • Legacy Issue Number: 13900
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.12.2.3, the Definition of range ends "Derivation: range = .domain-view.attribute-type." This text should be struck. The correct derivation is given below.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Delete the leftover text

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Attribute:attribute-type is not a DataType

  • Legacy Issue Number: 13899
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.11.1.3, the Definition of attribute-type says "represents the required DataType... The DataType is required to be ...".
    What is intended here is "data type" – the general concept – not DataType, which is a class in the metamodel, and it is the wrong one.

    Also, the second sentence could be less cryptic. When the Attribute is defined within the scope of an Algorithm, the attribute-type can be an ActualType. When the Attribute is an "abstract attribute", it's nominal attribute-type is always a GeneralizedType.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct/clarify the Definition of Attribute:attribute-type.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Figure 28 is the wrong figure

  • Legacy Issue Number: 13880
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Figure 28 is a duplicate of Figure 29. It does not depict the ActualType and its subtypes concepts that were in Figure 28 of the Alpha version of the specification.

  • Reported: EXPRESS 1.0b1 — Fri, 17 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Replace Figure 28 with the ActualTypes Figure from the Alpha specification

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Distinguish AliasRef from VariableRef in text

  • Legacy Issue Number: 13713
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 13.10.4 AliasVariable, it should be stated that an AliasRef to an AliasVariable produces a different result from a VariableRef to an AliasVariable. The AliasRef produces the cell/variable/referent place, the VariableRef produces the value that is currently there. And for that reason, .refers-to may be a bad choice for the association end name (it is different from VariableRef:refers-to).

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

    Add a Note to the effect that an AliasRef to a Variable produces a different result from a VariableRef to the same Variable.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct semantics of optional RETURN value

  • Legacy Issue Number: 13711
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In, 13.9.1.3 RETURNStatement:return-value, what is stated here for FunctionCalls is syntactically correct, but semantically incorrect. The semantic rule is, if the RETURN statement appears in a FUNCTION it always has a return-value. If the return-value is not specified in the syntax, it is (implicitly) a VariableRef to the FunctionResult.

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

    Correct the Definitions of ReturnStatement and result-value to state the semantic rule.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct the properties of Alias-binds-variable

  • Legacy Issue Number: 13710
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 13.3.3, Alias-binds-variable, it is the alias-variable property of the AliasStatement that is composite, not the namespace property of the AliasVariable, and Figure 44 shows neither. This error is duplicated in 13.3.2.3 and 13.3.1.3.

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

    Figure 44 is corrected by Issue 13709. Change the association end properties in all occurrences in the text. Also, AliasStatement:body should be documented as composite.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Correct model of AliasStatement and AliasVariable

  • Legacy Issue Number: 13709
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 13.3.1, AliasStatement, the text says the ALIAS statement binds the AliasVariable to a VARExpression called the "referent", but neither the diagram nor the documented associations relate a VARExpression to the AliasStatement. 13.3.2 shows the referent VARExpression as an attribute of AliasVariable. This association should certainly appear in the diagram in Figure 44. But the actual referent of the AliasVariable at any given time is what the VARExpression evaluates to when the AliasStatement is executed. The referent VARExpression should be associated with the AliasStatement, not with the AliasVariable. That other Variables have runtime values is a fact that does not seem to have an image in the metamodel (e.g., Variable does not have a current-value association); so the fact that an AliasVariable has a runtime referent should not have such a model, either.

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

    The argument is correct. The “referent” expression should be associated with the AliasStatement, not with the AliasVariable.
    When correcting Figure 44, also correct the missing Composites for alias-binds-variable and alias-has-body.

  • Updated: Wed, 11 Mar 2015 01:54 GMT

Statements can appear outside StatementBlocks

  • Legacy Issue Number: 13708
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 13.2.5.1, under AssociationEnd: in-block, the Note says that every statement that is not a StatementBlock occurs in a StatementBlock. But the model does not appear to support this. There is no such OCL rule. And, for example, the end class of IFStatement:then-actions is a Statement, not a StatementBlock. So the first sentence of the Note appears to be false and should be struck. (Or the corresponding OCL rule should be written.)

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

    Delete the first sentence of the Note in 13.2.5.1.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

in 12.11 most values not specified as an instance object in the Instances package (Clause 9)

  • Legacy Issue Number: 13707
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.11, each literal is said to represent some value. But none of these values, except for Indeterminate, is actually specified as an Instance object in the Instances package (Clause 9). Each of them should have a .refers-to link to an object that appears in Clause 9. And each of these objects should have a .text attribute value, specifying its representation.

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

    Issue 13683 is extended to add E and PI to the NamedValues package.
    Correct Figure 42 and the text to show the attributes of the BuiltInConstants

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Indeterminate literal is not documented

  • Legacy Issue Number: 13706
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.11 BuiltInConstants, the Indeterminate Literal ("?") appears in the diagram in Figure 42, but is not documented in the text.

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

    The Indeterminate Literal (“?”) is modeled in clause 12.3.4 as IndeterminateRef, and is documented there. It is treated as a distinct kind of Primary, rather than as an instance of Literal, because it does not refer to a SimpleValue.
    Delete the Indeterminate object from the diagram in Figure 42, and add a Note to 12.3.4.
    Issue 13707 replaces Figure 42, implementing the deletion.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Delete associations to Instance classes in 12.10

  • Legacy Issue Number: 13705
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.10 PartialEntityConstructor, Figure 41, the AttributeValue, SingleEntityValue, and PartialEntityValue objects are the result of evaluating the constructor at a particular runtime instant. They should not be part of this model - the results of other operations are not modeled. The associations that reflect runtime evaluation - AttributeBinding:to-value, and PartialEntityConstructor:result-value should be deleted from the model. (Some such diagram could be used to explain what is happening, but it would be descriptive, not normative. Or these relationships could be shown as some kind of stereotyped dependency.)

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

    AttributeBinding:to-value should not be part of the model, and it isn’t documented; it only appears in Figure 41. And the use of AttributeValue and SingleEntityValue in the diagram are inappropriate.
    PartialEntityConstructor:result-value provides a means of linking a constant value to the constructor Expression when appropriate – it subsets Expression:evaluation.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

PartialEntityConstructor attributes subset Expression attributes

  • Legacy Issue Number: 13704
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.10 PartialEntityConstructor, the id value attribute should be documented as subsets Expression.text, and not as derived from it. And the result-value attribute should be documented as subsets: Expression.evaluation, and not as derived from it.

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

    Document PartialEntityConstructor:id as subsets Expression:text and remove the derivation. Note: Figure 41 is correct in this regard, but Figure 33 shows id as a derived attribute.
    Document PartialEntityConstructor:result-value as subsets Expression:evaluation and remove the derivation.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Incorrect model of AggregateInitializer

  • Legacy Issue Number: 13703
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.9, AggregateInitializer, Figure 40, the use of ListMember is wrong. A MemberBinding in an AggregateInitializer binds to a virtual "slot" in a virtual GenericAggregate. It does not bind to a ListMember of a specific LISTValue until it is evaluated in a particular runtime occurrence. (For example, the same initializer could produce different values if it occurs within a REPEAT statement and some member-value expression depends on the control-variable.) So the model in Figure 40 is incorrect. MemberBinding:to-slot is not a ListMember. It is a GenericMember of "generic aggregate", which refers to the result of the AggregateInitializer itself. In the metamodel, each other Expression class denotes the abstraction of its evaluation – we don't explicitly model the result instance. So GenericAggregate, if that is what it models, is not an Instance; it is the abstract result of the AggregateInitializer. Each actual result value is an AggregateValue, but not necessarily a LISTValue.

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

    The use of ListMember is wrong – the MemberBinding binds a member-value Expression to a virtual slot, not to an actual slot in a ListValue. The association MemberBinding:to-slot should be removed from the model.
    There is no need to model the “GenericMember”, since its properties may be totally dependent on the evaluation of RepeatCounts.
    According to ISO 10303-11 (clause 12.9), the nature of the Instance that is the evaluation of the AggregateInitializer Expression is a value of type AGGREGATE OF GENERIC. The class GenericAggregate models that concept, as specified in 9.4.6.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

AggInitializer:result-value subsets evaluation

  • Legacy Issue Number: 13702
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.9, AggregateInitializer, the result-value attribute should be documented as subsets Expression:evaluation, and not as derived from it.

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

    Document result-value as subsets Expression:evaluation and remove the derivation

  • Updated: Wed, 11 Mar 2015 01:53 GMT

12.8, Query expressions

  • Legacy Issue Number: 13701
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.8, Query expressions, first paragraph, "depicts the concepts" should be at least "Figure 38 depicts the concepts." Further, some of the text erroneously appearing at the beginning of 12.7 might belong here. In EXPRESS, QUERY is a function.

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

    Replace the first paragraph of 12.8 with a description of the relationship to EXPRESS QUERY, and refer to Figure 39.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Provide link for actual-referent

  • Legacy Issue Number: 13700
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.7.1.3, ActualParameter:actual-referent does not appear in Figure 38 above. There should be a reference here to Figure 48.

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

    Add the reference in a Note

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Correct text of Operations and FunctionCalls

  • Legacy Issue Number: 13697
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.6 Operations and 12.7 Function Calls, the first two paragraphs of both sections are identical. The first sentence reads: "This section describes Operations, QueryExpressions and Function Calls." And then it goes on to describe them. But 12.6 only presents the model for Operations and 12.7 only presents the model for FunctionCalls. These two paragraphs need to be rewritten in both places.

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

    Rewrite the introduction to 12.6 and 12.7

  • Updated: Wed, 11 Mar 2015 01:53 GMT

AttributeRef/GroupRef:id subsets Expression:text

  • Legacy Issue Number: 13696
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward 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.0
  • Disposition Summary:

    duplicates issue 13692
    Disposition: See issue 13692 for disposition

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Clarify ActualParameter:inFunctionCall

  • Legacy Issue Number: 13699
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.7.1 ActualParameter, there should be a Constraint that every ActualParameter is either inFunctionCall or inProcedureCall. In the text, it is not clear what "(always in a FunctionCall)" means in "When the corresponding formal Parameter is an InParameter (always in a FunctionCall), …". The intent is that in a FunctionCall, the corresponding formal parameter is always an InParameter, but the text appears to say that when the formal parameter is an InParameter it must be in a FunctionCall. So the text should be clarified and a corresponding Constraint should be stated.

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

    Clarify the text of the Definition, and add the suggested OCL constraint.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Delete ParameterRef:id

  • Legacy Issue Number: 13695
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.3.6.2 ParameterRef:id is inherited from VariableRef and should not appear here.

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

    duplicates issue 13691
    Disposition: See issue 13691 for disposition

  • Updated: Wed, 11 Mar 2015 01:53 GMT

id attributes in 12.3 subset Expression:text

  • Legacy Issue Number: 13694
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.3, the .id attribute of ConstantRef, ExtentRef, EnumItemRef, VariableRef, AttributeRef, GroupRef should all be documented as "subsets Expression.text" and not as derived from it.

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

    duplicates issue 13689
    Disposition: See issue 13689 for disposition

  • Updated: Wed, 11 Mar 2015 01:53 GMT

id attributes in 12.3 subset Expression:text

  • Legacy Issue Number: 13689
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.3, the .id attribute of ConstantRef, ExtentRef, EnumItemRef, VariableRef, AttributeRef, GroupRef should all be documented as "subsets Expression.text" and not as derived from it.

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

    Correct the documentation of the “id” attributes in 12.3 and 12.5.
    Correct the Figure (36) in 12.5.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

GenericElement:source is not composite

  • Legacy Issue Number: 13688
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 10.4.11.3, GenericElement:source is documented as Properties: composite, but it is actually the (derived) ParameterType:contains association to the GenericElement that is the composite. And Figure 29 shows neither as composite. The text should be corrected, and the Figure should match.
    The GenericElement occurs in the syntactic specification of the ParameterType for the specified Parameter. It refers to the element of the type of the actual parameter that corresponds to that element of the type of the formal parameter. Trying to model this in detail in MOF is just not practical.

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

    Remove “Properties: composite” from GenericElement:source. Make the relationship navigable from Parameter and composite on that side.
    Also, make the GenericElement:namespace relationship navigable from Algorithm, and show that association end as ‘type-parameters’.
    The practicality issue is to be considered under Issue 13687

  • Updated: Wed, 11 Mar 2015 01:53 GMT

GenericElement:source is not composite

  • Legacy Issue Number: 13693
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 10.4.11.3, GenericElement:source is documented as Properties: composite, but it is actually the (derived) ParameterType:contains association to the GenericElement that is the composite. And Figure 29 shows neither as composite. The text should be corrected, and the Figure should match.
    The GenericElement occurs in the syntactic specification of the ParameterType for the specified Parameter. It refers to the element of the type of the actual parameter that corresponds to that element of the type of the formal parameter. Trying to model this in detail in MOF is just not practical.

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

    duplicates issue 13688
    Disposition: See issue 13688 for disposition

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Delete ParameterRef:id

  • Legacy Issue Number: 13691
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.3.6.2 ParameterRef:id is inherited from VariableRef and should not appear here.

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

    Remove ParameterRef:id.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Literal refers-to SimpleValue is not abstract

  • Legacy Issue Number: 13690
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 12.3.5.3, Literal refers-to SimpleValue is not abstract. There are no documented subtypes of Literal. Should there be?

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

    There is no need to model subtypes of Literal.
    The properties of “refers-to” are incorrect. Per Figure 34, refers-to subsets evaluation. It is neither derived nor abstract.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

correct documentation of extent-within-population

  • Legacy Issue Number: 13685
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.7.4, extent-within-population
    Population:extents is the composite association, not Extent:within-population.
    The attribute Population:extents is not documented in 9.7.2.3; it is documented as an inverse in 9.7.2.4, and 9.7.2.4 refers to Rules:Extent instead of Instances:Extent

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

    In 9.7, show extent-within-population as composite in Figure 25.
    In 9.7.4.1, extent-within-population, move the “composite” property from within-population to extents.
    In 9.7.2 Population, delete the Other Roles entry for extents and create the correct entry under Associations, copying it from 9.7.4.1.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Correct documentation of Extent:content

  • Legacy Issue Number: 13684
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.7.1.3, AssociationEnd: content
    The text says it is derived, but Figure 25 shows it (correctly) as subsets member-values.
    Modify the text to match the diagram.

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

    as proposed

  • Updated: Wed, 11 Mar 2015 01:53 GMT

True, False and Unknown are not defined

  • Legacy Issue Number: 13683
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.3, SimpleValues
    There is no instance package that defines the simple values True, False and Unknown. We cannot formally constrain BooleanValue to be True or False, since no Instance package defines those values.

    Proposed Resolution:
    Create an instance package in the Instances Package for the built-in LOGICAL constants TRUE, FALSE, UNKNOWN.

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

    Add a NamedValues Instance Package to the Instances Package to include E, PI, TRUE, FALSE, UNKNOWN. (E and PI are added to address Issue 13707.)
    Constrain BooleanValue to TRUE and FALSE and LogicalValue to TRUE, FALSE and UNKNOWN.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Constrain of-type for SimpleValue subclasses

  • Legacy Issue Number: 13682
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.3, SimpleValues
    Unlike all of the other abstract subtypes of Instance, SimpleValue has an of-type association and none of its subclasses have specific of-type associations. This is because some SimpleValues can be values of more than one SimpleType. Accordingly, each SimpleValue subclass should have a constraint on its of-type relationships:
    For LogicalValue: isIn(Core:BuiltinTypes:LOGICAL, self->of-type)
    For NumberValue: isIn(Core:BuiltinTypes:NUMBER, self->of-type)
    For RealValue: isIn(Core:BuiltinTypes:REAL, self->of-type)
    For IntegerValue: isIn(Core:BuiltinTypes:INTEGER, self->of-type)
    For StringValue: isIn(Core:BuiltinTypes:STRING, self->of-type)
    For BinaryValue: isIn(Core:BuiltinTypes:BINARY, self->of-type)

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

    The type of LogicalValues is resolved by Issue 13683.
    For other SimpleValue objects, it is not a requirement that all of the possible “of-type” DataType relationships are modeled; it is only required that the “declared type” of the value is modeled. The proposed OCL rules would require that the declared type of each SimpleValue be the corresponding EXPRESS-defined SimpleType. The consensus is only to require that the value be an instance of an appropriate SimpleType: NumberValue ~ NumericType, BinaryValue ~ BinaryType, StringValue ~ StringType. These specific relationships replace the general relationship modeled as SimpleType:of-type.
    Figure 20 is replaced by Issue 13683

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Remove instance-of-type

  • Legacy Issue Number: 13679
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.14, Figure 16, the Association Instance-of-type is not documented. And it is not identified as the abstraction of the of-type associations in Clause 9. It should not appear in the figure.
    Proposed Resolution:
    In Figure 16, DELETE the Instance-of-type association.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Instance-of-type is intended to be the abstraction of the of-type associations in Clause 9. Document instance-of-type in 8.14 and show the of-type associations as subsetting the general property

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Correct derivation for value-of-EnumerationType

  • Legacy Issue Number: 13681
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.2.3.3 and 9.2.8.1, AssociationEnd: of-type
    In 9.2.3.3 the value expression for 'derivation' is nonsense. In 9.2.8.1, it is missing. Following the text for the inverse relation described in 8.6.6.3, this is some kind of recursive derivation operation that should be described as an operation.

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

    In 9.2.3.3 and 9.2.8.1, delete the tagged value derivation. Insert a paragraph that defines the derivation in both occurrences of the of-type Association End.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

derivation of Redeclaration:refined-role

  • Legacy Issue Number: 13680
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.13.1.3, AssocationEnd refined-role, the tagged value 'derivation' has no value expression. And the text makes the derivation clear.
    Proposed Resolution:
    In 8.13.1.3, AssocationEnd refined-role, DELETE the Tagged Values and derivation = paragraphs.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    As proposed

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Derivation of redeclaration bounds

  • Legacy Issue Number: 13678
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.13.1.3, AssocationEnds: lower-bound, upper-bound, the tagged value 'derivation' has no value expression. And the text does not make the derivation clear. The intent is that, when the restricted-type is an AggregationType, the lower-/upper- bound is the lower-/upper-bound of that AggregationType.
    Proposed Resolution:
    In 8.13.1.3, Association End: lower-bound

    a. After the Definition paragraph, ADD a new paragraph:
    When the restricted-type is an AggregationType, the lower-bound SizeConstraint is the lower-bound of that AggregationType.

    b. DELETE the "Tagged Values" and "derivation =" paragraphs.

    In 8.13.1.3, Association End: upper-bound

    a. After the Definition paragraph, ADD a new paragraph:
    When the restricted-type is an AggregationType, the upper-bound SizeConstraint is the upper-bound of that AggregationType.

    b. DELETE the "Tagged Values" and "derivation =" paragraphs.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    as proposed

  • Updated: Wed, 11 Mar 2015 01:53 GMT

derivation of role bounds

  • Legacy Issue Number: 13676
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.12.4.3 AssocationEnds: lower-bound and upper-bound, the tagged value 'derivation' has no value expression. And none can be provided, because the derivation is different for DomainRole and RangeRole.
    Proposed Resolution:
    Delete the Tagged Value 'derivation'.
    For lower-bound, break the Definition paragraph before "The lower-bound on the Domain role..."
    For upper-bound (where the break already exists), make the paragraph normative/definitive: remove "Note: ".

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Agreed. These corrections are editorial

  • Updated: Wed, 11 Mar 2015 01:53 GMT

remove "derivedFrom" dependency

  • Legacy Issue Number: 13677
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.12.6 and 8.12.7 entity-plays-domain/range-role, the <<derivedFrom>> dependencies do not appear in Figure 12. It appears that this is just documentation of the derivation of the derived association, and it only documents one leg of the derivation path. All the other cases just define 'derivation', or express it in text.

    Proposed Resolution:
    Delete 8.12.6.1 and 8.12.7.1

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    These dependencies are not a useful part of the metamodel. They should be deleted.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Correct derivation of plays-domain-role

  • Legacy Issue Number: 13674
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.11.3.3 and 8.12.6.2, AssociationEnd: plays-domain-role
    The derivation expression makes no sense. What is being defined here is a set of instances that are individually related by a derived path from a member of self->attributes.
    Proposed Resolution:
    Remove the Tagged value derivation and describe the operation that produces the derived result.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    as proposed

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Scope of Attribute is not modeled

  • Legacy Issue Number: 13673
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.11.1.3, AssociationEnd: of-entity, the text of the Note defines an unmodeled (derived) association that subsets the TypeElement.namespace association for Attribute. And the /owning-entity association end depicted in Figure 12 is not that association, since the inverse relationship defined in 8.11.3.3 (EntityType::attributes) includes the attributes of subtypes.
    As a consequence, the association that defines the namespace/scope of the Attribute as a TypeElement is not actually modeled.
    Proposed Resolution:
    Model the derived association: :of-entity->declared-in as ":namespace" explicitly in Figure 12 and in 8.11.1.3, and show it as subsets TypeElement:namespace.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The derived namespace association should be explicitly modeled for Attribute, essentially as indicated in the issue statement..

  • Updated: Wed, 11 Mar 2015 01:53 GMT

entity-has-attributes documentation

  • Legacy Issue Number: 13672
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.11.1 and 8.11.3, the entity-has-attributes association depicted in Figure 12 is not properly documented. 8.11.1 does not document .owning-entity. In 8.11.3.3. .attributes does not show the parent association, and the parent association (entity-has-attributes) is not documented as an Association in 8.11.
    Proposed Resolution:
    Document the association in a new subclause of 8.11 and correct the corresponding elements of 8.11.1 and 8.11.3.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct Figure 13 to show owning-entity.
    Document the association in a new subclause of 8.11 and correct the corresponding elements of 8.11.1 and 8.11.3.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

EnumerationType:values is derived

  • Legacy Issue Number: 13671
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.6.6.3, AssociationEnd: values is not marked Properties: derived, but it is a derived relation per the text. And the derivation expression is nonsense. The text defines a recursive operation.
    Proposed Resolution:
    Insert Properties: derived
    Delete the Tagged Value derivation, and state that the derivation is a recursive operation.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    As proposed.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Parameter:explicit-role is not defined

  • Legacy Issue Number: 13675
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.11.3.3 and 8.12.7.2, AssociationEnd: plays-range-role, In the derivation expression, ParameterType:explicit-role is not defined anywhere. The intended association is modeled as EntityType:used-in (InvertibleAttribute) in the text and in Figure 14.
    Proposed Resolution:
    In the derivation expression, REPLACE:
    ParameterType:explicit-role
    with:
    used-in
    (Note, however, that used-in is a set.)

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Because EntityType::used-in is multivalued, the derivation expression requires an iteration. Remove the derivation and replace it with a Note that explains the derivation.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Some ActualTypes have namespaces

  • Legacy Issue Number: 13670
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.6.1.3 ActualType, the Note is incorrect. Two of the subtypes of ActualType are identified by "label" and they do have a namespace.
    Proposed Resolution:
    Delete the Note.

  • Reported: EXPRESS 1.0b1 — Wed, 11 Mar 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The Note in 8.6.1.3 is correct. The label on an ActualAGGREGATEType or an ActualGenericType is a reference to the label on a component of the parameter type of some formal parameter. The label on the GeneralizedType in that parameter type is the declaration of that label and has the namespace that is the Algorithm.
    The text should be revised to make this clear.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Associations that should be composite

  • Legacy Issue Number: 13669
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Many associations in the specification should be specified as "composite", in order to facilitate XMI export and other implementation technologies. The following is a list of associations (by their end names) that are clearly 'composite' in intent, as their definitions indicate:

    (Core, clause 8)
    EntityType:unique-rules
    LocalScope:local-elements
    NamedType:type-elements
    NamedType:domain-rules
    Schema:schema-elements
    Schema:interfaces EntityType:declares
    SingleEntityType:declares
    SingleEntityValue:properties

    (Instances, clause 9)
    ARRAYValue:member-slot
    BAGValue:member-slot
    EnumerationType:declared-items
    LISTValue:member-slot

    (Algorithms, clause 10)
    Algorithm:formal-parameters
    Algorithm:actual-types
    Algorithm:body
    AlgorithmScope:variables
    Function:result
    Parameter:type-constraints
    Parameter:structure-constraints

    (Rules, clause 11)
    GlobalRule:supporting-body
    GlobalRule:contains-rules
    SupertypeRule:constraints

    (Expressions, clause 12)
    AggregateInitializer:bindings
    FunctionCall:actual-parameters
    PartialEntityConstructor:bindings
    QueryExpression:query-variable

    (Statements, clause 13)
    CaseAction:action
    CaseStatement:cases
    IfStatement:then-actions
    IfStatement:else-actions
    ProcedureCall:actual-parameters
    RepeatStatement:body
    RepeatStatement:control-variable
    StatementBlock:body-statements

    Proposed Resolution:
    For each of the above, modify the UML diagram to show the 'composition' association and modify the text specification of the association end by adding:
    Properties: composite

  • Reported: EXPRESS 1.0b1 — Fri, 6 Mar 2009 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    As proposed, and fix related association properties. In particular, Scope:named-elements, LocalScope:local-elements, NamedType:type-elements are composites and derived unions.
    Document ParameterType: constraints, which is also a composite derived union.
    Figures 2, 12, 19, 27, 29, 30, 44 are further modified by other issues.

  • Updated: Wed, 11 Mar 2015 01:53 GMT

The metamodel doesn't seem to support a Schema -> Interface -> Schema relationship

  • Legacy Issue Number: 13447
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    Issue Submitter: David Price, Eurostep

    Document: EXPRESS Metamodel, Alpha Version

    Issue:

    The metamodel doesn't seem to support a Schema -> Interface -> Schema
    relationship. I do see Schema -> InterfaceElement -> SchemaElement
    relationship in the metamodel but it's as often as not the entire Schema
    that gets interfaced.

    If I were using the metamodel in a tool to create EXPRESS, this seems to mean
    I can't establish schema interfaces beforehand (e.g. to split a domain being
    modeled into subdomains) unless I have elements in every schema. This seems
    like a gap in the metamodel.

    What I mean by this is that I should be able to take the EXPRESS metamodel,
    build an application that directly implements the classes it defines and then
    I should be able to create any and all valid EXPRESS schemas.

    Since:
    SCHEMA A;
    Â USE FROM X;
    END_SCHEMA;
    SCHEMA X;
    END_SCHEMA;

    is valid EXPRESS it seems to me the metamodel should support this. It doesn't
    seem to me that the distinction is purely syntactic if there are valid
    schemas that cannot be represented using the metamodel. I do agree with Ed
    Barkmeyers analysis of what the text in Part 11 says, it's just that the text
    appears to be incomplete in that it doesn't cover the A and X situation
    above.

    Related Discussion Summary:

    >From Ed Barkmeyer: I would say that USE FROM <schema>; is just a syntactic
    shorthand. Â What is actually interfaced is a specific collection of
    InterfacedElements. It is not clear that any additional semantic
    relationship is established between the two schemas. Â The only relationship
    between the two schemas is that some of the InterfacedElements in one Schema
    refer to SchemaElements defined in the other one.

    In the UML case, the relationship is package-to-package, and circular
    import/merge relationships are not valid. Â But EXPRESS is very clear that the
    relationship is schema-to-InterfacedElement, and circular references among
    the schemas themselves are permitted. Â Also in UML, importing a package
    doesn't change the local package namespace. Â In EXPRESS, interfacing elements
    adds identifiers to the local schema namespace. Â So Exp:Schema and
    UML:Package are only superficially similar.

    I guess we never discussed using the metamodel to "create EXPRESS", and
    I'm not quite sure what that means. Â But Bernd Wenzel pointed out at one point
    that certain purely syntactic information should be maintained in the
    metamodel to allow a reasonable approximation to the original EXPRESS
    schema to be constructed.

    My understanding was that EXPRESS was being treated as the legacy.
    So the intent of the metamodel was to capture the knowledge contained in
    a set of EXPRESS schemas, for the purpose of rendering that knowledge
    into more useful forms.

    It is not clear whether USE FROM X (<list of everything in X>); is a
    "reasonable approximation" to USE FROM X; . Â But it is certainly true
    that there is no way in the metamodel to represent USE FROM X; if X
    contains no declarations.

    Note also that, unlike USE FROM X;, what REFERENCE FROM X; interfaces is
    selective, and there you want the metamodel to capture the
    interpretation – the results of the algorithm described in clause 11 –
    not just the parse. Â So I would never want to see a metamodel population
    in which some schema-to-schema relationship was captured INSTEAD OF the
    collection of schema-to-InterfacedElement relationships that that syntax
    MEANS. Â (But the other experts may not share my view.)

    Proposed Resolution: No

  • Reported: EXPRESS 1.0b1 — Fri, 6 Feb 2009 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Add Interface to clause 8.4 and Figure 2, with two associations: interfaced-schema, interfacing-schema and an isUSE attribute

  • Updated: Wed, 11 Mar 2015 01:53 GMT

Constructs that have no containers

  • Legacy Issue Number: 19074
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    MOF/XMI (and the Eclipse EMF implementation) requires that every model element have a containment trace up to a root (model) object. In the EXPRESS metamodel, Anonymous Types, Generalized Types, and Expressions have no such trace. (There may be others.) It appears that the intent is to allow these objects to be shared, rather than to treat each occurrence as unique. With respect to the Anonymous and Generalized Types, the sharing is consistent with EXPRESS requirements for recognizing these types as the same, or as specializations of one another. The problem is then that there is a need for these objects to have a container that is consistent with the scope of their common interpretation. Expressions (which could be unique) have such a feature; it should be the container. The un-Named Type objects also need one.

  • Reported: EXPRESS 1.0 — Thu, 7 Nov 2013 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    It is not possible in general to have Attributes and Parameters “contain” their types, because the containers for NamedTypes are their namespaces. So AnonymousTypes and GeneralizedTypes need some other container. Since such types may have members whose interpretation is defined within a Scope, it is appropriate that the same Scope apply to these types.
    Expressions have a required property (interpretation-context) that is the appropriate container. The association, however must be made bi-directional and composite.
    The separate container associations are introduced here, and the expression-has-context association is modified in the MOF model.
    Remark.appears-in should be a containment, but is not so marked. This is also corrected.
    PartialEntityType also has no container. Its container should be an EntityType. A composite relationship for this is added.
    Finally, Attribute is shown as having two containers: .of-entity and (the inherited) .namespace. Only the latter should be the container; the inverse of the former (SingleEntityType.declares) should be derived from it, and there is no longer a reason for it to be a bi-directional association. This has a minor impact on implementations because these associations already exist, but the composition structure is modified.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

type-specializes-type is broader than AnonymousType

  • Legacy Issue Number: 19085
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The EXPRESS concept ‘specialization’ can relate many different kinds of types per ISO 10303-11 clause 9.2.7. In particular, it extends to AnonymousTypes, GeneralizedTypes, EntityTypes, and SelectTypes. Except for a handful of explicit relationships among SimpleTypes, it is nominally a derived property that is used when it relates to the validity of expressions, actual parameters, actual types, etc. The ‘specializes’ attribute of AnonymousType is too general for the explicit relationships, and too narrow for the general concept in the ISO clause. If it is the intent to capture the specialization relationship between types per the ISO clause where needed, the ‘specializes’ attribute should be an attribute of ParameterType (the supertype of AnonymousType that covers all the EXPRESS cases).

  • Reported: EXPRESS 1.0 — Thu, 14 Nov 2013 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    It is not clear that the property is used at all, except for the instance diagrams in clause 8.17. But the generalization to ParameterType will not affect any existing uses, and it is optional. ‘specializes’ will be generalized to ParameterType specializes ParameterType.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Exchange of AnonymousTypes and Expressions is not possible

  • Legacy Issue Number: 19081
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    AnonymousTypes, GeneralizedTypes and Expressions are not “contained in” any EXPRESS Scope element (or any other element).

    This makes it impossible for them to be conveyed in any EXPRESS XMI file. This is a particularly serious problem for AggregationTypes, which are the data types of many attributes and are rarely named. (This problem has been fixed in implementations, but it should be fixed in the specification.)

    Note: The problem was discovered in resolving Issue 18815, but it should be addressed clearly and separately.

  • Reported: EXPRESS 1.0 — Tue, 12 Nov 2013 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    This is effectively a duplicate of Issue 19074, and is resolved by the resolution to Issue 19074.
    Revised Text:
    See Issue 19074.

    Disposition: Duplicate (of Issue 19074)

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Many 'subsets' properties should be 'redefines'

  • Legacy Issue Number: 19075
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The metamodel defines a number of high-level common properties that are (or should be) constrained to subclass-subclass relationships in practice. Unfortunately many of these relationships are described as ‘subsets’ of the properties, while the EXPRESS specification is clear that they are constraints and therefore should be redefinitions. (Alternatively, some the high-level relationships could just be derived unions.)

  • Reported: EXPRESS 1.0 — Thu, 7 Nov 2013 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    The RTF agrees that almost all of the ‘subsets’ relationships to namespace or ‘of-type’ should be ‘redefines’. Similarly, the redefinitions of Expression.evaluation should be properly modeled by ‘redefines’.
    The namespace relationships are repaired in the resolution to Issue 19031. The remaining ones – Instance ‘of-type’ and typed Expressions – are corrected here. The relationship between the IndeterminateRef expression and the Indeterminate Instance class is added.
    These changes have no real affect on implementations, but they improve automatically generated code.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Schema does not have a URI

  • Legacy Issue Number: 19094
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    For XMI exchange of an EXPRESS model using the EXPRESS Metamodel, the master container, equivalent to UML:model is a Schema. But Schema has no URI attribute to label the model as a resource. ISO 10303-11 suggests that the ‘version’ attribute be used to carry an ASN.1 identifier for the Schema, but says nothing about URIs. It may be appropriate to use ‘version’ to contain the URI, but it is not clear that MOF supports that interpretation.

  • Reported: EXPRESS 1.0 — Mon, 18 Nov 2013 05:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    Add an optional URI attribute to Schema.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Derivation of Relationships is unimplementable

  • Legacy Issue Number: 19061
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The model of Relationships in clause 8.12 requires the explicit construction of a RangeRole object when the ExplicitAttribute is created, and the creation of a DomainRole object and a Relationship object when an INVERSE attribute is created (and possibly when a UsedIn construct requires them). As modeled, the association from ExplicitAttribute to Relationship is 1-to-many, and it is derived from ExplicitAttribute.RangeRole.in-relationship. But both of those associations are 1-to-1. So it is not clear how a 1-to-many association can be derived from them. On the Inverse side, the InverseAttribute creates a unique DomainRole and a unique Relationship. There is one Relationship per InverseAttribute. So, either the same RangeRole must participate in all of the Relationships, or the ExplicitAttribute relates to one RangeRole per Relationship.

    Also, for Eclipse EMF purposes, it would be good if one of the associations to each Role is composite.

  • Reported: EXPRESS 1.0 — Fri, 1 Nov 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    EXPRESS allows a subtype of the range of an ExplicitAttribute to declare an InverseAttribute whose range is subtype of the EntityType that declares the ExplicitAttribute. Consequently, an ExplicitAttribute can correspond to several technically different Relationships, each of which specifies a specific domain and range. The model in clause 8.12 must be revised to reflect this, while correcting the noted error.
    As a consequence, the relationship between a Role and the EntityType that plays it is not derived (contradicting the v1.0 model) – it is part of the definition of the specific modeled Relationship, and the derivation of the inverse relationships involves filtering functions. Conversely, the relationship between the ExplicitAttribute and the RangeRoles it defines is derivable from the Relationships it creates (1-to-1).
    Given this structure of multiple Relationship objects, each Relationship object is the appropriate container for its Roles.
    This change affects implementations. It properly enables the capture of all allowable EXPRESS language constructs. Existing implementations either ignore Relationships, or assume that they are 1-to-1 with ExplicitAttributes (which is probably the case for most published EXPRESS models).
    Issue 13870 revises the text to move the Relationships associations from InvertibleAttribute to ExplicitAttribute, and the necessary changes overlap. The changes associated with Issue 19061are therefore merged with the changes in Issue 13870.
    Revised Text:
    see Issue 13870

    Disposition: Merged

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Conflicting compositions involving ParametricElement

  • Legacy Issue Number: 19039
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.14, diagram 8.15, ParametricElement is shown as being contained in two composite associations – the inherited NamedElement.namespace and ParametricElement.source. Further the possible actual Classes that can be ElementSources are not Scopes, so the .source relationship cannot be a redefinition of NamedElement.namespace. ElementSource.type-parameters should not be a composite relationship. In EXPRESS terms, the Scope of the ParametricElement tag is the Scope of the ElementSource, and not the ElementSource itself; the ElementSource is just the definition point. The derived relationship .namespace in the diagram really is the containment relationship.

  • Reported: EXPRESS 1.0 — Tue, 29 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    The relationship to ElementSource is erroneously shown as composite. The diagram will be corrected, and the text is clarified.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

The INDETERMINATE instance cannot have a type

  • Legacy Issue Number: 19038
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    It is not possible in most implementations to specify the object-identifier for an object. In clause 10.2, Figure 10.1, “INDETERMINATE” is used as the object-identifier for an Object/Instance that has no distinguishing properties. The only modeled property of the Indeterminate metaclass (inherited from Instance) is the type(s) that the object instantiates. Clause 10.2.7 says the EXPRESS INDETERMINATE instance is not an instance of any type, but it can be treated as an instance of the required data type of the Expression, if any. That is the semantic rule, but it cannot possibly work in an implementation if the INDETERMINATE value is unique: It assumes that each use of it is a different Instance with different values for ‘of-type’. It must be a requirement that the ‘of-type’ property is always empty. In that way, the INDETERMINATE object can be identified as such. And, using MOF reflection, it is the only object that identifies its Class as “Indeterminate”.

  • Reported: EXPRESS 1.0 — Tue, 29 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    The INDETERMINATE value is deleted by the resolution to Issue 18815, precisely because it has no modeled properties. It should be a property of the Indeterminate class that SELF.of-type is always empty.
    At the same time, the existing ‘is-singleton’ constraint should be rephrased in MOF terms.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

No way to distinguish GenericTypes

  • Legacy Issue Number: 19037
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The Class GenericType has two named instances: GENERIC and GENERIC_ENTITY. But there is no attribute in the metamodel that distinguishes these instances.

    In the GenericTypes package, the two instances are distinguished only by their object-ids. It is inappropriate to assume that the Object-ids can be easily specified in an implementation.

    The GenericType metaclass should have a ‘keyword’ attribute, to capture “GENERIC” and “GENERIC_ENTITY”.

  • Reported: EXPRESS 1.0 — Tue, 29 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    Some addition to GenericType is needed for successful model exchange.
    Note that the derived ParametricType has the ‘isEntity’ property for this purpose, while SimpleTypes have an ’id’ property (of type Keyword). Since the GenericType objects are parsed from EXPRESS source, it is probably best to use the ‘id: Keyword’ pattern.
    This change also necessitates creating the slot values in the GenericTypes Instance package. Because the GenericTypes instance package is significantly revised by Issue 18815, the changes that resolve this Issue are incorporated into the Revised text of Issue 18815.
    Revised Text:
    The text changes are incorporated in Issue 18815.
    Disposition: Merged

  • Updated: Mon, 9 Mar 2015 14:34 GMT

The two generalization sets for NamedType are inconsistent

  • Legacy Issue Number: 19031
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The two generalization sets for NamedElement (in Figures 8.2 and 15.2), both of which are said to be complete (“total”), are not the same.

    There are three different categorizations of NamedElement – required Scope, actual Scope, and admissible in Scope.

    For required scope, there are subclasses of NamedElement that can only be defined in a Schema, or only in a LocalScope or only in a NamedType scope, and there are subclasses that can be defined in more than one kind of Scope – CommonElements and ParametricElements. Neither diagram shows CommonElement in this way, and Figure 8.2 says its categorization is “total” (complete) but it does not include ParametricElement at all.

    For admissibility, there are NamedElements that a Schema can define, NamedElements that a LocalScope can define, and NamedElements that a NamedType can define. This seems to be the intent of the categorization in Figure 8.2, given the definitions of CommonElement and SchemaElement. But LocalScope is an abstraction, and different kinds of LocalScopes have different admissibility rules. CommonElement is also a subtype of LocalElement, but such elements are admissible in AlgorithmScopes and not in other LocalScopes.

    On the other hand, the definitions of TypeElement and LocalElement are about the actual scope of the Named Element, which is the inverse of the admissibility relationship (it can only be what is admissible). One would expect that CommonElement and ParametricElement would be subclasses of LocalElement, but the LocalScope.namespace would have to be 0..1.

    Finally, CommonElement, LocalElement and TypeElement are all abstractions that simply NARROW the NamedElement abstraction and the NamedElement.namespace relationship in no clearly useful way. They have no other properties. If the intent is to narrow Scope.named-elements, then the model can omit LocalElement and TypeElement without loss, because the real rules are more constrained, and the purpose of LocalScope is to be what the Core defines it to be – “all other”. Whether CommonElement is more than a packaging convenience (a subset of the categorizations of SchemaElement and “AlgorithmElement”) is not clear.

  • Reported: EXPRESS 1.0 — Fri, 25 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    CommonElement has the property it is defined to have: a choice of namespace Scopes. The RTF agrees that LocalElement and TypeElement are worthless abstractions – every subclass further redefines namespace. They will be deleted and their subclasses will inherit directly from NamedElement. Figure 8.2 is simplified. The complete generalization set for NamedElement is shown in Figure 15.2.
    These changes are only to abstractions in the metamodel – they should have no affect on implementations.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Change the term 'dependency' to 'package import/merge'

  • Legacy Issue Number: 19028
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    At the beginning of the documentation of each of the packages in the EXPRESS metamodel, there is a section that refers to “dependencies”. The UML diagrams correctly show these relationships as package import and package merge. The text should be modified to use the correct UML/MOF terminology.

  • Reported: EXPRESS 1.0 — Thu, 24 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    The text ‘dependency on’ will be changed to ‘imports package’ or ‘merges package’ as required.
    Note: The resolution to Issue 19027 caused several of the Imported Packages to become package merges. This text reflects those changes.
    Note: The resolution to Issue 18745 created similar text in Clause 8.1, which was also revised by this issue resolution.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

replace {disjoint, total} in diagrams with generalization sets

  • Legacy Issue Number: 19027
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Several UML diagrams in the EXPRESS metamodel bear the markup

    {disjoint, total}

    over class-subclass decompositions. This markup is not documented in the text of the specification, and the implied generalization sets are not present in the MOF metamodel. The preferable solution is to create the generalization sets with the isDisjoint and isCovering features of MOF2.4. An alternative solution is to remove the text from the diagrams.

  • Reported: EXPRESS 1.0 — Thu, 24 Oct 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    To improve the quality of the model, the RTF determined to create the GeneralizationSets that carry the intent of the markup, which was the default interpretation in UML v1.4 (the original source of the model). This requires changing many diagrams in only this way, and properly documenting the GeneralizationSets.
    None of the generalization sets introduced in this revision are conceptually new – they all reflect restrictions defined by ISO 10303-11. Therefore the formalization should not affect implementations. The RTF regards these changes as improvements in the quality of the MOF model, not in its content.
    There is an error in Figure 10.1, which says that the Instance categories are disjoint, although the diagram shows an overlapping subclass. This error is corrected in the metamodel (below), but the diagram is substantively modified by another Issue resolution.
    The creation of certain generalization sets combines generalizations from different packages, and thus causes some package imports to become merges. The text of those sections is modified by Issue 19028, and is not corrected here.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

EXPRESS MM MOF model does not include the UML InstanceSpecifications in the specification

  • Legacy Issue Number: 18815
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The EXPRESS MM specification defines three Packages – BuiltInTypes, BuiltInConstants, and GenericTypes – that contain UML InstanceSpecifications. It also contains the Instance INDETERMINATE in the Instances package. These InstanceSpecifications represent predefined elements of the EXPRESS language that are instances of more general classes (of types and values) defined in the language. Because MOF does not support InstanceSpecification, the v1.0 MOF model does not contain any representation of these model elements. Standard representation of these model elements is critical to interoperable interchange of EXPRESS models. Some MOF-compatible representation of these model elements must be included in the specification and/or the normative artifacts.

  • Reported: EXPRESS 1.0 — Tue, 16 Jul 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    The InstanceSpecifications are maintained in the (informative) UML model and in the text. The MOF model is accompanied by a “module” in the EXPRESS (M1) XMI form. For simplicity, the EXPRESSElements module combines all the UML packages. This is described in a new section (16) of the text. To properly construct the module, it is necessary to add the formal properties (slots) to the InstanceSpecifications.
    It was noted in creating the EXPRESS modules that, although ISO 10303-11 refers to the elements in the BuiltInConstants module as “constants”, they are really just reserved words that are treated as Literals when they appear in expressions. Accordingly, the BuiltInConstants package is renamed BuiltInConstants and moved to the Expressions package, and the module is named accordingly. This has the advantage of allowing them to be formally included in a Scope as ‘Scope.expression’.
    Note that moving the package does not affect conformance to the Expressions compliance point, because Expressions imports Instances. Technically it reduces requirements for the Instances compliance point, but Instances package support for the values that these Literals refer to is still required.
    In a similar way, the INDETERMINATE object is already represented as a separate Expression (Primary) subclass: IndeterminateRef, and serves no purpose. It is deleted from the model.
    Because Issue 19037 adds an attribute to the GenericType instances, the corresponding text changes are incorporated into the revised text below.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Use UML PrimitiveTypes and not MOF: types

  • Legacy Issue Number: 18745
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    UML::Boolean (or PrimitiveTypes::Boolean) would be correct throughout the document (and MOF::Boolean strictly-speaking incorrect); and if the Express metamodel were to import the PrimitiveTypes model, then unadorned Boolean would do the trick nicely.

  • Reported: EXPRESS 1.0 — Thu, 30 May 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    Make the Core Package explicitly import the UML PrimitiveTypes package, thus properly documenting the datatypes previously called “MOF datatypes”..
    Modify section 8.2 to refer to UML Primitive Types.
    Change all occurrences of MOF:Boolean, MOF:Integer, MOF:String to the corresponding UML primitive type.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Correct CMOF file to MOF/XMI version 2.4

  • Legacy Issue Number: 18744
  • Status: closed  
  • Source: Model Driven Solutions ( Steve Cook)
  • Summary:

    I am puzzled by the use of the cmof: namespace in the cmof file. At version 2.4.1 it is normal to use UML XMI files for metamodels – see, for example, the UML 2.4.1 metamodel itself (http://www.omg.org/spec/UML/20110701/UML.xmi). I believe there is a fundamental misunderstanding here – from 2.4 onwards there is no longer any special cmof format. I think that simply deleting all of the MagicDraw-specific content from 13-05-34 would give almost all of what you want; you would perhaps then need a mof:Tag for nsPrefix to make it a correct metamodel.

  • Reported: EXPRESS 1.0 — Thu, 30 May 2013 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.1
  • Disposition Summary:

    For version 1.1, create a proper CMOF v2.4.1 XMI file.

  • Updated: Mon, 9 Mar 2015 14:34 GMT

Excess text in schema-interfaces-elements Definitions

  • Legacy Issue Number: 13905
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.4.7.3, at the end of the Definition of AssociationEnd: interfaced-elements, delete the text ".interfaced-elements=.interfaces.refers-to" It is the derivation below.

    In clause 8.4.18.1, at the end of the Definition of AssociationEnd: interfaced-elements, delete the text ".interfaced-elements=.interfaces.refers-to" It is the derivation below.

    In clause 8.4.18.1, at the end of the Definition of AssociationEnd: referenced-in, delete the text ".referenced-in=.referenced-as.interfacing-schema" It is the derivation below.

  • Reported: EXPRESS 1.0b1 — Tue, 28 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Delete the text ".interfaced-elements=.interfaces.refers-to" from the entries for interfaced-elements in 8.4.7.3 and 8.4.18.1. Delete the text ".referenced-in=.referenced-as.interfacing-schema" from the Definition of referenced-in in 8.4.18.1. These corrections are included in the resolution of Issue 13447.
    Note: Issue 13447 was resolved in the FTF Report and thus in v1.0 of the specification, and these changes were made at that time.
    Revised Text:
    None.
    Disposition: See issue 13447 for disposition

  • Updated: Mon, 9 Mar 2015 14:33 GMT

Question on InvertibleAttribute subclass of ExplicitAttribute

  • Legacy Issue Number: 13870
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    It seems an odd thing to me to create a subclass of ExplicitAttribute to
    instantiate for Attributes that have the potential to have inverses. I don't
    understand the rationale. Seems like it would be simper to have a constraint
    on InverseAttribute about it being owned by an EntityType referenced in an
    ExplicitAttribute

  • Reported: EXPRESS 1.0b1 — Thu, 16 Apr 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The RTF agrees that the InvertibleAttribute subclass of ExplicitAttribute is inappropriate. Careful examination of Clause 9.2.1 of ISO 10303-11 indicates that all ExplicitAttributes can create Relationships. The InvertibleAttribute in Clause 8.11.6 was intended to capture formal relationships among entities, following the rules for InverseAttributes in EXPRESS, but it is not a proper model of the EXPRESS ‘relationship’ concept.
    Accordingly, the InvertibleAttribute subclass is removed and replaced in all appropriate usages by the superclass ExplicitAttribute.
    An OCL formulation of the EXPRESS rules for the permissible attribute types of an ExplicitAttribute that is invertible may not be possible. The restriction is captured using a Boolean “isInvertible” attribute.
    Removing InvertibleAttribute from the Relationships diagram also eliminates the last use of the <<implicit>> extension. The extension is removed from the model.
    Issue 19061 points out other implementation problems with the Relationships model, and the resolution to that issue (q.v.) describes model corrections that overlap with the changes made in resolving this issue. The changes for Issue 19061 are merged with the changes for this Issue below.

  • Updated: Mon, 9 Mar 2015 14:33 GMT

The EntityType class has two properties with the same name 'attributes'

  • Legacy Issue Number: 14082
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    The EntityType class has two properties with the same name -
    'attributes'.

    Proposed Resolution: Rename one of the properties.

  • Reported: EXPRESS 1.0b2 — Thu, 16 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The 'entity-has-attributes' association is depicted in Figure 13. The "other property" is depicted in Figure 14, but it is depicted as <<implicit>>, meaning that it is a diagram convention only, as described in Clause 6 - a representation of the association in Figure 13 as inherited by InvertibleAttribute. So there is only one property that is named: EntityType:attributes.
    The problem is that the CMOF file contains two distinct associations with the same names, because the tooling did not understand the <<implicit>> association to be a diagram convention.

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

EXPRESS Metamodel Enumeration Issue

  • Legacy Issue Number: 13663
  • Status: closed  
  • Source: TopQuadrant ( David Price)
  • Summary:

    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.

  • 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

EXPRESS MM Issue -- InverseAttribute isUnique property not fully described

  • Legacy Issue Number: 14215
  • Status: closed  
  • Source: Eurostep Group AB ( Phil Spiby)
  • Summary:

    According to ISO 10303-11:2004 an Inverse attribute may be specified to
    be a SET, a BAG or a entity data type. The description of isUnique
    identifies values for SET and BAG but does not prescribe a value for
    entity data type.

  • Reported: EXPRESS 1.0b2 — Fri, 21 Aug 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    In clause 8.11.5 (InverseAttribute), the definition of isUnique reads:
    Definition: True if the designated relationship between this instance and any given instance can occur at most once; False if it can occur more than once. (True if the INVERSE attribute is described as a SET; False if it is described as a BAG.)
    The intent of the normative text is clear, but the parenthetical sentence does not address the case in which the attribute-type INVERSE attribute is declared to be an entity-type rather than an aggregation type. The parenthetical sentence will be corrected to clarify this case.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Generic_entity usage in Abstract entity not supported

  • Legacy Issue Number: 14194
  • Status: closed  
  • Source: Anonymous
  • Summary:

    According to ISO 10303-11:2004 a GENERIC_ENTITY may be used to represent
    an explicit or derived attribute within an ABSTRACT ENTITY. According to
    the Meta-model the use of the syntactic element type_label is restricted
    to parameters. This conflicts with ISO specification and should be
    changed.

  • Reported: EXPRESS 1.0b2 — Tue, 18 Aug 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Agreed. This addition to the 2004 version of EXPRESS was overlooked in the RFC specification, and it includes AGGREGATE as well. This has several consequences for the metamodel.
    The GenericElement concept is used in defining EntityTypes outside of Algorithms, and thus should be supported by the Core Package. And the same is true of the ActualTypeConstraint, according to ISO 10303-11:2004. Parts of clause 10.4 and all of clause 10.5 will therefore be moved into the Core package (clause 8).
    A new abstract class will be created (ElementSource) to be a purpose-built supertype of Parameter and Attribute that relates to GenericElements and ActualTypeConstraints.
    GenericElement has two possible choices of namespace - EntityType or Algorithm - with the consequence that it is of no modeled subtype of NamedType. It will simply be a subtype of NamedType with two choices of Scope.
    Because the revised text moves a section of the metamodel into the Core package, it also incorporates the resolution of Issues 14068, 14070, and 13687, which affect the moved text. In particular, Issue 14070 renames GenericElement, ActualDataType, ActualStructure to ParametricElement, ParametricType, ParametricStructure, respectively. In effect, this whole section of the model has been rewritten, and the change of names makes it easier for implementors to find all the affected code.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: Repair clause 6

  • Legacy Issue Number: 14185
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 6 contains a number of statements that may have been true of the RFC, but are no longer appropriate, notably:

    • out-of-date things about the metaclass stereotype
    • out-of-date things about the names of assocations on the diagrams
    • out-of-date references to the CMOF and UML files.

    Proposed change: Align the text with current diagram practice.

  • Reported: EXPRESS 1.0b2 — Fri, 7 Aug 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The issue is correct. Clause 6 will be modified to align the stated "conventions" with the actual practice in the specification.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue -- Contradictory InterfacedElement rules

  • 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

Singleton is not supported by CMOF

  • Legacy Issue Number: 14164
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    According to the CMOF v2 specification, the <<Singleton>> stereotype is ignored by CMOF. The metamodel should therefore not use the stereotype on the Indeterminate class in Instances (the only use), explicitly model the Indeterminate value object, and write the appropriate OCL rule.

    The IndeterminateRef in 12.3.4 should be specified to return that object.

  • Reported: EXPRESS 1.0b2 — Thu, 30 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The use of <<Singleton>> should be removed. An INDETERMINATE object will be created to instantiate the Indeterminate class, and the appropriate rules will be added to the model.
    Note: the INDETERMINATE Instance has no data type, which means that the 1..* on Instance:of-type is incorrect. This will also be fixed.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EnumerationItem has no name

  • Legacy Issue Number: 14136
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    According to ISO 10303-11, the domain of an EnumerationType is "a set of names". But the EnumerationItem in Beta-2 has no "name" attribute, and does not appear to inherit one!

    Proposed change:
    Add an attribute to EnumerationItem: name: String.

  • Reported: EXPRESS 1.0b2 — Tue, 28 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    issue withdrawn by submitter

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: correct definition of StringValue:of-type

  • Legacy Issue Number: 14077
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.3.9.3, the references to BinaryType and BinaryValue should be to StringType and StringValue.

  • Reported: EXPRESS 1.0b2 — Mon, 13 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the references.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: (more) Missing subsets documentation

  • Legacy Issue Number: 14076
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.11.3, the unique-rules attribute should subset type-elements, as shown in the diagram.

    In 10.2.11.2, both namespace and result should subset the corresponding ends of local-element-has-local-scope, as shown in Figure 30.

    In 10.3.5.2, both namespace and variables should subset the corresponding ends of local-element-has-local-scope, as shown in Figure 31.

  • Reported: EXPRESS 1.0b2 — Mon, 13 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The diagrams are correct. The documentation should be corrected to show the subsets relationships.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: Built-in constants are Constants

  • Legacy Issue Number: 14074
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Beta-2 has a new subclause 9.8: NamedValues, and it contains the definitions of what ISO 10303-11 calls BuiltInConstants. This appears to be the same concept as Constant, except that the names are defined in the language, instead of the Schema. For some reason, clause 12.11 still defines specific Literal values to refer to these NamedValues, instead of just using the ConstantRef concept. Why? Making the NamedValues a kind of Constant would allow the redundant 12.11 to be deleted from the model.

  • Reported: EXPRESS 1.0b2 — Mon, 13 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    A Constant is not an Instance; a Constant refers to an Instance (and not always the same instance). A NamedValue is an Instance. The name of a Constant is in some namespace; the name of a NamedValue is a keyword in the language. The model just doesn't correspond.
    It is, however, possible to delete "the redundant 12.11". There is no reason to model the specific forms of Literals that denote specific values. It is, however, useful to note that a reference to a NamedValue or to Indeterminate is a Literal.
    As the issue observes, the NamedValues are called BuiltInConstants in ISO 10303-11, which suggests that changing the name of the NamedValues Package is appropriate (after deleting the BuiltInConstants package in 12.11).

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: Definition of Constant

  • Legacy Issue Number: 14073
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 9.6.1 Constants are said to be Instances in the definition, but Constant has only one supertype: CommonElement; Constant is not modeled as a subtype of Instance. The model only shows a Constant to be related to an Instance by :actual-value. One of the model and the definition must be wrong.

  • Reported: EXPRESS 1.0b2 — Mon, 13 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The model is correct. Constant is not a subtype of Instance. The definition says that a Constant "denotes" an Instance. It behaves more like an initialized variable in that it has a lifetime and represents a given instance during its lifetime. Only Constants that are SchemaElements behave like Instances. The text will be revised to clarify this.
    The appearance of Constant in the Instance Package is misleading. Constant should not be in the Instance Package, precisely because it is not an Instance. Because Constants, especially Constants whose value-expressions are Literals, can be used in formulating datatypes, Constant could be moved to the Core package or to the Expressions package.
    Also, the :actual-value relationship should be derived from the value-expression

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: Rename GenericElements

  • Legacy Issue Number: 14070
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The use of "Actual" on both sides of the ActualAggregateType to ActualStructure relationship, and the ActualGenericType and ActualDataType relationship is confusing and makes it seem that one pair of those classes is redundant. And ActualStructure and ActualDataType are subtypes of "GenericElement", but they have no common words in the names. GenericElements are some kind of "type parameter" (which is what the association end is called). So ActualStructure should be StructureParameter, or GenericStructure, or something like that, shouldn't it?

    Proposed change:

    Rename GenericElement, ActualDataType, ActualStructure to make the naming consistent and make it clear that they are "type parameters".

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

    The designation GenericElement suggests that it is some general class of model element. "Actual" is overloaded - here it refers to elements taken from ActualParameters, while the "ActualTypes" are derived from them. The classes will be renamed: ParametricElement, ParametricStructure, ParametricType.
    The resolution to Issue 14194 moves the section of text that defines these concepts to the Core package. So these changes are made in that text.
    Revised Text:
    The text changes are incorporated into the model changes in issue 14194.
    Disposition: Merged into Issue 14194

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue: ActualType doesn't have a namespace

  • Key: EXPRESS_-9
  • Legacy Issue Number: 14069
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 8.6.1.3 and Figure 32 says that ActualTypes have a namespace. As Figure 33 shows, the GenericElements are the objects that define the type_labels within the Algorithm; the ActualTypes don't. The ActualGenericType and ActualAggregateType just have identifiers that refer to these. If the same ActualStructure is used for ActualAggregateTypes with different member types, the ActualTypes are different, but the type labels – the names in the namespace – are the same, which violates the uniqueness rule for namespaces.

    So ActualTypes don't have ScopedIds, and they don't have a namespace.
    (It may be that they must be "owned by" the Algorithm for CMOF purposes, but that should be a separate concern.)

    Proposed change:

    Delete the :namespace association for ActualType.

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

    The name of the issue is misleading. The text of 8.6.1.3 AssociationEnd: scope is clear on this point:
    "An ActualType does not really have a namespace; the GenericElement to which it refers is a LocalElement whose namespace is the Algorithm. The .scope of the ActualType does, however, represent the ownership of the ActualType as a LocalElement and the lifetime of the ActualType. "
    The problem is that no ActualType has a ScopedId - an ActualType is not a NamedElement, and its 'scope' relationship does not subset the LocalElement:namespace relationship. The model will be corrected.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Distinguishing instances of AGGREGATEType

  • Key: EXPRESS_-8
  • Legacy Issue Number: 14068
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    Clause 8.10.1 is not clear as to how instances of AGGREGATEType are distinguished. Those with different type_labels should be different, but 8.10.1 doesn't say so, and it doesn't model the labels. Those with the same type_label are treated as constraints. But what about AGGREGATEs with no type labels? For exchange purposes, we need to agree on how to distinguish instances.

    Then in Clause 10.4.2, an ActualAggregateType refers to an ActualStructure, but an ActualStructure doesn't have any relationship to an AGGREGATE type. So how is the type derivation relationship determined? It is possible that the parameter type of the :source Parameter involves two AGGREGATE types, e.g.:
    FUNCTION F(x: AGGREGATE:a [1:?] OF AGGREGATE:b [0:?] OF GENERIC):REAL;
    In clause 8.10, the AGGREGATETypes do not have type_labels, so it is not clear whether to match the ActualStructure labeled "a" to the AGGREGATE of AGGREGATE or to the AGGREGATE of GENERIC.

    (This problem does not arise for ActualDataType, because there can be only one GENERIC or GENERIC_ENTITY type in the :source Parameter.)

    Proposed change:

    Clarify how instances of AGGREGATEType are distinguished. And either give them a label, or create a relationship from ActualStructure to AGGREGATEType.

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

    (Note: The resolution incorporates changes in terminology that were adopted by Issue 14070.)
    For each syntactic occurrence of GENERIC, GENERIC_ENTITY or AGGREGATE that defines a type_label, there is a corresponding ParametricElement that defines that type_label. Other syntactic occurrences with that type_label represent ActualTypes and ActualTypeConstraints or ActualStructureConstraints that refer to that ParametricElement.
    Each syntactic occurrence of AGGREGATE is a distinct instance of AGGREGATEType. It is not modeled as having a type_label, because two distinct AGGREGATETypes can have the same type_label. The specification will be modified to make this clear.
    The type_label on an occurrence of AGGREGATE serves to label the associated ParametricStructure, or to associate ActualTypes and ActualStructureConstraints with it. Since there may be more than one such structural element in the parameter-type of a given Parameter, each ParametricStructure must be associated with the specific AGGREGATEType. ParametricStructure is not a subtype of AGGREGATEType; it is associated with one. The specification will be corrected.
    In resolving this issue, it was observed that a similar ambiguity exists with respect to GENERIC:tag and GENERIC_ENTITY:tag. It is not clear how many GenericTypes there are. This problem was resolved as follows:
    There are exactly two GenericTypes (GENERIC, GENERIC_ENTITY) and they don't have type_labels. The definition of GenericType is incorrect in this regard, and the :isEntity attribute serves no purpose. isEntity is properly an attribute of ParametricTypes - the ParametricElements that correspond to GENERIC:tag and GENERIC_ENTITY:tag. The model will be corrected.
    The type_label on an occurrence of GENERIC or GENERIC_ENTITY serves to label the ParametricType, or to associate ActualTypes and ActualTypeConstraints with it. ParametricType is not a subtype of GenericType; the specification will be corrected.
    All occurrences of GENERIC refer to the same type; and all occurrences of GENERIC_ENTITY refer to the same type. Therefore, the ParametricType based on a GENERIC:tag component has no distinguishing type to refer to. The occurrence of GENERIC or GENERIC_ENTITY, however, must be unique within a ParameterType; so the referent of the ParametricType is implicit in the :source (Parameter or Attribute) that has the ParameterType. The model is modified to reflect this design.
    Summary: The technical changes are conceptually three:

    • AGGREGATEType and GenericType are clarified.
    • ParametricElements are not parts or specializations of GeneralizedTypes
    • ParametricStructures are associated with specific AGGREGATETypes.
      The resolution of Issue 14194 simplifies the change somewhat, by moving most of the affected text from Clause 10 into Clause 8. So all of the technical changes are incorporated in the resolution of 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 21:48 GMT

EXPRESS MM issue: Definition of Instance

  • Legacy Issue Number: 14072
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    According to clause 5 of ISO 10303-11, the concept Instance means "things that may be in the domains of data types". The definition of Instance in the metamodel (8.14.2 and 9.2.1) is: "any real or conceptual object, information unit, or data item." Change/extend the definition to clearly reflect the ISO 10303-11 intent.

  • Reported: EXPRESS 1.0b2 — Mon, 13 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Clarify the definition of Instance to refer to the domains of data types.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Clarify rule for SupertypeRule:id

  • Key: EXPRESS_-7
  • Legacy Issue Number: 14053
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 11.3.4, the last sentence of the definition appears to state a constraint on the inherited attribute id:ScopedId. But it says "cannot" instead of "shall not", and it is not clear whether it applies to SupertypeRule or SubtypeConstraint or both.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Clarify/correct the rule specified in the last sentence of the Definition per clause 9.7 of ISO 10303-11.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

complete fixes for Issue 13916

  • Key: EXPRESS_-6
  • Legacy Issue Number: 14052
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    The resolution of Issue 13916 indicated that all of the following changes should be made:
    1. REPLACE all occurrences of ".namespace" with ":namespace"
    2. REPLACE all occurrences of ".named-elements" with ":named-elements"
    3. REPLACE all occurrences of ".type-elements" with ":type-elements"
    4. REPLACE all occurrences of ".local-elements" with ":local-elements"
    5. REPLACE all occurrences of ".constraints" with ":constraints"
    6. REPLACE all occurrences of ".in-" with ":in-"
    7. REPLACE all occurrences of ".position" with ":position"
    8. REPLACE all occurrences of ".id" with ":id"
    9. REPLACE all occurrences of ".evaluation" with ":evaluation"
    10. REPLACE all occurrences of ".text" with ":text"

    These changes were not made in the Beta-2 version.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    This issue collects miscellaneous editorial corrections.
    Complete the editorial changes specified by the first FTF Report. But in lieu of item 6 above, correct the references to ".in-relationship" appropriately. Correct other period/colon errors, and make other editorial corrections.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Obsolete Note in 8.13

  • Key: EXPRESS_-5
  • Legacy Issue Number: 14051
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.13, the Note before Figure 15 refers to a feature that is no longer present in the diagram. Delete the Note.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    The issue is correct. Delete the Note.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Define SpecializedType

  • Key: EXPRESS_-4
  • Legacy Issue Number: 14050
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.6.11 (SpecializedType), the Definition was somehow garbled by the Note.

    Following the pattern in 8.6.6 and 8.6.10, the Definition should be something like: a DefinedType representing an EXPRESS defined data type whose underlying_type is not a SELECT type nor an ENUMERATION.

    Alternatively, we could actually provide definitions for these three classes that give the reader some understanding of the intent.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Repair the definition of SpecializedType in 8.6.11, and the Note, which refers to the wrong clauses of ISO 10303-11. Expand the definitions in 8.6.6 and 8.6.10 to give some indication of the meaning of the types.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

EXPRESS MM Issue - Missing subsets documentation

  • Key: EXPRESS_-3
  • Legacy Issue Number: 14049
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 8.4.16.2, AssociationEnd: local-elements should be marked:
    subsets: Scope:named-elements

    In 8.4.17.2, AssociationEnd: schema-elements should be marked:
    subsets: Scope:named-elements

    In 8.4.21.1, AssociationEnd: type-elements should be marked:
    subsets: Scope:named-elements

    In 8.4.21.1, AssociationEnd: namespace should be marked:
    subsets: NamedElement:namespace

    Either 8.4.21 should be marked as having the supertype element-defined-in-scope, or that subclause should be deleted from 8.4.16 and 8.4.17.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the identified "subsets" properties. Retain the association generalization in 8.4.16 and 8.4.17 and add it to 8.4.21, for documentary purposes, even though CMOF v2 does not support association generalizations.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Fix derivation on EnumerationType:values

  • Key: EXPRESS_-2
  • Legacy Issue Number: 14048
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In 9.2.8.1, under AssociationEnd: values, the "derivation" Tagged Value has no value. This subclause should look like its counterpart in 8.6.6.3 (p.42).

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Resolution:
    The entry in 9.2.8.1 should be the same as the entry in 8.6.6.3.
    Revised Text:
    The revised text is included in the revised text for issue 13663, which moves the clauses in question.

    Disposition: Merged into Issue 13663

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Correct reference to ISO 10303-11

  • Key: EXPRESS_-1
  • Legacy Issue Number: 14047
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward Barkmeyer)
  • Summary:

    In clause 8.9.1.3, under AssociationEnd: lower-bound, the Note refers to "8.2.x of ISO 10303-11". It should refer to "8.2.2, 8.2.3 and 8.2.4"

    Similarly, under AssociationEnd: upper-bound, same Note.

  • Reported: EXPRESS 1.0b2 — Wed, 1 Jul 2009 04:00 GMT
  • Disposition: Resolved — EXPRESS 1.0
  • Disposition Summary:

    Correct the Notes.

  • Updated: Fri, 6 Mar 2015 21:48 GMT

Choose a term for "referent" of VARExpression

  • Key: EXPRESS-5
  • Legacy Issue Number: 13712
  • Status: closed  
  • Source: Thematix Partners LLC ( Edward 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 ( Edward 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 ( Edward 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 ( Edward 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 ( Edward 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