Issues for Mailing list of the Reference Model for EXPRESS Information Modeling Language Finalization Task Forc
To comment on any of these issues, send email to express-ftf@omg.org. (Please include the issue number in the Subject: header, thusly: [Issue ###].) To submit a new issue, send email to issues@omg.org.
List of issues (green=resolved, yellow=pending Board vote, red=unresolved)
Issue 13663: EXPRESS Metamodel Enumeration Issue
Issue 13686: Correct/explain the type model for InParameter
Issue 13687: What is a GenericElement?
Issue 13692: AttributeRef/GroupRef:id subsets Expression:text
Issue 13698: Two Subtypes of ActualParameter
Issue 13712: Choose a term for "referent" of VARExpression
Issue 14047: Correct reference to ISO 10303-11
Issue 14048: Fix derivation on EnumerationType:values
Issue 14049: EXPRESS MM Issue - Missing subsets documentation
Issue 14050: Define SpecializedType
Issue 14051: Obsolete Note in 8.13
Issue 14052: complete fixes for Issue 13916
Issue 14053: Clarify rule for SupertypeRule:id
Issue 14068: Distinguishing instances of AGGREGATEType
Issue 14069: EXPRESS MM Issue: ActualType doesn't have a namespace
Issue 14070: EXPRESS MM Issue: Rename GenericElements
Issue 14071: EXPRESS MM issue: Correct definition of E
Issue 14072: EXPRESS MM issue: Definition of Instance
Issue 14073: EXPRESS MM Issue: Definition of Constant
Issue 14074: EXPRESS MM Issue: Built-in constants are Constants
Issue 14076: EXPRESS MM Issue: (more) Missing subsets documentation
Issue 14077: EXPRESS MM Issue: correct definition of StringValue:of-type
Issue 14082: The EntityType class has two properties with the same name 'attributes'
Issue 14136: EnumerationItem has no name
Issue 14164: Singleton is not supported by CMOF
Issue 14184: EXPRESS MM Issue -- Contradictory InterfacedElement rules
Issue 14185: EXPRESS MM Issue: Repair clause 6
Issue 14194: Generic_entity usage in Abstract entity not supported
Issue 14215: EXPRESS MM Issue -- InverseAttribute isUnique property not fully described
Issue 13663: EXPRESS Metamodel Enumeration Issue (express-ftf)
Click here for this issue's archive.
Source: TopQuadrant (Mr. David Price, dprice(at)topquadrant.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text:
Actions taken:
July 23, 2010: closed issue
June 6, 2011: closed issue
Issue 13686: Correct/explain the type model for InParameter (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In 8.4.16, in the first Note, last sentence, CHANGE "Variables" to "NamedVariables", so that the sentence reads:
In fact, only NamedVariables can be defined in every LocalScope.
2. In 8.6.12.4, in the first paragraph, CHANGE "NamedVariable" to "Variable", so that the entry reads:
From: Algorithms::Variable as variable-type
3. In clause 10.2.4, at the end of the 3rd paragraph (beginning "An InParameter has a formal-parameter-type…"), ADD:
When the formal-parameter-type is an InstantiableType, the variable-type is the same type. When the formal parameter-type is a GeneralizedType, the variable-type is the corresponding ActualType.
and ADD a Note:
Note - It is possible that the formal-parameter-type is itself an ActualType, if the Algorithm is defined within another Algorithm. In such a case, the variable-type is the same type.
4. In 10.2.5.3, DELETE the entire entry for AssociationEnd: variable (6 paragraphs):
AssociationEnd: variable To: InVariable
via: variable-for-parameter
Definition: the InVariable that corresponds to the InParameter during each evaluation of the Algorithm.
During an evaluation of the Algorithm that defines the InParameter, the value of the InVariable may change. The corresponding actual parameter value does not change.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 1..1
5. In clause 10.2.8, in the Definition paragraph, after the first two sentences, DELETE the text:
A VARParameter is not a separate object; it is rather a temporary name for an existing object - the ActualParameter. Alternatively, it may be thought of as an object that holds a pointer to another object. All references to a VARParameter (in Statements and Expressions) refer to the object that the VARParameter refers to.
and ADD 2 new paragraphs:
During an invocation of the Algorithm, theVARParameter is a VARVariable whose referent is specified by the VARExpression that is the corresponding ActualParameter. All references to a VARParameter (in Statements and Expressions) refer to its referent.
As a Parameter, the VARParameter has a formal-parameter-type, which is the type specification to which the corresponding ActualParameters are required to conform. As a VARVariable, its data type is the type of its referent.
6. In clause 10.3, REPLACE Figure 31 (Variables) with:
<image=Issue13686-Figure31-Variables.png>
7a. In clause 10.3.2, in the Definition paragraph, last sentence, CHANGE "scopes" to "scope", so that the sentence reads:
Each kind of NamedVariable has a different scope, but the scope of every NamedVariable is a LocalScope.
7b. In clause 10.3.2, DELETE the 2nd paragraph:
Every NamedVariable has a declared variable-type, which may be an InstantiableType or an ActualType.
and REPLACE it with:
Every NamedVariable is either a Variable or a VARVariable.
8a. In clause 10.3.2.3, DELETE the entire entry (4 paragraphs) for AssociationEnd: variable-type:
AssociationEnd: variable-type To: Core::VariableType
Definition: the actual data type of the Variable. In any given invocation, the data type of the Variable is an InstantiableType. If the data type of the Variable is specified as an InstantiableType, it is fixed for all invocations. If the data type of the Variable is specified as an ActualType, the actual data type varies from invocation to invocation, according to the data type of an actual parameter. If the Variable is a Parameter and its formal parameter type is a GeneralizedType, the variable-type is the corresponding ActualType.
Note - See 9.5.4 of ISO 10303-11:2004.
Multiplicity: 1..1
and REPLACE it with the paragraph:
none.
8b. In clause 10.3.4.3, REPLACE the paragraph:
none.
with the 5 paragraphs:
AssociationEnd: variable-type To: Core::VariableType
Definition: the data type of the Variable - the type of the values that the Variable can contain.
In any given invocation, the data type of the Variable is an InstantiableType. If the data type of the Variable is specified as an InstantiableType, it is fixed for all invocations. If the data type of the Variable is specified as an ActualType, the actual data type varies from invocation to invocation, according to the data type of an actual parameter. If the Variable is an InParameter and its formal parameter type is a GeneralizedType, the variable-type is the corresponding ActualType.
Note - See 9.5.4 of ISO 10303-11:2004.
Multiplicity: 1..1
9. In clause 10.3.4, REPLACE the last two sentences of the Definition paragraph:
The values contained in other NamedVariables can change, but only Variables can be the objects of assignments or the referents of VARExpessions (see 13.10). Playing the role VariableCell.referent characterizes Variables.
with:
Variables can be the objects of assignments or the referents of VARExpressions (see 13.10), and they have declared or implied data types that constrain their allowable values.
10a. In clause 12.8, replace Figure 43 (Query Expressions) with:
<image=Issue13686-Figure43-Query.png>
10b. In clause 12.8.2, after the first Note, ADD a new Note:
Note - Although QueryVariable is modeled as a subclass of Variable, it is syntactically impossible for a QueryVariable to be the referent of a VariableCell.
10c. In clause 12.8.2.1, in the first paragraph, DELETE "Algorithms::NamedVariable, ", so that the paragraph reads:
Algorithms::Variable
11a. In clause 13.8, replace Figure 53 (REPEAT… Statements), with:
<image=Issue13686-Figure53-RepeatStmt.png>
11b. In clause 13.8.1, in the Definition paragraph, REPLACE the sentence:
the specification for the control variable, if any, for the Repeat statement.
with:
a Variable representing the specification of for the control variable, if any, of the REPEAT statement.
11c. In clause 13.8.1.1, CHANGE "NamedVariable" to "Variable", so that the paragraph reads:
Algorithms::Variable
Actions taken:
March 12, 2009: received issue
July 23, 2010: closed issue
Issue 13687: What is a GenericElement? (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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
Revised Text:
Actions taken:
March 12, 2009: received issue
July 23, 2010: closed issue
Discussion: This is about sorting out syntactic and semantic concepts. The FTF was unable to reach a satisfactory resolution.
Revised Text:
none.
Disposition: Deferred
Issue 13692: AttributeRef/GroupRef:id subsets Expression:text (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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).
Resolution: Merged into Issue 13689
Disposition: See issue 13689 for disposition
Revised Text:
Actions taken:
March 12, 2009: received issue
April 26, 2010: closed issue
June 6, 2011: closed issue
Issue 13698: Two Subtypes of ActualParameter (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1a. In 8.14.1.4, DELETE the paragraph:
From: Expressions::ActualParameter as actual-value
1b; In 8.14.1.4, immediately after the paragraph:
From: Expressions::MemberBinding as member-value
INSERT a new paragraph:
From: Expressions::PassByValue as actual-value
2a. In clause 10.2.4.4, DELETE the paragraph:
none.
and REPLACE it with:
From: Expressions::PassByValue as for-parameter
2b. In clause 10.2.8.4, DELETE the paragraph:
none.
and REPLACE it with:
From: Statements::PassByReference as for-parameter
3. In clause 12.7, REPLACE Figure 42 with:
<image = Issue13698-Figure42-FunctionCalls.png>
4a. In clause 12.7.1, in the Definition paragraph, DELETE the two sentences:
When the corresponding formal Parameter is an InParameter, the actual-value is present - either an instance of an InstantiableType or Indeterminate. When the corresponding formal Parameter is a VARParameter, the actual-value is not present, the actual-reference is present instead.
and REPLACE them with a new paragraph:
ActualParameter is an abstraction of two different parameter-passing mechanisms: PassByValue and PassByReference. When the corresponding formal Parameter is an InParameter, the ActualParameter shall be a PassByValue. When the corresponding formal Parameter is a VARParameter, the ActualParameter shall be a PassByReference.
4b. In clause 12.7.1, immediately before the Note, INSERT a new Note:
Note - PassByValue is described below. PassByReference is defined in the Statements package (a separate compliance point), because it is only used in Procedure Call statements.
4c. In clause 12.7.1, immediately after the Note, INSERT a new paragraph:
Properties: abstract
5. In clause 12.7.1.3, DELETE all of the following:
AssociationEnd: actual-referent To: Statements::VARExpression
Definition: the VARExpression that denotes the referent object to be associated with the formal (VAR) Parameter during the invocation.
Multiplicity: 0..1
Note: The actual-referent association is shown in Figure 48.
AssociationEnd: actual-value To: Core::Expression
Definition: the Expression that specifies the value to be passed for the ActualParameter. When the corresponding formal Parameter is an InParameter (always in a FunctionCall), the actual-value is present. When the corresponding formal Parameter is a VARParameter (only in a ProcedureCall), the actual-value is not present.
Note - See 12.8 of ISO 10303-11:2004.
Multiplicity: 0..1
6a. In clause 12.7.1.3,under AssociationEnd: formal-parameter, in the Definition paragraph, CHANGE
"ParameterBinding applies"
to
"ActualParameter corresponds".
6b. In clause 12.7.1.3, immediately before AssociationEnd: in-FunctionCall, INSERT:
Properties: derived union of PassByValue:for parameter and PassByReference:for parameter.
7. DELETE the entirety of section 12.7.2.5, i.e. all of the following:
12.7.2.5 Rules
Constraint
exists(self->actual-value) XOR exists(self->actual-referent);
An ActualParameter is either a value (expression) or a reference (expression)
Constraint
exists(self->inFunctionCall) XOR exists(self->inProcedureCall);
Every ActualParameter appears in either a FunctionCall or a ProcedureCall
Constraint
IF self->formal-parameter->inout THEN exists(self->actual-referent);
If the corresponding formal-parameter is an VAR parameter, the ActualParameter must be a Reference; if the formal parameter is an InParameter, it must be a value..
Constraint
IF NOT (self->formal-parameter->inout) THEN exists(self->actual-value);
8. Immediately before clause 12.7.3, INSERT a new subsection
[autonumbered below, will be 12.7.3 and renumber existing subsections]:
1.3.5 PassByValue
Definition: An ActualParameter that is passed "by value". At the time of Algorithm invocation, the actual value Expression is evaluated and the resulting value is assigned to the InParameter - the local Variable within the invocation that corresponds to the formal parameter.
1.3.5.1 Supertypes
ActualParameter
1.3.5.2 Attributes
none.
1.3.5.3 Associations
AssociationEnd: actual-value To: Core::Expression
Definition: the Expression that specifies the value to be passed to the InParameter. This is the Expression that is syntactically the actual_parameter when the corresponding formal parameter is an InParameter.
The actual-value shall evaluate to either an instance of an InstantiableType or Indeterminate.
Note - See 12.8 of ISO 10303-11:2004.
Multiplicity: 1..1
AssociationEnd: for-parameter To: Algorithms::InParameter
Subsets: Expressions::ActualParameter:formal-parameter
Definition: the formal parameter to which the actual value is passed.
Note - See 12.8 of ISO 10303-11:2004.
Multiplicity: 1..1
1.3.5.4 Other Roles
none.
9. In clause 13.7, REPLACE Figure 52 (Procedure Call Statement) with:
<image = Issue13698-Figure52-CallStmt.png>
10. In clause 13.7, immediately before 13.7.1, INSERT a new subsection
[autonumbered below, will be 13.7.1 and renumber existing subsections]:
1.3.6 PassByReference
Definition: An ActualParameter that is passed "by reference". At the time of Algorithm invocation, the actual referent VARExpression is evaluated to identify a cell and that cell becomes the referent of the VARParameter during execution of the Algorithm.
1.3.6.1 Supertypes
ActualParameter
1.3.6.2 Attributes
none.
1.3.6.3 Associations
AssociationEnd: actual-referent To: Statements::VARExpression
Definition: the VARExpression that denotes the cell that is to be the referent of the formal VARParameter during the invocation. This is the expression that is syntactically the actual_parameter when the corresponding formal parameter is a VAR Parameter.
Note - See 12.8 of ISO 10303-11:2004.
Multiplicity: 1..1
AssociationEnd: for-parameter To: Algorithms::InParameter
Subsets: Expressions::ActualParameter:formal-parameter
Definition: the formal parameter to which the actual referent is assigned.
Note - See 12.8 of ISO 10303-11:2004.
Multiplicity: 1..1
1.3.6.4 Other Roles
none.
1.3.6.5 Rules
Constraint
exists(self->inProcedureCall);
Every PassByReference appears in a ProcedureCall (not a FunctionCall).
11. In 13.10.5.4, DELETE the paragraph:
From: Expressions::ActualParameter as actual-referent
and REPLACE it with:
From: PassByReference as actual-referent
Actions taken:
March 12, 2009: received issue
July 23, 2010: closed issue
Discussion: The proposed technical change interacts with Issue 13686, which is unresolved. The FTF was unable to reach a satisfactory resolution.
Revised Text:
none.
Disposition: Deferred
Issue 13712: Choose a term for "referent" of VARExpression (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In clause 10.3.3, REPLACE the first two paragraphs:
Definition: A VARVariable represents a "reference" or "pointer" that functions as a reference to a Variable (or part of a Variable) during the execution of an Algorithm.
A VARVariable is a NamedVariable (it has an identifier and a nominal variable-type), but it is not a Variable. Unlike a Variable, it does not itself hold an Instance. Instead, it points to an object (place) that holds an Instance. The object to which a VARVariable refers is called its referent. The referent of a VARVariable can be anything to which a VARExpression (see 13.10.5) can refer. The referent of a VARVariable is fixed at the time the instance of the VARVariable is created.
with the two paragraphs:
Definition: A VARVariable represents a "pointer" that functions as a reference to a "cell" - a Variable, or a part of a Variable - during the execution of an Algorithm.
A VARVariable is a NamedVariable, but it is not a Variable. Unlike a Variable, it does not itself hold an Instance. Instead, it points to a cell that holds an Instance. The cell to which a VARVariable refers is called its referent. The referent of a VARVariable can be anything to which a VARExpression (see 13.10.5) can refer. The referent of a VARVariable is fixed at the time the instance of the VARVariable is created.
2. In clause 13.3.1, REPLACE the Definition paragraph:
Definition: Represents an EXPRESS ALIAS statement. An ALIAS statement introduces a NamedVariable (the alias-variable) to represent the result of a VARExpression (the referent). But the AliasVariable is not a Variable, and the semantics is not assignment; it is rather creation of a VARVariable that is persistently associated with the Variable specified by the VARExpression, over changes in value of that Variable. Within the body of the ALIAS statement, any assignment to the AliasVariable assigns the value to the referent Variable, and any VariableRef that refers to the AliasVariable refers to the current value of that Variable.
with the paragraph:
Definition: Represents an EXPRESS ALIAS statement. An ALIAS statement introduces a NamedVariable (the alias variable) to represent the result of a VARExpression (the referent). The AliasVariable is not a Variable, and the interpretation is not assignment. The ALIAS statement creates a VARVariable that is persistently associated with the cell specified by the VARExpression over changes in the content of that cell during execution of the body. Within the body of the ALIAS statement, any assignment to the AliasVariable assigns the value to the referent cell, and any VariableRef that refers to the AliasVariable refers to the current value in that cell.
3a. In 13.3.1.3, under AssociationEnd: alias-variable, REPLACE the Definition paragraph:
Definition: the Variable that is introduced by the AliasStatement and bound to a Reference.
with the paragraph:
Definition: the AliasVariable that is introduced by the AliasStatement and bound to the :referent.
3b. In 13.3.1.3, under AssociationEnd: referent, CHANGE "(member or component of the) Variable" to "cell"
4. In 13.3.2, in the Definition paragraph, 2nd sentence, CHANGE "(a part of) a Variable" to "cell"
5a. In 13.10.1, REPLACE the first two paragraphs:
Definition: A VARExpression whose referent is an "attribute object" containing the value of one ExplicitAttribute in an EntityValue.
The .referent attribute of the AttributeCell identifies the ExplicitAttribute that characterizes the attribute object. The referent of the .base-entity VARExpression must be an object that holds an EntityValue that has a "slot" for that ExplicitAttribute. That object/slot in the referent of the base-entity is the referent of the AttributeCell VARExpression.
with the two paragraphs:
Definition: A VARExpression whose referent is a cell (or "slot") containing the value of one ExplicitAttribute in an EntityValue or PartialEntityValue.
The referent of the :base-entity VARExpression shall be a cell that holds an EntityValue or PartialEntityValue that has a "slot" for the ExplicitAttribute that is the :referent of the AttributeCell. The cell/slot in the referent of the :base-entity that corresponds to that ExplicitAttribute is the referent of the AttributeCell.
5b. In 13.10.1.3, under AssociationEnd: base-entity, REPLACE the Definition paragraph:
Definition: the Expression that identifies the object that contains the EntityValue that contains an object representing the ExplicitAttribute that is the referent of the AttributeCell.
with the paragraph:
Definition: the VARExpression that identifies the cell that contains the EntityValue or PartialEntityValue that contains the referent of the AttributeCell.
6a. In 13.10.2, REPLACE the first two paragraphs:
Definition: A VARExpression whose referent is the group of objects/slots for the ExplicitAttributes that constitute a SingleEntityType in an object that holds an EntityValue.
The .referent attribute of the GroupCell identifies the SingleEntityType that characterizes the attribute group. The referent of the .base-entity VARExpression must be an object that holds an EntityValue that has "slots" for the ExplicitAttributes constituting that SingleEntityType. Those slots in the referent of the base-entity constitute the referent of the GroupCell VARExpression.
with the two paragraphs:
Definition: A VARExpression whose referent is the group of cells (or "slots") for the ExplicitAttributes that constitute a SingleEntityType within a cell that holds an EntityValue.
The referent of the :base-entity VARExpression shall be a cell that holds an EntityValue or PartialEntityValue that includes a SingleEntityValue for the SingleEntityType that is the :referent of the GroupCell. The group of cells/slots in the referent of the :base-entity that corresponds to that SingleEntityType is the referent of the GroupCell.
6b. In 13.10.2.3, under AssociationEnd: base-entity, REPLACE the Definition paragraph:
Definition: the Expression that identifies the object that contains the EntityInstance or EntityValue that contains a collection of ExplicitAttribute objects representing the SingleEntityType to which the GroupCell refers.
with the paragraph:
Definition: the VARExpression that identifies the cell that contains the EntityValue or PartialEntityValue that contains the referent of the GroupCell.
7a. In 13.10.3, REPLACE the Definition paragraph:
Definition: A VARExpression that represents a reference to a member (object) of an object whose datatype is an aggregation data type. The aggregate object is the referent of the .base-aggregate VARExpression. The referent of the MemberCell VARExpression is the member object that is designated by the index or position value that is the result of the .index-value Expression.
with the two paragraphs:
Definition: A VARExpression that represents a reference to a cell that is a member of a cell whose datatype is an aggregation data type.
The cell that is the referent of the :base-aggregate VARExpression shall have a datatype that is an aggregation data type. The referent of the MemberCell is the member of that cell that is designated by the index or position value that is the result of the :index-value Expression.
7b. In 13.10.3.3, under AssociationEnd: base-aggregate, REPLACE the Definition paragraph:
Definition: the Expression that identifies the aggregate object in which the referenced member object appears.
with the paragraph:
Definition: the VARExpression that identifies the aggregate cell that contains the referent member cell.
7c. In 13.10.3.3, under AssociationEnd: index-value, CHANGE both occurrences of "object" to "cell", so that the paragraph reads:
Definition: the index or position value used to identify the member cell within the aggregate cell.
8. In 13.10.4.3, under AssociationEnd: refers-to, REPLACE the Definition paragraph:
Definition: the formal InParameter that is the referent object, or the formal VARParameter whose referent is the referent object.
with the paragraph:
Definition: the AliasVariable or VARParameter whose referent is the referent of the AliasRef.
9. In 13.10.5, REPLACE the Definition paragraph and the following bullet list:
Definition: an Expression that refers to an object that contains a value. Unlike Primary Expressions, Index Expressions and Selector Expressions, which are similar in structure, a VARExpression formally refers to the object (place) that holds an Instance, rather than the Instance itself. The object to which a VARExpression refers is called its referent. Every referent object has a data type, but the type of the VARExpression that refers to it is "reference to object with" that data type. The referent object can be:
- a LocalVariable
- an InParameter or FunctionResult
- a member of an AggregationType that is, or is part of, the content model of another object
- an ExplicitAttribute of an EntityType that is the content model of another object
- a SingleEntityType that is part of the content model of another object
- an ExplicitAttribute of an EntityInstance that is the value of another object
- a SingleEntityType that represents a set of ExplicitAttributes of an EntityInstance that is the value of another object.
- the object that is the referent of an AliasVariable or a VARParameter.
with the following:
Definition: an expression that refers to a cell - a place - that contains a value.
Unlike Primary Expressions, Index Expressions and Selector Expressions, which are similar in structure, a VARExpression formally refers to the cell that holds an Instance, rather than to the Instance itself. The cell to which a VARExpression refers is called its referent. The type of a VARExpression is "reference to cell containing" the data type of the referent cell. The referent of a VARExpression can be:
- a LocalVariable
- an InParameter or FunctionResult
- a member of a cell whose data type is an AggregationType
- an ExplicitAttribute slot in a cell that contains an EntityValue or PartialEntityValue
- the cells that contain a SingleEntityValue in a cell that contains an EntityValue or PartialEntityValue
- the cell that is the referent of an AliasVariable or a VARParameter.
10. In 13.10.6, in the Definition paragraph, 2nd sentence, CHANGE "object" to "cell", so that the sentence reads:
The referent of the VariableCell VARExpression is the cell that instantiates…
Actions taken:
March 12, 2009: received issue
July 23, 2010: closed issue
Discussion: The FTF was unable to reach a satisfactory resolution. This relates to the definition of Variable, which is part of Issue 13686.
Revised Text:
none.
Disposition: Deferred
Issue 14047: Correct reference to ISO 10303-11 (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: Correct the Notes.
Revised Text: 1. In 8.9.1.3, in the Note under AssociationEnd: lower-bound, CHANGE "8.2.x" to "8.2.2, 8.2.3 and 8.2.4".
2. In 8.9.1.3, in the Note under AssociationEnd: upper-bound, CHANGE "8.2.x" to "8.2.2, 8.2.3 and 8.2.4".
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14048: Fix derivation on EnumerationType:values (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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).
Resolution: 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
Revised Text:
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14049: EXPRESS MM Issue - Missing subsets documentation (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In 8.4.16.2, immediately after AssociationEnd: local-elements, INSERT:
subsets: Scope:named-elements
2. In 8.4.17.2, immediately after AssociationEnd: schema-elements, INSERT:
subsets: Scope:named-elements
3. In 8.4.21.1, immediately after AssociationEnd: type-elements, INSERT:
subsets: Scope:named-elements
4. In 8.4.21.1, immediately after AssociationEnd: namespace, INSERT:
subsets: NamedElement:namespace
5. In 8.4.21, immediately before the existing 8.4.21.1, insert a new subsection (to become 8.4.21.1):
1.3.6.6Supertypes
element-defined-in-scope
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14050: Define SpecializedType (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In clause 8.6.6, at the end of the Definition paragraph, ADD:
"- a data type that has as its domain a set of named values"
so that the paragraph reads:
Definition: a DefinedType representing an EXPRESS defined data type whose underlying_type is a ENUMERATION data type - a data type that has as its domain a set of named values.
2. In clause 8.6.10, at the end of the Definition paragraph, ADD:
"- a data type that has as its domain the union of the domains of a specified set of named data types"
so that the paragraph reads:
Definition: a DefinedType representing an EXPRESS defined data type whose underlying_type is a SELECT data type - a data type that has as its domain the union of the domains of a specified set of named data types.
3. In clause 8.6.11, DELETE the first Note:
Note - Definition: See 8.2.2, 8.2.3, and 8.2.4 of ISO 10303-11:2004.
and REPLACE it with the two paragraphs:
Definition: a DefinedType representing an EXPRESS defined data type whose underlying_type is neither an explicit ENUMERATION data type nor an explicit SELECT data type. According to ISO 10303-11 clause 9.1, a SpecializedType represents an abstract data type whose values are represented by values of the underlying_type; but in practice, a SpecializedType may also simply name an underlying_type that is an AnonymousType, or name an underlying_type whose domain is a subset of the domain of another DefinedType.
Note - See 9.1 of ISO 10303-11:2004.
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14051: Obsolete Note in 8.13 (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary: In 8.13, the Note before Figure 15 refers to a feature that is no longer present in the diagram. Delete the Note.
Resolution: The issue is correct. Delete the Note.
Revised Text: In clause 8.13, DELETE the first Note paragraph:
Note - The "implicit" association entity-plays-role in Figure 15 is used to represent the two associations entity-plays-domain-role (see 8.12.6) and entity-plays-range-role (see 8.12.7) without further cluttering the diagram. It is not a part of the model.
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14052: complete fixes for Issue 13916 (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. CHANGE all occurrences of ".namespace" to ":namespace"
2. CHANGE all occurrences of ".named-elements" to ":named-elements"
3. CHANGE all occurrences of ".type-elements" to ":type-elements"
4. CHANGE all occurrences of ".local-elements" to ":local-elements"
5. CHANGE all occurrences of ".constraints" to ":constraints"
6. CHANGE all occurrences of ".id" to ":id"
7. CHANGE all occurrences of ".evaluation" to ":evaluation"
8. CHANGE all occurrences of ".text" to ":text"
9. In 8.7.2, in the paragraph beginning "The EXPRESS domain rule wr1…":
a. CHANGE ".position" to ":position"
b. CHANGE ".asserts" to ":asserts"
10a. In 8.11.5.3, under AssociationEnd: models-role, in the Definition paragraph, CHANGE "(models-role.in-relationship)" to
"(models-role:in-relationship)"
10b. In 8.12.9.1, under AssociationEnd: models-role, in the Definition paragraph, CHANGE "(models-role.in-relationship)" to
"(models-role:in-relationship)"
11. In 8.12.1.3, under AssociationEnd: domain, in the Definition paragraph, DELETE the text:
"Derivation: .domain = .in-relationship.range.domain-view.of-entity."
so that the paragraph reads:
Definition: represents the (single) entity data type common to all instances that play the Domain Role.
12. In 8.12.7.1, under AssociationEnd: range, in the Definition paragraph, DELETE the text:
Derivation: .range = .domain-view.attribute-type.
so that the paragraph reads:
Definition: represents the (single) entity data type common to all instances that play the Range Role.
13. In 12.3.6.3, under AssociationEnd: refers-to, at the end of the Definition paragraph, CHANGE ".." to ".".
14. In 12.9.2,
a. in the Definition paragraph, insert a paragraph break after the first sentence.
b. in the last sentence of the (new) paragraph, CHANGE "The .position" to "The :position".
c. Change the paragraph beginning "Note: " to a Note.
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14053: Clarify rule for SupertypeRule:id (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: Clarify/correct the rule specified in the last sentence of the Definition per clause 9.7 of ISO 10303-11.
Revised Text: In 11.3.4, DELETE the last sentence of the Definition paragraph:
A supertype-clause cannot have a ScopedId; a SUBTYPE_CONSTRAINT can have a ScopedId, but is not required to.
and INSERT two new paragraphs immediately after the Definition:
A SupertypeRule shall have an :id value if and only if it represents an EXPRESS SUBTYPE_CONSTRAINT.
Note - This rule reflects the EXPRESS syntax. An EXPRESS supertype-clause has no identifier. An EXPRESS SUBTYPE_CONSTRAINT is required to have an identifier.
Actions taken:
July 1, 2009: received issue
July 23, 2010: closed issue
Issue 14068: Distinguishing instances of AGGREGATEType (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: (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
Revised Text:
Actions taken:
July 10, 2009: received issue
July 23, 2010: closed issue
Issue 14069: EXPRESS MM Issue: ActualType doesn't have a namespace (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: (Note: These changes also require changes to Figure 32 and Figure 57, but those figures are replaced by the resolution of Issues 14194 et al.)
1. In clause 8.6.1.1, in the first paragraph, DELETE the text " , LocalElement", so that the paragraph reads:
Variable.
2a. In 8.6.1.3, under AssociationEnd: scope, DELETE the second paragraph:
Subsets: Core::LocalElement.namespace
2b. In 8.6.1.3, under AssociationEnd: scope, DELETE the 5th paragraph:
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.
and REPLACE it with a new paragraph:
An ActualType does not have a namespace; it defines no identifiers. The :scope of the ActualType represents the ownership of the ActualType and the lifetime of the ActualType.
3a. In clause 10.4.14, DELETE subsection 10.14.4.1 in its entirety:
10.4.14.1 Supertypes
Core::local-element-has-local-scope
3b. In (existing) 10.4.14.2, under AssociationEnd: scope, DELETE the second paragraph:
Subsets: Core::LocalElement.namespace
3c. In (existing) 10.4.14.2, under AssociationEnd: scope, after the Definition paragraph, ADD a Note:
Note - An ActualType does not have a namespace; it defines no identifiers. The :scope of the ActualType represents the ownership of the ActualType and the lifetime of the ActualType.
Actions taken:
July 10, 2009: received issue
July 23, 2010: closed issue
Issue 14070: EXPRESS MM Issue: Rename GenericElements (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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".
Resolution: 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
Revised Text:
Actions taken:
July 10, 2009: received issue
July 23, 2010: closed issue
Issue 14071: EXPRESS MM issue: Correct definition of E (express-ftf)
Click here for this issue's archive.
Source: THALES (Mr. Hugues Vincent, hugues.vincent(at)thalesgroup.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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).
Revised Text: In clause 9.8.2, DELETE the Definition paragraph:
Definition: Represents the REAL value that is the image of 1 under the Napierian exponential function.
and REPLACE it with:
Definition: Represents the unique REAL number e such that the area above the x-axis and below the curve 1/x, for 1 £ x £ e, is exactly 1.
Actions taken:
June 23, 2009: received issue
July 23, 2010: closed issue
Issue 14072: EXPRESS MM issue: Definition of Instance (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: Clarify the definition of Instance to refer to the domains of data types.
Revised Text: 1. In 8.14.2, DELETE the Definition paragraph:
Definition: represents any real or conceptual object, information unit or data item.
and REPLACE it with:
Definition: an object that is in the domain of a DataType - any real or conceptual object, information unit or data element.
2. In 9.2.1, DELETE the Definition paragraph:
Definition: represents any real or conceptual object, information unit or data item.
and REPLACE it with:
Definition: an object that is in the domain of a DataType - any real or conceptual object, information unit or data element.
Actions taken:
July 13, 2009: received issue
July 23, 2010: closed issue
Issue 14073: EXPRESS MM Issue: Definition of Constant (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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
Revised Text: 1. In Clause 9.6, REPLACE the first paragraph:
This section defines the Constant concept. A Constant is a named instance that is explicitly declared in the schema. 9.6 depicts the model of Constants. The Constant class and its properties are described below.
with:
This section defines the Constant concept. A Constant is a model element that provides a name for an instance of any data type, and allows the instance it names to be specified as the value of an Expression. Figure 27 depicts the model of Constants. The Constant class and its properties are described below.
2. In clause 9.6, REPLACE Figure 27 with:
<image=Issue14073-Figure27-Constants.png>
3. In clause 9.6.1, REPLACE the Definition paragraph:
Definition: a CommonElement denoting a single instance value throughout each of its life cycles.
with the two paragraphs:
Definition: a CommonElement that denotes a single instance value throughout each of its life cycles. The instance value is described by an Expression that evaluates to the value to be used in each instantiation of the Constant.
For a Constant that is defined as a SchemaElement, the value is unchanged across all algorithms and rules, and over all corresponding populations. It is a constant and names a specific Instance. Its :value expression may only refer to Instances and other Constants. A Constant defined in an AlgorithmScope, however, assumes a value for a given invocation of the Algorithm or Rule, but may assume different values for different invocations. Its :value expression may refer to parameters of the Algorithm or to elements of the population.
4. In clause 9.6.1.3, under AssociationEnd:actual-value, after the Multiplicity paragraph, ADD 3 paragraphs:
Properties: derived
Tagged Values
derivation = self->value-expression->evaluation;
Actions taken:
July 13, 2009: received issue
July 23, 2010: closed issue
Issue 14074: EXPRESS MM Issue: Built-in constants are Constants (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
--
Resolution: 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).
Revised Text: 1. In 9.3 (SimpleValues), REPLACE Figure 23 with:
<image=Issue14074-Figure23-SimpleValues.png>
2. In the title of subclause 9.8 (NamedValues), CHANGE the text "NamedValues" to the text "BuiltInConstants".
3. In 9.8, DELETE the second Note paragraph:
Note - The built-in constants are also modeled as Literals in Clause 12.11, i.e., as the Expressions that refer to these values.
4a. In 9.8, REPLACE Figure 29 with:
<image=Issue14074-Figure29-BuiltInConstants.png>
4b. In 9.8, REPLACE the caption for Figure 29:
Figure 29 - Named Values
with
Figure 29 - Built-In Constants
5. In 12.3 (Primaries), REPLACE Figure 38 with:
<image=Issue14074-Figure38-Primaries.png>
6. In 12.3.5 (Literals), after the first Note paragraph, ADD a new Note paragraph:
Note - References to the built-in constants - E, PI, TRUE, FALSE, UNKNOWN - are considered to be Literals whose :text is the keyword.
7. In 12.3.5.3, under AssociationEnd: refers-to, after the Definition paragraph add two new paragraphs:
Multiplicity: 0..1
Note - Although every Literal refers to exactly one SimpleValue, it is not usually necessary to instantiate either the SimpleValue or the relationship.
8. DELETE subclause 12.11 (Instance Package: BuiltInConstants) in its entirety, all text, figures and subclauses.
Actions taken:
July 13, 2009: received issue
July 23, 2010: closed issue
Issue 14076: EXPRESS MM Issue: (more) Missing subsets documentation (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: The diagrams are correct. The documentation should be corrected to show the subsets relationships.
Revised Text: 1. In 8.11.3.3, under AssociationEnd: unique-rules, immediately before the Definition paragraph insert:
Subsets: NamedType:type-elements
2a. In 10.2.11.2, under AssociationEnd: namespace, immediately before the Definition paragraph insert:
Subsets: LocalElement:namespace
2b. In 10.2.11.2, under AssociationEnd: result, immediately before the Definition paragraph insert:
Subsets: LocalScope:local-elements
3a. In 10.3.5.2, under AssociationEnd: namespace, immediately before the Definition paragraph insert:
Subsets: LocalElement:namespace
3b. In 10.3.5.2, under AssociationEnd: variables, immediately before the Definition paragraph insert:
Subsets: LocalScope:local-elements
Actions taken:
July 13, 2009: received issue
July 23, 2010: closed issue
Issue 14077: EXPRESS MM Issue: correct definition of StringValue:of-type (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
Summary: In 9.3.9.3, the references to BinaryType and BinaryValue should be to StringType and StringValue.
Resolution: Correct the references.
Revised Text: In 9.3.9.3, under AssociationEnd of-type, DELETE the Definition paragraph,
Definition: the BinaryType(s) that are instantiated in the BinaryValue.
and REPLACE it with:
Definition: the StringType(s) that are instantiated in the StringValue.
Actions taken:
July 13, 2009: received issue
July 23, 2010: closed issue
Issue 14082: The EntityType class has two properties with the same name 'attributes' (express-ftf)
Click here for this issue's archive.
Source: TopQuadrant (Mr. David Price, dprice(at)topquadrant.com)
Nature: Uncategorized Issue
Severity:
Summary: The EntityType class has two properties with the same name -
'attributes'.
Proposed Resolution: Rename one of the properties.
Resolution: 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.
Revised Text: There is no change to the text of the specification. The error will be corrected in the CMOF file.
Actions taken:
July 23, 2010: closed issue
Discussion:
Issue 14136: EnumerationItem has no name (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: issue withdrawn by submitter
Revised Text:
Actions taken:
July 28, 2009: received issue
July 28, 2009: closed issue
July 23, 2010: closed issue
Discussion: The issue was withdrawn by the submitter. In any case, EnumerationItem is a subclass of NamedElement and inherits the 'id: ScopedId' attribute, as shown in Figure 20, and it is mandatory per the rule in 9.2.3.5.
Revised Text:
none.
Disposition: Resolved, No change
Issue 14164: Singleton is not supported by CMOF (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In clause 8.14, REPLACE Figure 16 with:
<image=Issue14164-Figure16-Basics.png>
2a. In 8.14.2.3, under AssociationEnd: of-type, in the Definition paragraph, at the beginning of the second sentence, INSERT:
"With the exception of the Indeterminate Instance (see 9.2.9), "
so that the sentence reads:
"With the exception of the Indeterminate Instance (see 9.2.9), every modeled Instance instantiates …"
2b. In 8.14.2.3, under AssociationEnd: of-type, REPLACE the Multiplicity paragraph:
Multiplicity: 1..*
with
Multiplicity: 0..*
3. At the end of clause 8.14.2, immediately before clause 8.15, INSERT a new subclause (to be 8.14.2.5):
1.3.6.6 Rules
Constraint (OCL): datatype-required
self = INDETERMINATE or exists(self->of-type);
Every Instance except INDETERMINATE has at least one data type.
4. In Clause 9.2, REPLACE Figure 19 (Instances) with:
<image=Issue14164-Figure19-Instances.png>
5. In Clause 9.2.4, DELETE the first two paragraphs:
Stereotypes: Singleton
Definition: Represents the class containing only the "indeterminate" value (?), which represents "no value" or no meaningful value. This value arises primarily as the evaluation of an Expression in which one of the operations "fails." Indeterminate is not clearly an instance of any data type, or of all data types.
and REPLACE them with:
Definition: The class that contains only the INDETERMINATE object (see 9.2.9).
6. At the end of Clause 9.2.4, immediately before 9.2.5, INSERT a new subclause, to be 9.2.4.5:
1.3.6.7 Rules
Constraint (OCL): is-singleton
self = INDETERMINATE;
The only instance of Indeterminate is the INDETERMINATE object.
7. At the end of Clause 9.2, immediately before 9.3, INSERT a new subclause, to be 9.2.9:
1.3.7 Instance: INDETERMINATE
Type: Instances::Indeterminate
Definition: Represents the EXPRESS "indeterminate" value, which is interpreted as "no determinable value".
This Instance arises as the evaluation of an Expression that is the Indeterminate literal ("?"), or an Expression in which one of the operations "fails". Indeterminate is not an instance of any data type, but it may be treated as an instance of the required data type of the Expression, if any.
Note - See clause 14.2 of ISO 10303-11:2004.
8a. In clause 12.3.4, REPLACE the Definition paragraph:
Definition: a Primary Expression consisting of the symbol ("?") that denotes the Indeterminate value.
with the paragraph:
Definition: a Primary Expression consisting of the symbol "?", which always evaluates to the INDETERMINATE value (see 9.2.9).
8b. In clause 12.3.4.3, DELETE the 3 paragraphs:
AssociationEnd: refers-to To: Instances::Indeterminate
Subsets: Core::Expression:evaluation
Definition: represents the fact that the IndeterminateRef refers to the single Indeterminate value. This relationship specializes Expression.evaluation.
and REPLACE them with the paragraph:
none.
Actions taken:
July 30, 2009: received issue
July 23, 2010: closed issue
Issue 14184: EXPRESS MM Issue -- Contradictory InterfacedElement rules (express-ftf)
Click here for this issue's archive.
Source: Eurostep Group AB (Mr. Phil Spiby, phil.spiby(at)eurostep.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. In clause 8.4, REPLACE Figure 2 and its title:
<figure>
Figure 2 Scopes and schemas
with:
<image=Issue14184-Figure2-Schemas.png>
Figure 2 Schemas and Interfacing
2a. In clause 8.4.3, DELETE the 2nd paragraph:
Each interface statement explicitly or implicitly includes zero or more SchemaElements from the interfaced Schema in the interfacing Schema. Each SchemaElement that is explicitly interfaced by the statement shall be represented by exactly one InterfacedElement that is included in the Interface. Each SchemaElement that is implicitly interfaced by the statement shall be represented by at least one InterfacedElement that is included in some Interface between the interfacing Schema and the interfaced Schema.
and REPLACE it with two paragraphs:
Each EXPRESS interface statement (USE or REFERENCE) explicitly includes zero or more SchemaElements from the interfaced Schema in the interfacing Schema. Each interface statement shall be represented by an Interface object with the corresponding :kind. If there are multiple interface statements of the same kind for the same interfaced schema, they may all be represented by a single Interface object of that kind. Each SchemaElement that is explicitly interfaced by the statement(s) shall be represented by exactly one InterfacedElement that is included in the Interface. Such elements are considered to be in the namespace of the interfacing Schema as well, but the identifier in the interfacing schema may be overridden in the InterfacedElement.
In addition, an EXPRESS interface statement may implicitly interface zero or more SchemaElements from the interfaced Schema in the interfacing Schema, in order to complete the specifications of the explicitly interfaced elements. For each interfaced schema from which one or more SchemaElements are implicitly interfaced, the interfacing Schema shall also contain one Interface object that has :kind=IMPLICIT, and that includes one InterfacedElement for each implicitly interfaced element from that interfaced Schema. Implicitly interfaced elements are not considered to be in the namespace of the interfacing schema, but they may appear in a corresponding population.
2b. In clause 8.4.3, between the two existing Notes, INSERT a new Note:
Note - The above requires an interfaced element that is both USEd and REFERENCEd in the same interfacing schema to have two corresponding InterfacedElements, one in each of the Interface objects corresponding to the two kinds of interface statements.
2c. In clause 8.4.3, in the last sentence of the second Note, CHANGE "at least one appropriate Interface" to "an Interface whose kind is implicit" so that the sentence reads:
But SchemaElements that are implicitly interfaced at least once and are not explicitly interfaced at all must be modeled by InterfacedElements that are included in an Interface whose kind is implicit.
3. In clause 8.4.3.2, DELETE the entire entry for Attribute: isUSE:
Attribute: isUSE To: MOF::Boolean
Definition: True if the EXPRESS interfacing statement is USE; False otherwise.
The interpretation of USE is that Instances of every NamedType that is explicitly interfaced by the statement are permitted to be "independent entities" in a Population governed by the interfacing Schema. When the interfacing statement is REFERENCE, Instances of interfaced NamedTypes exist in a Population only to fulfill some Attribute of an entity that is ultimately dependent on an "independent entity".
Note - See clause 11.1 of ISO 10303-11:2004.
Multiplicity: 1..1
and REPLACE it with the following 3 paragraphs:
Attribute: kind To: InterfaceKind
Definition: The nature of the interface, as indicated by the interface statement the Interface represents: USE, REFERENCE, implicit.
Multiplicity: 1..1
4. In clause 8.4.4, DELETE the last sentence of the Definition paragraph, which reads:
Because a given schema can only interface a given SchemaElement once, the combination (.interfacing-schema, .refers-to) uniquely identifies an InterfacedElement relationship.
and REPLACE it with:
Each InterfacedElement is contained in exactly one Interface, which models one or more interface statements of the same kind for the interfaced schema. Because it is not meaningful for an interface statement to interface the same SchemaElement more than once, the combination (:included-in, :refers-to) uniquely identifies an InterfacedElement relationship.
5. In clause 8.4.4.2, DELETE the entry for Attribute: isImplicit in its entirety:
Attribute: isImplicit To: MOF::Boolean
Definition: True if the InterfacedElement represents an implicit interface of the SchemaElement it refers-to, that is, no identifier for the SchemaElement is introduced into the namespace of the interfacing Schema; and False otherwise.
Note - See clause 11.4 of ISO 10303-11:2004. Note that if a SchemaElement is interfaced by an InterfaceElement in which isImplicit = TRUE, no InterfaceElement of the .interfacing-schema in which isImplicit = FALSE refers-to the same SchemaElement.
Multiplicity: 1..1
and REPLACE it with:
Attribute: kind To: InterfaceKind
Definition: the nature of the interface that is represented by the InterfacedElement: USE, REFERENCE, implicit. It is derived from the kind of Interface it is included in.
Multiplicity: 1..1
Properties: derived.
derivation = self->included-in->kind
6. Immediately before clause 8.4.5 (LocalElement), INSERT a new subclause (autonumbered below, to be 8.4.5 and renumber the following subclauses):
1.3.8 Datatype: InterfaceKind
Stereotype: enumeration
Definition: The nature of an Interface - the EXPRESS interface relationship between two Schemas.
1.3.8.1 Supertypes
none.
1.3.8.2 Values
Value: IMPLICIT
Definition: Represents "implicit" interfacing, as defined in ISO 10303-11. A NamedElement is implicitly interfaced when it is not explicitly interfaced by any USE or REFERENCE statement but is used in the specification of a NamedElement that is explicitly interfaced, or in the specification of another element that is implicitly interfaced. Elements that are implicitly interfaced do not appear in the namespace of the interfacing schema. Instances of implicitly interfaced NamedTypes may appear in a Population governed by that Schema as if they were REFERENCEd.
Value: REFERENCE
Definition: Represents explicit interfacing by a REFERENCE statement. NamedElements that are explicitly interfaced have identifiers in the namespace of the interfacing schema. Instances of NamedTypes that are interfaced by a REFERENCE statement may exist in a Population, but only to fulfill some Attribute of an entity that is ultimately dependent on an "independent entity".
Value: USE
Definition: Represents explicit interfacing by a USE statement. NamedElements that are explicitly interfaced have identifiers in the namespace of the interfacing schema. Instances of every NamedType that is explicitly interfaced by a USE statement are permitted to be "independent entities" in a Population governed by the interfacing Schema.
Actions taken:
August 7, 2009: received issue
July 23, 2010: closed issue
Issue 14185: EXPRESS MM Issue: Repair clause 6 (express-ftf)
Click here for this issue's archive.
Source: NIST (Mr. Edward J. Barkmeyer, edbark(at)nist.gov)
Nature: Uncategorized Issue
Severity:
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.
Resolution: The issue is correct. Clause 6 will be modified to align the stated "conventions" with the actual practice in the specification.
Revised Text: 1. In clause 6, in the bullet list following the 2nd paragraph, DELETE the list item:
o Generalization of associations
2. In clause 6, DELETE the 4th paragraph (beginning "The stereotype <<metaclass>> …") in its entirety.
3. In clause 6, in the 5th paragraph (beginning "MOF 2.0 requires …"), REPLACE the second sentence:
In this specification, all the association names are shown, but the names of unidirectional associations are shown in small type, and the documentation describes only the owned association end.
with:
In this specification, all associations are named (in the UML and CMOF XMI files), but only the names of bidirectional associations are displayed and and only bidirectional associations are separately documented (as Associations).
4. In clause 6, in the 6th paragraph (beginning "Similarly, MOF 2.0 requires …"), at the very end of the paragraph, DELETE the text "(see below)", and after the following period, ADD a sentence:
Every navigable association end is documented as a properties of the owning class.
5. In clause 6, DELETE the last two paragraphs in their entirety:
For derived attributes and associations, the derivation is shown as the tagged-value derivation.
The model specified in this document is available in two XMI forms as well:
o OMG document mantis/2008-02-03 is the UML2 model
o OMG document mantis/2008-02-04 is the CMOF model.
and REPLACE them with:
For derived attributes and associations, the UML model includes an <<isDerived>> stereotype that allows the attachment of the tagged-value "derivation". Wherever the derivation is a simple navigation expression, it is given as the value of "derivation" and documented accordingly in the normative text. Where the derivation is a more complex operation, it is omitted from the UML model and described in the text. The CMOF model does not include the tagged values, but wherever the derivation expression is given in the UML model, the CMOF model contains a Constraint requiring the value of the derived property to be equal to the value of the derivation expression.
Actions taken:
August 7, 2009: received issue
July 23, 2010: closed issue
Discussion:
Issue 14194: Generic_entity usage in Abstract entity not supported (express-ftf)
Click here for this issue's archive.
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: 1. (source: 14070)
1a. In 8.6.1, in the 2nd paragraph, CHANGE four occurrences of "GenericElement" to "ParametricElement".
1b. In 8.6.1.3, under AssociationEnd: scope, in paragraph 4, CHANGE "GenericElement" to "ParametricElement" (Note: Issue 14069 deletes the occurrence in paragraph 5).
2. (source:14068) In Clause 8.10, REPLACE Figure 11 with:
<image=Issue14068-Figure11-GeneralizedTypes.png>
3. (source: 14068, 14070, 14194)
3a. In 8.10.1, after the Definition paragraph, INSERT a paragraph and a Note:
Each syntactic occurrence of AGGREGATE is considered to be a distinct instance of AGGREGATEType, even when the bounds and member-type are the same as those of some other syntactic occurrence, because the corresponding types of the actual parameters or subtype attributes need not be the same. When the structures are required to be the same, that is represented as an ActualStructureConstraint (see 10.5.1).
Note - When the keyword AGGREGATE is followed by an EXPRESS type_label, there are three possible interpretations in the metamodel:
§ A ParametricStructure is being defined to have that type_label (see 10.4.10) and relate to the datatype of the actual parameters or instantiable attributes that correspond to the :source. The datatype, or component of the datatype, of the :source is a new AGGREGATEType. This is the interpretation of the first occurrence of the type_label in a parameter list or entity declaration.
§ An ActualStructureConstraint is being specified (see x.x) that refers to the ParametricStructure with that type_label. The datatype denoted by the occurrence of AGGREGATE:label is a new AGGREGATEType that has that constraint. This is the interpretation of any later occurrence of the type_label in the same parameter list or entity declaration.
§ A new ActualAGGREGATEType is being defined by reference to the ParametricStructure with that type_label (see 10.4.6), and the datatype of the variable, attribute, or member is the ActualAGGREGATEType. This is the interpretation of any other occurrence of the type_label within the same Algorithm.
3b. In clause 8.10.1.3, immediately before the AssociationEnd:lower-bound paragraph, INSERT a new subsection:
AssociationEnd: defines-parameter To: ParametricStructure
via: AGGREGATEType-defines-parameter
Definition: The ParametricStructure, if any, that is defined to refer to the structure of the actual data types that conform to this AGGREGATEType.
Multiplicity: 0..1
4. (source: 14070) In clause 8.10.5, in the first Note, CHANGE "GenericElement" to "ParametricElement"
5. (source: 14068, 14070, 14194)
5a. In clause 8.10.8, in the first sentence of the Definition paragraph, DELETE the text: ", and some labeled instances of them", and INSERT a paragraph break after the sentence, so that the text reads:
Definition: represents the EXPRESS generalized types GENERIC and GENERIC_ENTITY.
Every data type is a specialization …
5b. In 8.10.8, immediately after the first Note paragraph, ADD a new Note:
Note - When the keywords GENERIC and GENERIC_ENTITY are followed by an EXPRESS type_label, there are three possible interpretations in the metamodel:
§ A ParametricType is being defined to have that type_label (see 10.4.9) and relate to the datatype of the actual parameters or instantiable attributes that correspond to the :source. The datatype, or component of the datatype, of the :source is the GenericType. This is the interpretation of the first occurrence of the type_label in a parameter list.
§ An ActualTypeConstraint is being specified (see x.x) that refers to the ParametricType with that type_label. The datatype denoted by the occurrence of GENERIC:label or GENERIC_ENTITY:label is the GenericType but the allowable data types that correspond to it in this usage are constrained by the ActualTypeConstraint. This is the interpretation of any later occurrence of the type_label in the same parameter list.
§ An ActualGenericType is being identified by reference to the ParametricType with that type_label (see 10.4.6), and the datatype of the variable, attribute, or member is the ActualGenericType. This is the interpretation of any other occurrence of the type_label within the same Algorithm.
5c. In 8.10.8.2, DELETE the following 5 paragraphs:
Attribute: isEntity To: MOF::Boolean
Definition: True if the corresponding data type is required to be an Entity data type; False otherwise.
o .isEntity is True if the EXPRESS keyword was GENERIC_ENTITY.
o .isEntity is False if the EXPRESS keyword was GENERIC.
Multiplicity: 1..1
and REPLACE them with one paragraph:
none.
5d. Immediately before 8.11, add a new subsection to 8.10 (to be 8.10.8.5):
1.3.8.3 Rules
Constraint (OCL)
self = GenericTypes::GENERIC OR self = GenericTypes::GENERIC_ENTITY;
6. (source 14194) In clause 8.11.1.1, REPLACE the paragraph
TypeElement
with the paragraph
TypeElement, ElementSource
7. (source: 14068, 14070, 14194)
Immediately before existing Clause 8.14, INSERT two new subclauses
(the text below is autonumbered, but it will become 8.14 and 8.15 and renumber the clauses that follow):
1.4 Parametric Datatype Elements
EXPRESS permits the generalized_type specifications for formal parameters and attributes of abstract entity data types to contain labeled components that refer to specific elements of the data type of the corresponding actual parameters and instantiable entity subtypes. These labeled components are modeled as ParametricElements. In the declarations of other attributes of the abstract entity data type or other parameters of the same Algorithm, ActualTypeConstraints refer to these ParametricElements. In Algorithm bodies, the specifications of data types that are ActualTypes refer to ParametricElements defined in the formal parameter list. Figure 3 depicts the ParametricElement concepts.
<image = Issue14194-FigureNew1-ParametricElements>
Figure 3 Parametric Datatype Elements
Note - In the diagram the model elements that are taken from the Algorithms Package can be ignored if only the Core package is being implemented.
1.4.1 Class: ElementSource
Definition: an Attribute or Parameter. ElementSource reifies the roles of Attribute and Parameter as :source of ParametricElements - the container of their declarations - and as owner of ActualTypeConstraints and ActualStructureConstraints.
Note - InverseAttributes cannot have values for any of the properties of ElementSource - type-parameters, type-constraints, structure-constraints.
Properties: abstract
1.4.1.1 Supertypes
none
1.4.1.2 Attributes
none.
1.4.1.3 Associations
AssociationEnd: structure-constraints To: ActualStructureConstraint
Definition: the ActualStructureConstraints, if any, that constrain the allowable data types of the corresponding actual parameter.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..* unordered
AssociationEnd: type-constraints To: ActualTypeConstraint
Definition: the ActualTypeConstraints, if any, that constrain the allowable data types of the corresponding actual parameter.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..* unordered
AssociationEnd: type-parameters To: ParametricElement
via: element-has-source
Definition: the ParametricElements, if any, whose declarations are contained in the declared type of the ElementSource (Attribute or Parameter).
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..* unordered
1.4.2 Class: ParametricElement
Definition: a NamedElement representing a parametric data type - a component of the type description for an abstract Attribute or a formal Parameter that refers to the corresponding type component of the InstantiableType or the corresponding actual parameter. The ParametricElement is denoted by an EXPRESS type_label that is unique within the scope of the EntityType or Algorithm.
The :id attribute of the ParametricElement represents the EXPRESS type_label.
In EXPRESS entity_declarations, the first occurrence of the type_label among the Attribute declarations defines the ParametricElement. Any later occurrence of the same type_label in the Attribute declarations for the same EntityType (even for the same Attribute) specifies an ActualStructureConstraint or an ActualTypeConstraint that is based on the ParametricElement. The :source property indicates the Attribute whose data type contains the ParametricElement definition.
In EXPRESS Algorithm declarations, the first occurrence of the type_label in the formal parameter list defines the ParametricElement. Any later occurrence of the same type_label in the formal parameter list (even in the same Parameter) specifies an ActualStructureConstraint or an ActualTypeConstraint that is based on the ParametricElement. The :source property indicates the Parameter whose formal parameter type contains the ParametricElement definition.
Note - An EXPRESS type_label is not part of the model of a GenericType or AGGREGATEType; it is an identifier for a ParametricElement that can be used in ActualTypes and ActualTypeConstraints.
Properties: abstract
1.4.2.1 Supertypes
NamedElement
1.4.2.2 Attributes
none.
1.4.2.3 Associations
AssociationEnd: namespace To: Scope
Definition: the EntityType or Algorithm that is the namespace of the ScopedId that is the type_label. This relationship is derived - the namespace of a ParametricElement is the same as the namespace of its :source element (Attribute or Parameter).
Multiplicity: 1..1
Properties: derived.
Note - While the derivation has the conceptual form: self->source->namespace in all cases, each kind of source inherits its namespace association from a different supertype.
AssociationEnd: source To: ElementSource
via: element-has-source
Definition: the ElementSource (Attribute or Parameter) whose declared type is or includes the ParametricElement and defines its type_label. The first (by :position) Attribute or Parameter whose declared type contains the type_label is the source for that ParametricElement and defines the type_label as its :id.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 1..1
1.4.2.4 Other Roles
none.
1.4.3 Class: ParametricStructure
Definition: A syntactic occurrence of AGGREGATE within a formal parameter type or attribute type that defines a type_label. The ParametricStructure is the first occurrence of the label among the Parameters of the Algorithm or the Attributes of the EntityType.
In an Attribute declaration, the ParametricStructure refers to the structure (ARRAY, BAG, LIST, SET) of the corresponding instantiable AggregationType in corresponding Attributes of subtypes. In a Parameter declaration, the ParametricStructure refers to the structure of the corresponding component of the corresponding ActualParameters.
Note - Later occurrences of the type_label in the same Scope are ActualStructureConstraints (see 1.5.1).
Example - In the EXPRESS declaration:
FUNCTION check_properties(inputs: AGGREGATE:ins OF property, selectors: AGGREGATE:ins OF BOOLEAN): BOOLEAN;
the AGGREGATE:ins in the inputs parameter declares both an AGGREGATEType component of the formal-parameter-type of the inputs Parameter and a ParametricStructure that defines the type_label "ins". The :source-structure of the ParametricStructure is that AGGREGATEType.
(The AGGREGATE:ins in the selectors Parameter declares an AGGREGATEType component and an ActualStructureConstraint based on "ins". See 1.5.1.)
1.4.3.1 Supertypes
ParametricElement
1.4.3.2 Attributes
none.
1.4.3.3 Associations
AssociationEnd: source-structure to: AGGREGATEType
via: AGGREGATEType-defines-parameter
Definition: the AGGREGATEType from whose instantiations the ParametricStructure takes its values. That is, the ParametricStructure refers to the structure of the attribute-type or the component of the actual parameter that corresponds to this AGGREGATEType.
Note - the AGGREGATEType is unique and is, or is a component of, the data type of the :source, which is a ParameterType. Since a ParameterType can contain more than one occurrence of AGGREGATE, the intended component of the actual parameter type must be explicitly identified.
Multiplicity: 1..1
1.4.3.4 Other Roles
From: ActualAGGREGATEType as refers-to
From: ActualStructureConstraint as required-structure
1.4.4 Class: ParametricType
Definition: A syntactic occurrence of GENERIC or GENERIC_ENTITY within a formal parameter type or attribute type that defines a type_label. The ParametricType is the first occurrence of the type_label among the Parameters of the Algorithm or the Attributes of the EntityType.
In an EntityType declaration, the ParametricType refers to the corresponding InstantiableType component of each corresponding Attribute. In an Algorithm declaration, the ParametricType refers to the data type of the corresponding component of each corresponding ActualParameter. Since the ElementSource (Attribute or Parameter) contains exactly one component that is a GenericType, the ParametricType is always associated with that component.
Note - The association between the ParametricType and the GenericType component is not modeled, since the GenericType component is not itself modeled (it is simply an occurrence of one of the two objects of GenericType). The association is implied, as stated above, by the (inherited) association to the ElementSource (ParametricElement:source).
Note - Later occurrences of the type_label within the same Scope are ActualTypeConstraints (q.v.).
Note - See ISO 10303-11 clause 9.5.3.4. It also requires that the ParametricType must be based on GENERIC_ENTITY, i.e., that :isEntity must be TRUE, if the :source of the ParametricType is an Attribute.
1.4.4.1 Supertypes
ParametricElement
1.4.4.2 Attributes
Attribute: isEntity to: MOF::Boolean
Definition: True if the ParametricType is based on GENERIC_ENTITY; False if it is based on GENERIC.
Multiplicity: 1..1
1.4.4.3 Associations
none.
1.4.4.4 Other Roles
From: ActualGenericType as refers-to
From: ActualTypeConstraint as required-type
1.4.4.5 Rules
Constraint (OCL):
not (self->source.type = Attribute) or (self->isEntity);
If the source is an Attribute, the ParametricType must be based on GENERIC_ENTITY.
1.4.5 Association: AGGREGATEType-defines-parameter
Definition: represents the relationship between a ParametricStructure and the AGGREGATEType that defines it. The ParametricStructure takes on the structure of the actual parameters that conform to this element of the formal parameter type.
1.4.5.1 Association Ends
AssociationEnd: defines-parameter To: ParametricStructure
Definition: The ParametricStructure, if any, that is defined to refer to the structure of the actual data types that conform to this AGGREGATEType.
Multiplicity: 0..1
AssociationEnd: structure-source To: AGGREGATEType
Definition: the AGGREGATEType from whose instantiations the ParametricStructure takes its values. That is, the ParametricStructure refers to the structure of the attribute-type or the component of the actual parameter that corresponds to this AGGREGATEType.
Note - the AGGREGATEType is unique and is, or is a component of, the data type of the :source, which is a ParameterType. Since a ParameterType can contain more than one occurrence of AGGREGATE, the intended component of the actual parameter type must be explicitly identified.
Multiplicity: 1..1
1.4.6 Association: element-has-source
Definition: represents the relationship between a ParametricElement and the syntactic/semantic element (ElementSource) that contains its definition.
Note - See 9.5.3.4 of ISO 10303-11:2004.
1.4.6.1 Association Ends
AssociationEnd: source To: ElementSource
Definition: the ElementSource (Attribute or Parameter) whose declared type is or includes the ParametricElement and defines its type_label. The first (by :position) Attribute or Parameter whose declared type contains the type_label is the source for that ParametricElement and defines the type_label as its :id.
Multiplicity: 1..1
AssociationEnd: type-parameters To: ParametricElement
Definition: the ParametricElements, if any, whose declarations are contained in the declared type of the ElementSource (Attribute or Parameter).
Multiplicity: 0..* unordered
1.5 Actual Type Constraints
EXPRESS permits the generalized_type specifications for formal parameters to contain labeled generic components that refer to specific elements of the data type of the corresponding actual parameters. These elements can be referred to in the specifications for the data types of other formal parameters. The effect of such a reference is to state a constraint on the data types of the actual parameters that correspond to the formal parameter that contains the reference to the labeled component. This section provides a model for the capture of such constraints, herein called ActualTypeConstraints. The associated concepts are depicted in Figure 3 (in 1.4) and Figure 4.
According to clause 9.5.3.4 of ISO 10303-11, the first occurrence of a labeled component in a parameter type is the defining occurrence and subsequent occurrences are constraining references.
<image = Issue14194-FigureNew2-ActualTypeConstraints.png>
Figure 4 Actual Type Constraints
1.5.1 Class: ActualStructureConstraint
Definition: A constraint on the structure of the ConcreteAggregationType that corresponds to a given AGGREGATEType. The constraint is declared in EXPRESS by a type_label on the AGGREGATE keyword that occurs in the specification of an attribute-type or a formal-paramater-type, but is not the definition of that type_label (cf. ParametricStructure). The requirement declared by the constraint is that the structure of the ConcreteAggregationType that corresponds to the AGGREGATEType that uses the type_label (the :matching-structure, the component in the data type of the corresponding actual parameter or corresponding instantiable attribute) must be the same as the structure referred to by the ParametricStructure that defines the type_label (the :required-structure).
Note - See 9.5.3.4 of ISO 10303-11:2004.
Example - In the EXPRESS declaration:
FUNCTION check_properties(inputs: AGGREGATE:ins OF property, selectors: AGGREGATE:ins OF BOOLEAN): BOOLEAN;
the AGGREGATE:ins in the inputs parameter declares both an AGGREGATEType component of the formal-parameter-type of the inputs Parameter and a ParametricStructure that defines the type_label "ins". The AGGREGATE:ins in the selectors Parameter declares both an AGGREGATEType component of the formal-parameter-type of the selectors Parameter and an ActualStructureConstraint based on "ins". The matching-structure of the ActualStructureConstraint is the AggregateType of the selectors parameter, and the required-structure is the ParametricStructure declared by the inputs parameter.
1.5.1.1 Supertypes
none.
1.5.1.2 Attributes
Attribute: label To: Core::Identifier
Definition: the EXPRESS type_label on the AGGREGATE keyword that denotes the constraint. Any occurrence of the same type_label after the first denotes a constraint.
Multiplicity: 1..1
1.5.1.3 Associations
AssociationEnd: matching-structure To: AGGREGATEType
via: aggregate-has-constraint
Definition: the AGGREGATEType component to which the constraint applies, i.e., the AGGREGATEType that is denoted by the AGGREGATE keyword that uses the type_label.
Multiplicity: 1..1
AssociationEnd: required-structure To: ParametricStructure
Definition: the ParametricStructure that defines the EXPRESS type_label that is used to establish the constraint. The :required-structure defines the required structure (ARRAY, BAG, LIST, SET) of the ConcreteAggregationType that corresponds to the AGGREGATEType that is the :matching structure.
Multiplicity: 1..1
1.5.1.4 Other Roles
From: ElementSource as structure-constraints
1.5.2 Class: ActualTypeConstraint
Definition: a constraint on the InstantiableType that corresponds to a given GenericType component of an attribute-type or a formal-parameter-type. The constraint is declared in EXPRESS by a type_label (the :label property) on a GENERIC or GENERIC_ENTITY keyword that occurs in the specification of the formal-parameter-type, but is not defined there. The requirement declared by the constraint is that the InstantiableType that corresponds to the GenericType component that uses the type_label (the component in the data type of the corresponding actual parameter or corresponding instantiable attribute) must be type compatible with the InstantiableType to that corresponds to the ParametricType that defines the type_label (the :required-type).
If the formal parameter types of additional Parameters of the same Algorithm contain the same type_label, each such occurrence constitutes a distinct ActualTypeConstraint.
The data type of the ElementSource (Attribute or Parameter) that has the ActualTypeConstraint contains exactly one occurrence of a GenericType (GENERIC or GENERIC_ENTITY). That occurrence is the component that is constrained by the ActualTypeConstraint.
Note - See 9.5.3.4 of ISO 10303-11:2004.
1.5.2.1 Supertypes
none.
1.5.2.2 Attributes
Attribute: label To: Identifier
Definition: the EXPRESS type_label on the GENERIC or GENERIC_ENTITY keyword that denotes the constraint. Any occurrence of the same type_label after the first denotes a constraint.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 1..1
1.5.2.3 Associations
AssociationEnd: required-type To: ParametricType
Definition: the ParametricType that defines the EXPRESS type_label that is used to establish the constraint. The ParametricType defines the data type with which the component of the data type of the actual parameter that has the ActualTypeConstraint must be compatible.
Multiplicity: 1..1
1.5.2.4 Other Roles
From: Parameter as type-constraints
1.5.3 Association: aggregate-has-constraint
Definition: the relationship between an AGGREGATE type specification and its ActualStructureConstraint, if any.
1.5.3.1 Association Ends
AssociationEnd: constraint To: ActualStructureConstraint
Definition: the ActualStructureConstraint, if any, that applies to this component of the GeneralizedType specification.
Note - Only an AGGREGATEType that appears in the specification of the data type of a Parameter or an Attribute of an abstract entity data type can have an ActualStructureConstraint. The AGGREGATEType has an ActualStructureConstraint only if it has a syntactic type_label and does not itself define that type_label. See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..1
AssociationEnd: matching-structure To: Core::AGGREGATEType
Definition: the AGGREGATEType component to which the constraint applies, i.e., the AGGREGATEType that is denoted by the AGGREGATE keyword that uses the type_label.
Multiplicity: 1..1
8. (source 14194) In clause 10.2.1.3, under AssociationEnd: type-parameters, DELETE the following 8 paragraphs:
AssociationEnd: type-parameters To: GenericElement
via: element-scope-is-algorithm
subsets: Core::LocalScope:local-elements
Definition: The GenericElements that represent formal parametric types - type designations that may appear in ActualTypes and ActualTypeConstraints and to which ActualDataTypes and ActualStructures will be assigned on each invocation of the Algorithm.
Multiplicity: 0..* unordered.
Properties: derived
Tagged Values
derivation = self->formal-parameters->type-parameters;
9. (source 14194)
9a. In clause 10.2.5.1, REPLACE the paragraph
none
with the paragraph
Core::ElementSource
9b. In clause 10.5.2.3, DELETE all of the following text (the complete entries for three AssociationEnds):
AssociationEnd: type-parameters To: GenericElement
via: element-has-source
Definition: The GenericElements that are contained in the formal-parameter-type of the Parameter and represent formal parametric types - type designations that may appear in ActualTypes and ActualTypeConstraints and to which ActualDataTypes and ActualStructures will be assigned on each invocation of the Algorithm.
Multiplicity: 0..* unordered.
Properties: composite
AssociationEnd: structure-constraints To: ActualStructureConstraint
Definition: the ActualStructureConstraints, if any, that constrain the allowable data types of the corresponding actual parameter.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..* unordered
Properties: composite
AssociationEnd: type-constraints To: ActualTypeConstraint
Definition: the ActualTypeConstraints, if any, that constrain the allowable data types of the corresponding actual parameter.
Note - See 9.5.3.4 of ISO 10303-11:2004.
Multiplicity: 0..* unordered
Properties: composite
10. (source Issue 14194, 14070)
10a. In Clause 10.4, DELETE the 2nd paragraph:
EXPRESS permits the generalized_type specifications for formal parameters to contain labeled generic components that refer to specific elements of the data type of the corresponding actual parameters. These elements can then be referred to in the specifications of data types that are ActualTypes. Figure 32 depicts the binding of ActualTypes to the components of the data types of the formal parameters of the Algorithm.
and REPLACE it with:
EXPRESS permits the generalized_type specifications for formal parameters to contain labeled generic components that refer to specific elements of the data type of the corresponding actual parameters. These labeled components are modeled as ParametricElements (see 1.4). The specifications of data types that are ActualTypes refer to ParametricElements, as shown in Figure 32.
10b. In 10.4, REPLACE (existing) Figure 32 (Actual Types) with:
<image=Issue14194-Figure32-ActualTypes.png>
10c. In 10.4, DELETE Figure 33 and its caption:
<figure>
Figure 33 - ActualType References to Elements of GeneralizedTypes
11. (source 14070)
11a. In 10.4.1, in the 2nd paragraph, CHANGE four occurrences of "GenericElement" to "ParametricElement".
11b. In clause 10.4.2, in the Definition paragraph, CHANGE two occurrences of "ActualStructure" to "ParametricStructure".
11c. In clause 10.4.2.2, under Attribute:label, DELETE the Definition and Note paragraphs:
Definition: Represents the "type_label" on the AGGREGATE type, which is used to associate it with the ActualStructure.
Note: The label on the ActualAGGREGATEType is not a definition of that symbol; it is a reference to the occurrence of that symbol as a label on a component of a formal parameter type that defines the label in the Algorithm namespace and defines what the ActualStructure is. More than one ActualAGGREGATEType can have the same label and refer to the same structure.
and REPLACE them with:
Definition: Represents the EXPRESS type_label on the AGGREGATE type, which is used to associate it with the ParametricStructure that defines that identifier.
Note - The label on the ActualAGGREGATEType is not a definition of that symbol; it is a reference to the occurrence of that symbol as a label on a component of a formal parameter type that defines the label in the Algorithm namespace as the id for a ParametricStructure that defines what the actual structure is for each invocation. More than one ActualAGGREGATEType can have the same label and refer to the same structure.
11d. In clause 10.4.2.3, under AssociationEnd: refers-to, DELETE the subsection heading and Definition paragraphs:
AssociationEnd: refers-to To: ActualStructure
Definition: the AGGREGATEType to which the ActualAGGREGATEType corresponds. When instantiated, the ActualType will use the aggregate structure of the ActualParameter that corresponds to this AGGREGATEType (element).
and REPLACE them with:
AssociationEnd: refers-to To: ParametricStructure
Definition: the ParametricStructure that defines the identifier that corresponds to the :label on the ActualAGGREGATEType. When instantiated, the ActualAGGREGATEType will have the structure of the component of the datatype of the ActualParameter that corresponds to this ParametricStructure.
12. (source 14194) DELETE Clause 10.4.6 in its entirety (Note: this will cause renumbering):
10.4.6 Class: ActualDataType
Definition: A GENERIC or GENERIC_ENTITY type that defines a type_label to refer to the data type of the corresponding component of the .source ActualParameter. That is, a GenericType (component) that is also a GenericElement.
The ActualDataType is the first occurrence of the label among the Parameters of the Algorithm. Later occurrences in Parameters are ActualTypeConstraints (see 10.5).
10.4.6.1 Supertypes
GenericElement , Core::GenericType
10.4.6.2 Attributes
none.
10.4.6.3 Associations
none.
10.4.6.4 Other Roles
From: ActualGenericType as refers-to
From: ActualTypeConstraint as required-type
13. (source 14070, 14068)
13a. In (existing) clause 10.4.7, DELETE the Definition paragraph
Definition: an ActualType that refers to an ActualDataType - the data type of an actual parameter or component of an actual parameter. The .label attribute is used to determine the ActualStructure to which it refers. If the .isEntity attribute is FALSE (the EXPRESS keyword is GENERIC), the actual data type can be any Instantiable data type. If the .isEntity attribute is TRUE (the EXPRESS keyword is GENERIC_ENTITY), the actual data type must be an EntityType.
and REPLACE it with the following two paragraphs:
Definition: an ActualType that refers to a ParametricType - the data type, or the member-type, of an actual parameter.
The :label attribute is used to determine the ParametricType to which it refers.
13b. In (existing) 10.4.7.2, in the entry for Attribute:isEntity, immediately after the Multiplicity paragraph, ADD three paragraphs:
Properties: derived.
Tagged Values
derivation = self->refers-to->isEntity;
13c. In (existing) 10.4.7.2, under Attribute:label, DELETE the Definition and Note paragraphs:
Definition: Represents the "type_label" on the GENERIC or GENERIC_ENTITY type, which is used to associate it with the ActualDataType.
Note: The label on the ActualGenericType is not a definition of that symbol; it is a reference to the occurrence of that symbol as a label on a component of a formal parameter type that defines the label in the Algorithm namespace and defines what the ActualDataType is.
and REPLACE them with the two paragraphs:
Definition: Represents the EXPRESS type_label on the GENERIC or GENERIC_ENTITY keyword, which is used to associate it with the ParametricType that defines that type_label.
Note - The label on the ActualGenericType is not a definition of that symbol; it is a reference to the occurrence of that symbol as a label on a component of a formal parameter type.
13d. In (existing) clause 10.4.7.3, under AssociationEnd: refers-to, DELETE the subsection heading and Definition paragraphs:
AssociationEnd: refers-to To: ActualDataType
Definition: the GenericType to which the ActualGenericType corresponds. When instantiated, the actual type will be the data type of the ActualParameter that corresponds to this GenericType (element).
and REPLACE them with:
AssociationEnd: refers-to To: Core::ParametricType
Definition: the ParametricType that defines the identifier that corresponds to the :label on the ActualGenericType. When instantiated, the actual type will be the (component of the) datatype of the actual parameter that corresponds to this ParametricType.
14. (source 14194) DELETE the existing clauses 10.4.10, 10.4.11, 10.14.12, and 10.4.13 in their entirety (they are revised and moved to clause 8 above):
10.4.10 Class: ActualStructure
Definition: An AGGREGATE type that defines a type_label to refer to the structure (ARRAY, BAG, LIST, SET) of the corresponding component of the corresponding ActualParameter. That is, an AGGREGATEType (component) that is also a GenericElement.
The ActualStructure is the first occurrence of t
Actions taken:
August 18, 2009: received issue
July 23, 2010: closed issue
Issue 14215: EXPRESS MM Issue -- InverseAttribute isUnique property not fully described (express-ftf)
Click here for this issue's archive.
Source: Eurostep Group AB (Mr. Phil Spiby, phil.spiby(at)eurostep.com)
Nature: Uncategorized Issue
Severity:
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.
Resolution: 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.
Revised Text: In clause 8.11.5.2 under Attribute: isUnique, REPLACE the last sentence of the Definition paragraph:
(True if the INVERSE attribute is described as a SET; False if it is described as a BAG.)
with:
(True if the attribute-type of the INVERSE attribute is declared to be an entity data type or a SET; False if it is declared to be a BAG.)
Actions taken:
August 21, 2009: received issue
July 23, 2010: closed issue