Express Metamodel Avatar
  1. OMG Specification

Express Metamodel — All Issues

  • Acronym: EXPRESS
  • Issues Count: 23
  • Description: All Issues
Open Closed All
All Issues

Issues Summary

Key Issue Reported Fixed Disposition Status
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

Issues Descriptions

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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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 ( Mr. Edward J. 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