CreateAction links to only one classifier. It should be multiple.

Decline

Summary: A synchronous action is defined as a request where the sending
object pauses to wait for results. Synonym: synchronous request [OMA].

1) The OMA is not specific on this issue, but the understanding in
CORBA is that a request is only specific with respect to a thread.

• So, in UML, does the sending object truly pause to wait for results?
• Or is it just a thread of that object that pauses for results?
  (in that case, the definition should be clarified)

2) Another possible interpretation of a synchronous action is that
such a request is always associated with a response (contrarily to
an asynchronous request which has no associated response ?).
The sending object has then an obligation to collect that response.

If that interpretation was true, then synchronous action would
map to both synchronous request and def

Fixed in adopted spec

Subject: Inherited abstract operations

Subclauses: 15.2.4 ClassDefinition, 15.2.16 OperationDefinition

There is currently a constraint for an OperationDefinition that it must owned by a non-abstract class. This isn’t strong enough, because it doesn’t prevent a non-abstract class from inheriting an abstract operation. Instead, there should be a constraint on ClassDefinition that all member operations (owned or inherited) are not abstract.

agreed

Subject: Classifier behavior required for an active class

Subclause: 15.2.1 ActiveClassDefinition

A non-abstract active class must have a classifier behavior, because this is required by StartObjectBehaviorAction

agreed

Subject: Assignment of out parameters in if and switch statements

Subclauses: 14.2.13 ifStatement, 14.2.20 SwitchStatement

According to Subclauses 9.8 and 9.9, it is not permitted to define a new local name in an if statement without an else clause or a switch statement without a default clause. The ifStatementAssignmentsAfter and switchStatementAssignments constraints in Subclauses 14.2.13 and 14.2.22 attempt to enforce this by requiring that the assignments after such if or switch statements be the same as those before the statement. However, this constraint is too strong. An out parameter does not have an assign source before it is first assignment, yet it is already defined as a local name. Therefore, the constraints should be loosened to allow an if statement without an else clause or a switch statement without a default clause to contain the first assignment of an out parameter.

agreed

Subject: Derivation of SequenceOperationExpression::isCollectionConversion

Subclause: 13.2.50 SequenceOperationExpression

In Subclause 13.2.50 SequenceOperationExpression, the derivation for isCollectionConversion should include the requirement that the multiplicity is upper bound is 1.

agreed

Subject: Indexed feature left hand sides

Subclauses: 13.2.18 FeatureLeftHandSide, 13.2.35 NameLeftHandSide

In a FeatureLeftHandSide, if the left-hand side has an index, then the referenced feature must be a sequence (simply being ordered is not enough for the “replace” semantics of indexed assignment). Since a similar constraint is required for a NameLeftHandSide with an index, if the name

disambiguates to a feature, the constraint is probably best handled in a unified way in the LeftHandSide superclass.

To handle this constraint in a unified way in LeftHandSide superclass would probably require adding a derived referent property to be used for it, as well as adding derivations for it in each subclass. It is simpler instead to just add to each subclass the specific constraints necessary to resolve the issue.

Subject: Referent of a signal send

Subclauses: 13.2.3 BehaviorInvocationExpression, 13.2.17 FeatureInvocationExpression

The description of the InvocationExpression::referent property in Subclause 13.2.23 is “The behavior, operation or signal being invoked.” The featureInvocationExpressionReferentDerivation in Subclause 13.2.17 derives this property as the referent of the feature of the FeatureInvocationExpression. The behaviorInvocationExpressionReferentDerivation in Subclause 13.2.3 has derives the referent similarly, in the case that the target name of a BehaviorInvocationExpression disambiguates to a feature reference. However, for a signal send, the feature being referenced will actually be a reception for the signal, not the signal itself. The derivations in Subclauses 13.2.3 and 13.2.17 should be revised to account for this.

The constraint behaviorInvocationExpressionReferentDerivation actually already says “if the target disambiguates to a feature reference, the operation or signal being invoked”, which identifies that, for a signal send, the referent is the signal, not the reception. It is featureInvocationExpressionReferentDerivation that needs to be adjusted.

Subject: Assigned name must not be template binding

Subclause: 13.2.35 NameLeftHandSide

In Subclause 13.2.35 NameLeftHandSide, there needs to be a constraint that the name is not a template binding.

agreed

Subject: InstanceCreationExpression class must not be abstract

Subclause: 13.2.22 InstranceCreationExpression

In Subclause 13.2.22 InstanceCreationExpression there should be a constraint that the class of a constructor operation, or the referent if it is a class or data type, must not be abstract. In the case in which this constraint would be violated, but there is an associated Impl class constructor per Subclause 8.3.12, the referent should be the Impl constructor

agreed

Subject: Error in AssignmentExpression constraints

Subclause: 13.2.2 AssignmentExpression

· In Subclause 13.2.1 AssignmentExpression, the constraint assignmentExpressionSimpleAssignmentTypeConformance should require the type of the right-hand side to conform to the type of the left-hand side, not the other way around.

· The type and multiplicity bounds of a compound AssignmentExpression should be those of the left-hand side, not the right-hand side.

Agreed on the first bullet (except that the reference to 13.2.1 should be to 13.2.2).
On the second bullet, the problem is that the current assignmentExpressionCompoundTypeConformance constraint requires that the left-hand side and the right-hand side have the same type. This works for arithmetic or Boolean operations, but it does not necessarily work for bit string operations (which may have an Integer right-hand side) or shift operations (which require and Integer right-hand side). In all cases, however, the type of the compound assignment will be the type of the left-hand side.
The multiplicity upper bound for a compound assignment is required to always be 1. However, the multiplicity lower bound may be either 0 or 1, as determined by the multiplicity lower bound of the left-hand side.

Subject: AssignmentExpression as a data value update

Subclause: 13.2.2 AssignmentExpression,

· An assignment expression should only be allowed to be a data value update if its left hand side is a feature reference whose primary expression is a local name or parameter name.

· The derivation of the assignment for an assignment expression needs to account for the cases of a data value update and an indexed left hand side.

The deriviation of isDataValueUpdate is such that it is true only in the case mentioned in the first bullet. However, nothing currently prevents assignment to an attribute of a data type where the primary expression of the feature reference is not a local name or parameter. Such an assignment will not be mapped correctly, because it will not be considered a data value update and, so, the updated data value will be lost. Therefore, this case should be disallowed.
In the case of a data value update for an indexed left-hand side, the multiplicity of the new assignment should not be that of the left-hand side (which will be 1) but, rather, should be * (since only a sequence can be indexed).

Subject: Inconsistency on being constructorless

Subclause: 10.5.3.1 Constructors

In Subclause 10.5.3.1 it says that the mapping of default constructors “means that the instantiation of a class defined using Alf textual notation is never ‘constructorless’ as defined in Subclause 8.3.12”. However, later in the same subclause it says “If a class has an explicit constructor definition, then the default constructor is no longer available, even if the defined constructor has a different name than the default constructor.” But if no default constructor is available, and there is no explicit constructor with the name of the class and no arguments, then a constructorless instantiation is possible.

If a class has one or more explicit constructors, then the intent is that instances of the class be created using one of these constructors. Therefore, constructorless instantiation should not be allowed in this case, even if there is no default constructor.

Subject: Constructor in a BehaviorInvocationExpression

Subclause: 13.2.3 BehaviorInvocationExpression

In Subclause 13.2.17, FeatureInvocationExpression contains the constraint featureInvocationExpressionAlternativeConstructor, which constrains the placement of an alternative constructor invocation within the method of a constructor operation. However, the target name of a BehaviorInvocationExpression may also disambiguate to a feature reference to a constructor. If such an invocation is within the method of a constructor operation, then it also needs to be similarly constrained as an alternative constructor invocation (perhaps by moving featureInvocationAlternativeConstructor constraint needs to be moved to the InvocationExpression superclass).

Moving the constraint to the InvocationExpression superclass will not work, because this constraint limits when the referent of a feature invocation is a constructor. However, InstanceCreationExpression is also a subclass of InvocationExpression, and, in this case, the referent actually is supposed to be a constructor.

Therefore, a similar constraint needs to be added to BehaviorInvocationExpression

Subject: @determined should be @determinate

Subclauses: 9.8 if Statement, 9.9 switch Statement, 14.2.13 IfStatement, 14.2.22 SwitchStatement

The @determined annotation on if and switch statements should be @determinate, to correspond to the ConditionalNode attribute isDeterminate.

agreed

Subject: Error in bit string conversion

Subclause: 8.8 Assignment Expressions

In Subclause 8.8 Assignment Expressions, under “Assignability”, the function referenced for bit string conversion should be ToBitString, not ToInteger.

agreed

Subject: SequenceExpressionList::element should be ordered

Subclauses: 8.3.15 Sequence Construction Expressions, 13.1 Overview

Since a SequenceExpressionList represents an ordered list of expressions, clearly SequenceExpressionList::element should be ordered.

agreed

Subject: Error in Data Value Creation Expression

Subclause: 8.3.12 Instance Creation Expressions

In the second paragraph under “Data Value Creation Expression” in Subclause 8.3.12 Instance Creation Expressions, it says “Each argument expression must be to the corresponding attribute…”. This should be “Each argument expression must be assignable to the corresponding attribute…”.

agreed

Subject: Errors in Subclause 8.2

Subclause: 8.2 Qualified Names

· In the example at the end of Subclause 8.2 Qualified Names it says “The standard library class Map has two template parameters, K and V.” Actually, the template parameters are “Key” and “Value”.

· The references to UML specification subclauses in Subclause 8.2 are all off by one (e.g., 7.3.34 instead of 7.3.35 for Namespace) for UML 2.4.

Agreed on the first bullet. On the second bullet, it is actually only references to subclauses with numbers greater than 7.3.28 that are wrong, because the UML 2.4.1 inserted a new Subclause 7.3.29 for LiteralReal.

The Alf standard says
"A return statement may only be used within the definition of a behavior that has a return parameter."
We think it must be allowed to always use a return statement. If the context behavior has no return parameter then no expression should be provided in the return statement.

This is a duplicate of Issue 16419.

The signature of replaceOne is :
replaceOne<T> (in seq: T[*] sequence, in element: T, in newElement: T): T[*] sequence

The direction of parameter “seq” should probably be “inout”.

agreed

Currently, the signature of CollectionFunctions::removeAll is:

removeAll<T> (inout seq: T[*] sequence, in element: T)

According to the associated description, it should probably be (taking into account issue 16426 which requires a return parameter):

removeAll<T> (inout seq1: T[*] sequence, in seq2:T[*] sequence) : T[*] sequence

And the description should also be corrected to read “Remove all elements of seq2 from seq1” (“from” instead of “to”).

agreed

I think there is a typo page 184:

Difference

(in seq1: any[*] sequence,

in seq2: any[*] sequence nonunique):

any[*] sequence

it’s not necessary to show “nonunique” for seq2.

I don’t recall having seen something about that in existing issues (sorry if I missed it). I’ll raise an issue for that.

agreed

Subclause: C.4 Alf Standard Library Collection Classes Implementation

• All the collection implementation classes have an incorrect namespace declaration containing “Collections::CollectionClasses”, rather than just “CollectionClasses”. They also import “Alf::Library::FunctionBehaviors::Collections::CollectionFunctions” rather than “Alf::Library::CollectionFunctions”.
• Return types should not be given on constructors.
• Several classes have destructors that call CollectionImpl<T>::destroy, but CollectionImpl has no such destructor.
• The classes that have multiple specializations have to redefine indistinguishable operations inherited from both classes.
• In C.4.2 CollectionImpl,
o excludesAll and includesAll have seq as their parameter, but incorrectly use the name “element” in their bodies.
o In the first statement of removeOne, “self” is used instead of “this”.
o In the last statement of retainAll, there should not be “()” after “preSize”.
• In C.4.3 OrderedCollectionImpl,
o In the body of addAt, the call to “addAllAt” should be proceeded by “this.”.
o In the body of indexOf, the reference to “indexof” should be “indexOf”.
• In C.4.5 OrderedSet,
o In the body of equals, “OrdredCollcetionImpl” should be “OrderedCollectionImpl”.
o In the body of subOrderedSet, the constructor “OrderedSet” should be “OrderedSet<T>”.
• In C.4.6 Bag, the super constructor call should be to CollectionImpl, not OrderedCollection.
• In C.4.7 List,
o CollectionClasses::Impl::List should specialize CollectionClasses::List, not CollectionClasses::OrderedSet.
o subList should return List<T>, not OrderedSet<T>.
o In subList, the constructor “List” should be “List<T>”.
o The parameter for setContent should be a “sequence”.
• In C.4.8 Queue,
o Queue should specialize CollectionClasses::Queue, not CollectionClasses::Set.
o In the body of removeFirst, “toSequence” should be “toSequence()”.
o removeFirstOne should have a return multiploicity of 1..1.
o The body of removeFirstOne should return the argument element or null, depending on whether the element was actually found for deletion.
• In C.4.9 Deque,
o Deque should specialize CollectionClasses::Deque in addition to Queue.
o The super constructor call should be super.Queue<T>::Queue, not just super, and the super destructor call should be super.Queue<T>::destroy.
o The implementation of removeLastOne removes all occurrences of the given element, not just the last one.
o toSequence cannot return “this.content”, since “content” is private to Queue.
o The (constructor) operation Queue is inherited from both superclasses and must be redefined.

agreed

Subclause: C.3 Property Management Service

• To be consistent with the implementation of ‘create reply’, the association of Property to Location should be optional.

• In the ‘create property’ example, the mandatory ‘property type’ needs to be set in the propertyData instance creation expression.

• In the establish operation, two occurrences of “request.name” should be replaced with “request.’property name’”.

• In the acquire, update, delete and retrieve operations, the reply and error out parameters need to be set to null values before the if statement and the select expressions should have “[1]” at the end.

• In the acquire, update and dispose operations, the reference to ‘Property Type’ should be ‘Property Status’ and the assignment in the second if clause should be equality.

• The update operation needs to import 'Property Management'::'Data Model'::Locations::Location. Also, “request.’property location’” should be “request.’property location identifier’” (three times), “request.’serial number’ “should be “request.’property serial number’” and “request.size” should be “request.’property size’”.

Agreed, except that:
• The second bullet should reference the ‘create reply’ activity (which has a propertyData instance creation expression) rather than ‘create property) which does not.
• In the fifth bullet, the issue with assignment seems to have already been resolved.
Revised Text:

Subclause: C.2 Online Bookstore

• In the example class Order, the statement “accept (OrderDelivery)” should be “accept (OrderDelivered)”. Also, the nested activities have to be operations, because nested activities don’t have the containing class as their context.

• In the example activity EstablishCustomer, “TIM::current_date” should be replaced with “TIM::GetCurrentDate()”.

• The ProcessCharge activity should import Ordering::CreditCardCharge::ChargeData.

• In the graphical model for the Ordering example, the Customer class is shown as having a purchasesMade attribute that is not set in the EstablishCustomer activity, but that activity instead shows a phone attribute being set that is missing from the class.

agreed

Subclause: C.1 Quicksort Activity

In the “functional” QuickSort example:
• x cannot be set only in the else part of an if statement
• The sequence operation “remove” should be “removeAt”
• The recursive call to “QuickSort” should be “Quicksort”.

The first and third bullets are correct. However, the example already uses “removeAt”, not “remove”, so no change is necessary for that.
Note also that Annex C should really be Annex B (since it is the second annex).

Subclauses: Various subclauses in Part III Abstract Syntax

The following constraint names should be corrected as shown:
• expressionAssignmentsAfterDerivation -> expressionAssignmentAfterDerivation
• bitStringUnaryExpresionIsBitStringConversionDerivation -> bitStringUnaryExpressionIsBitStringConversionDerivation
• loopVariableIsCollectionConversionDerivation -> loopVariableDefinitionIsCollectionConversionDerivation
• importedElementNotStub -> importedMemberNotStub
• importedElementFeatureDerivation -> importedMemberIsFeatureDerivation
• forAllOrExistOrOneExpressionTypeDerivation -> forAllOrExistsOrOneExpressionTypeDerivation
• forAllOrExistOrOneExpressionLowerDerivation -> forAllOrExistsOrOneExpressionLowerDerivation
• forAllOrExistOrOneExpressionUpperDerivation -> forAllOrExistsOrOneExpressionUpperDerivation
• forAllOrExistOrOneExpressionArgument -> forAllOrExistsOrOneExpressionArgument
• relationalExpressionIsTypeDerivation -> relationalExpressionTypeDerivation
• relationalExpressionIsLowerDerivation -> relationalExpressionLowerDerivation
• relationalExpressionIsUpperDerivation -> relationalExpressionUpperDerivation
• unboundedLiteralExpressionDerivation -> unboundedLiteralExpressionTypeDerivation
• namespaceDefinitionMemberDistinguishaibility -> namespaceDefinitionMemberDistinguishability
• operationDefinitionIsConstructorDefinition -> operationDefinitionIsDestructorDerivation
• operationDefinitionIsDestructorDefinition -> operationDefinitionIsDestructorDerivation
• operationDefinitionRedefinedOperationsDerivation -> operationDefinitionRedefinedOperationConstraint
• propertyDefinitionIsBitStringConversion -> propertyDefinitionIsBitStringConversionDerivation
• incrementOrDecrementExpressionIsDataValueUpdate -> incrementOrDecrementExpressionIsDataValueUpdateDerivation
• incrementOrDecrementExpressionFeature -> incrementOrDecrementExpressionFeatureDerivation
• incrementOrDecrementExpressionAssignment -> incrementOrDecrementExpressionAssignmentDerivation

agreed

Subclause: 15.2.21 SignalDefinition

The description of SignalDefinition::isSameKindAs mentions “Reception” where it should say “Signal”.

agreed

Subclause: 15.2.19 PropertyDefinition

The propertyDefinitionInitializer constraint should also state that there are no assignments before the initializer expression.

agreed

Subclause: 15.2.16 OperationDefinition

OperationDefinition must take into account that the return type of a constructor is not explicitly declared, but is still included in the operation signature (per Subclause 10.5.3.1).

This needs to be accounted for in the definitions of the isSameKindAs and matchForStub helper operations.

Subclause: 15.2.16 OperationDefinition

In the description of OperationDefinition::operationDefinitionRedefinition, “signal referent” should be “single referent”.

agreed

Subclause: 15.2.15 NamespaceDefinition

NamespaceDefinition::ownedMember association should be ordered. (This is important at least for activity and operation parameters.)

agreed

Subclause: 15.2.12 ImportedMember

• The description of ImportedMember::isSameKind is written in terms of distinguishability rather than same kind.

• An ImportedMember should not generally be considered a feature, even if it is a feature of the namespace it is imported from, since it is not a feature of the namespace it is imported into.

• In the case of Alf members, it is appropriate to use the terminology “same kind”. However, in the case of two UML elements, the standard terminology of distinguishability still needs to be used.
• No change is required for an ImportedMember no be considered a feature. The isFeature property inherited from Member is false by default and the default value is never changed for an ImportedMember.

Subclause: 15.2.8 ElementImportReference

ElementImportReference should have a constraint that its referent must be a packageable element.

agreed

Subclause: 14.2.22

• The description of the switchStatementExpression constraint should be “The expression of a switch statement must have a multiplicity no greater than 1.”

• The description of the switchStatementEnclosedStatements constraint should be “A switch statement is the enclosing statement for the statements in all of its switch clauses.”

• The switchStatementAssignmentsBefore constraint should state that the assignments before the clauses of a switch statement are the assignments after the expression of the switch statement.

agreed

Subclause: 14.2.21 SwitchClause

SwitchClause should have a switchClauseCases constraint the states “All the cases expressions of a switch clause must have a multiplicity no greater than 1.”

agreed

Subclause: 14.2.15

The localNameDeclarationTypeDerivation requires the type of the statement to be the type of the expression if no type name is given. However, this is not correct, since the only way that the type name could be empty is if it is given as “any”, in which case the local name should be untyped.

agreed

Subclause: 13.2.55 SuperInvocationExpression

The superInvocationExpressionImplicitTarget constraint should include the condition that the containing behavior has only a single superclass

agreed

Subclause: 13.2.53 ShiftExpression

The description of the shiftExpressionOperands constraint should say “The first operand expression of a shift expression must have the type BitString or Integer. The second operand expression must have the type Integer.” (per Subclause 8.6.3).

agreed

Subclause 14.2.15 LocalNameDeclarationStatement

The localNameDeclarationStatementAssignmentsAfter constraint states “The assignments after a local name declaration statement are the assignments before the statement plus a new assignment for the local name defined by the statement.” The assignments should be the assignments after the expression of the statement plus the new assignment (so as to include assignments made in the expression).

agreed

Subclause: 14.2.12 for Statements

ForStatement should have a composition association with its body Block.

agreed

Subclause: 14.2.4 Block

• The second sentence of the description of the Block::assignmentAfter derived property mentions “statement” twice when it should say “block”.

• The blockAssignmentsBefore constraint should have the definition “The assignments before the first statement of a block are the same as the assignments before the block.”

agreed

Subclause: 13.2.46 SerquenceConstructionExpression

• SequenceConstructionExpression needs constraints on the type and multiplicity of its sequence elements. However, the rules here (and as stated in Subclause 8.3.15) need to allow for bit string conversion of integer elements for a bit string sequence.

• The description of the sequenceExpansionExpressionVariableSourceDerivation constraint should also state that the type of the assigned source for the expansion variable is the type of the primary expression and the multiplicity bounds are both 1.

• SequenceExpansionExpression needs a constraint that no names defined before the argument expression may be reassigned in the argument expression (per the Semantics in Subclause 8.3.19), not just the expansion variable.

• The description of the sequenceExpansionExpressionListUpperDerivation constraint says “lower bound” when in should say “upper bound”.

Agreed. However, only the first bullet in the issue summary is for Subclause 13.2.46 SequenceConstructionExpression. The second bullet is for 13.2.48 SequenceExpansionExpression. The third bullet is for 13.2.49 SequenceExpressionList (not “SequenceExpansionExpressionList”).

Subclause: 13.2.50 SequenceOperationExpression

• SequenceOperationExpression needs a constraint that a name may not be assigned in both the primary expression and any tuple argument expression.

• SequenceOperationExpression should have a derived association with an optional LeftHandSide that is created in the case of an “in place” operation and must have its constraints satisfied. The sequenceOperationExpressionTargetCompatibility constraint should also require that, for an “in place” operation, the primary expression have the form of a left-hand side and, if for a local name, the local name must already exist.

agreed

Subclause: 13.2.50 SequenceOperationExpression

SequenceOperationExpression should override the parameterElements operation to only return the parameters after the first, since the argument for the first parameter is given by the primary expression not in the tuple.

agreed

Subclause: 13.2.46 SequenceConstructionExpression

SequenceConstructionExpression needs to override updateAssignments. For a sequence expression list, the assignments before each element expression should be the assignment after the previous one and the assignments after the sequence construction expression are the assignments after the last element expression. For a sequence range the assignments before both expressions are the assignments before the sequence construction expression and the assignments after the sequence construction expression are the assignments after the expressions. There should also be a constraint on sequence ranges that the same local name cannot be assigned in both expressions

agreed

Subclause: 13.2.46 SequenceConstructionExpression

The description of the sequenceConstructionExpressionType constraint should make it clear that it is legal for the typeName property to be empty (corresponding to a type name notation of “any”).

agreed

Subclause: 13.2.42 QualifiedName

In the description of qualifiedNameDisambiguationDerivation, “If a qualified name is not ambiguous or it resolves to a namespace…” should be “If a qualified name is not ambiguous or it has a qualification that resolves to a namespace…”

agreed

Subclause: 13.2.42 QualifiedName
QualifiedName::templateName needs a description

agreed

Subclause: 13.2.41 PropertyAccessExpression

The propertyAccessExpressionLowerDerivation constraint description refers to upper bounds when it should refer to lower bounds

agreed

Subclause: 13.2.40 PositionalTuple

PositionalTuple should have a constraint that it does not have more arguments than its invocation has parameters.

agreed

Subclause: 13.2.35 NameLeftHandSide

• There needs to be a constraint on NameLeftHandSide that if its name is qualified, and does not disambiguate to a feature, then it resolves to a parameter of the behavior containing the left-hand side, and, if it disambiguates to a feature, it resolves to a single referent that is a structural feature.

• In the nameLeftHandSideAssignmentAfterDerivation constraint, if the named left hand side has an index, then the assignments after the left hand side should be the assignments after the index.

• The derivations for assignmentBefore and assignmentAfter for NameLeftHandSide need to account for the possibility of the name disambiguating to a feature reference

agreed

Subclause: 13.2.29 LogicalExpression

• The definitions of the logicalExpressionIsBitStringConversion1 and logicalExpressionIsBitStringConversion2 constraints mention “shift expression” when they should say “logical expression”.

• The logicalExpressionOperands constraint should allow for BitString and Integer operands (per the semantics of logical expression in Subclause 8.6.7).

• The logicalExpressionTypeDeriviation constraint should give the type BitString if the expression is bit-wise.

agreed

Subclause: 13.2.28 LiteralExpression

The constraint literalExpressionTypeDerivation (“The type of a literal expression is given by the type of the literal, as defined for each subclass below.”) is not necessary, since it doesn’t provide any actual constraint. (Plus, in the current document organization, not all of the subclasses are “below” the subclause on LiteralExpression.)

Agreed.

Subclause: 13.2.34 NameExpression

NameExpression should override updateAssignments to return the assignments after its derived propertyAccess expression, if it has one (i.e., if it disambiguates to a feature reference).

agreed

Subclause: 13.2.33 NamedTuple

NamedTuple should have a constraint that its argument names all correspond to parameter names of its invocation and that no argument name appears more than once.

agreed

Subclause: 13.2.31 NamedExpression

The constraints namedExpressionIsBitStringConversion and namedExpressionIsCollectionConversion cannot really be checked within the context of NamedExpression, since there is no way from that context to determine what the type of the “corresponding parameter” is.

No Data Available

Subclauses: 13.2.8 CastExpression and 13.2.10 Classification Expression

The castExpressionTypeResolution and classificationExpressionTypeName constraints should require a non-template classifier

agreed

Subclause: 13.2.23 InvocationExpression

• The return parameter of the InvocationExpression::parameterElements helper operation should be ordered.

• The definition of InvocationExpression::parameterElements should also handle the case in which the reference is an association end.

Agreed. Though ordering the return parameter on parameterElements presumes a resolution to Issue 16472 such that the ownedMembers of a Namespace are ordered.

Subclause: 13.2.23 InvocationExpression

The derivations of type, lower and upper inherited in InvocationExpression are based on the return parameter of the referent of the expression. This doesn’t work for referents that are not behaviors or operations. Specifically:

• For an InstanceCreationExpression, the referent may be a classifier (Class or DataType), in which case, the type needs to be the referent itself and lower and upper need to both be 1.

• For a BehaviorInvocationExpression, the referent may be an association end, in which case the type, lower and upper need to be the same as for the end.

agreed

Subclause: 13.2.18

There needs to be a constraint on FeatureLeftHandSide that it resolves to a single referent that is a structural feature.

Agreed. Note that the revised text below presumes the resolution for Issue 16435, which adds the referent derived property.

Subclause: 13.2.13 ConditionalTestExpression

The description of the updateAssignments operation for ConditionalTestExpression should clearly state that assignments can be made in the first operand expression. It should also state that the type of newly defined names is the effective common ancestor of the types of the name in each of the second and third operands

agreed

Subclause: 13.2.6 LeftHandSide

A left hand side should have derived type, lower and upper attributes, since these are defined in Subclause 8.8.

Agreed (however, the correct subclause for LeftHandSide is 13.2.26, not 13.2.6). Constraints for AssignmentExpression also refer to the type and bounds of the left-hand side. Note, though, that the type and bounds for a left-hand side for the first assignment of a local name cannot be derived directly from the left-hand side, since they are determined by the right-hand side of the assignment. But this is already accounted for in the simple assignment multiplicity and type conformance constraints for an AssignmentExpression.

Subclause: 13.2.4

The binaryExpressionOperandMultiplicity constraint requires that the operands of a binary expression have a multiplicity upper bound of 1. However, an equality expression (a kind of binary expression) is allowed to compare to “null”, which has a multiplicity upper bound of zero.

agreed

Subclause: 13.2.3 BehaviorInvocationExpression

• The behaviorInvocationExpressionReferentDerivation should allow for resolution of the target to an association end.

• The behaviorInvocationExpressionArgumentCompatibility constraint should note that it only applies if the target does not disambiguate to a feature reference.

agreed

Subclause: 13.2.2

The assignmentExpressionCompoundAssignmentTypeConformance constraint should also handle compound assignments for bit string operators.

agreed

Subclause 10.5.4: ReceptionDefinition

In the syntax for ReceptionDefinition, the condition for d.name should be

.

agreed

Subclauses: 13.2.31 NamedExpression, 15.2.9 EnumerationDefinition, 15.2.15 NamespaceDefinition, and 15.2.16 OperationDefinition

• NamedExpression::isBitStringConverstion should be isBitStringConversion
• EnumerationDefinition::classDefinitionSpecializationReferent should be enumerationDefinitionSpecializationReferent
• NamespaceDefinition::annotationAllowed should not be abstract.
• OperationDefinition::redefinedOperations should be redefinedOperation

Agreed. (Note, however, that “classDefinitionSpecializationReferent” and “annotationAllowed” are not an attributes, they are a constraint and a helper operation, respectively. But the indicated errors still need to be corrected.)

Subclause: 11.5 Collection Functions

In Table 11-15, “ordered nonuique” [sic] appears twice (first column, second and third rows) and should be replaced with “sequence”. remove, removeAll and removeOne should return “T[*] sequence”.

agreed

Subclause: 11.3.6 Sequence Functions

In Table 11-14, the return type of IndexOf should be Integer, not any.

agreed

Subclause: 10.1 Overview

It is only necessary to require implicit imports of standard model library packages into model units. Any direct or indirect subunits of a model library unit with implicit imports will have visibility upwards of the packages imported into the model unit. Also, applying «ModelLibrary» to a subunit cannot prevent this visibility of the standard model library packages, and so this stereotype is also actually only effective on a model unit.

agreed

Subclauses: 9.14 return Statements
A return statement without an expression should be allowed for a behavior without a return parameter.

agreed

Subclause: 10.4.3 Active Classes

In the ProcessQueue example in Subclause 10.4.3, “sign” that appears twice in the classifier behavior should be “sig”.

agreed

Subclause 10.4.2 Classes

In the Singleton example use in Subclause 10.4.2 under Semantics, “allinstances” should be “allInstances”.

agreed

Subclause: 10.5.3.1 Constructors

At the end of Subclause 10.5.3.1 it states that: “In the absence of explicit constructor invocations at the start of a constructor body (and also in the case of the default constructor behavior), a super constructor invocation is made implicitly for each immediate superclass, in the order the superclasses appear in the specializes list of the class containing the constructor, before executing any statements in the constructor body.” However, if the immediate superclasses themselves have common ancestors (so called “diamond inheritance”), applying this rule recursively will result in the constructors of these common ancestors being called multiple times.

Agreed. Handling diamond inheritance can be tricky. The approach proposed here leaves the current constructor semantics largely in place, and simply adds that, after a constructor from a certain class is called on an object, other calls on constructors from the same class have no effect. This could be implemented adding class-specific initialization flags to the implementation of the object or by “linearizing” the sequence of direct and indirect super constructor calls and removing any redundant calls.

Subclause 7.5: Names

Subclause 7.5 should says that reserved words cannot be used as identifiers, but it should also note that Boolean literals (which are not classified as reserved words) can also not be used as identifiers.

agreed

Subclause: 9.12 for Statements

It should be made clear that the expressions in the loop variable definitions of a for statement are evaluated sequentially in the order of the loop variables (per the mapping). (Or, if the expressions are evaluated concurrently, then there needs to be a constraint that the same name cannot be assigned in more than one of those expressions.)

Rather than adding a constraint (and changing the mapping), it seems easier to just make it clear that they are evaluated sequentially. And, in the abstract syntax, ForStatement::variableDefinition is ordered, which also indicates that sequential evaluation is the intent.

Subclause: 9.6 Local Name Declaration Statements

Subclause 9.6 should have a cross reference to the abstract syntax class InstanceCreationExpression, since the InstanceInitializationExpression production creates an instance of that class.

agreed

Subclause: 8.8 Assignment Expressions

It should be allowed to parenthesize a left hand side. This makes it possible to parse the left hand side simply as an expression and then check afterward if it is correct (as is done in the grammar given in the annex). It is also consistent with Java syntax.

agreed

Subclause: 8.3.15: Sequence Construction Expressions

In Subclause 8.3.15, the parsing of a NullExpression should set the hasMultiplicity=true for the SequenceConstructionExpression, otherwise the derivation of the lower and upper attributes (see Subclause 13.2.46) will result in those both being 1 instead of both being 0.

In Subclause 8.3.15 Sequence Construction Expressions, under Syntax, in the production for SequenceConstructionExpression, in the second line, after “NullExpression” add “(hasMultiplicity=true)”.

There is a small problem in section 8.3.6 regarding property access expressions.
The problem is that the concrete syntax defined in that section will not
actually match the examples given in that section.

---------
Here is the concrete syntax defined in that section...

PropertyAccessExpression(e: PropertyAccessExpression)
= FeatureReference(e.featureReference)

FeatureReference(f: FeatureReference)
= FeatureTargetExpression(f.expression) "." NameBinding(f.nameBinding)

FeatureTargetExpression(e: Expression)
= NameTargetExpression(e)

NameTargetExpression(e: NameExpression)
= ColonQualifiedName(e.name)

Note that NameTargetExpression only allows ColonQualifiedName(s) to be used to
define a PropertyAccessExpression.

-------
Here are the examples of property access expressions from the same section...

poleValue.im
this.node
members.name
jack.house

Note that, because NameTargetExpression only allows ColonQualifiedName(s), none
of the above examples matches the concrete syntax.

----------
I suspect that NameTargetExpression should be defined to be a QualifiedName,
which is defined to be either a DotQualifiedName, an UnqualifiedName, or a
ColonQualifiedName, so...

NameTargetExpression(e: NameExpression)
= QualifiedName(e.name)

where QualifiedName is defined elsewhere as:

QualifiedName(q: QualifedName)
= ColonQualifiedName(q)

This is indeed a little confusing, but it is not actually an error in the spec. There is a note on page 38 that says:
“See Subclause 8.2 for rules on the disambiguation of a qualified name using the dot notation to a property access expression. Such a potentially ambiguous expression is always initially parsed as a qualified name.”
For example, as far as context-free parsing is concerned, an expression like “poleValue.im” is ambiguous – it could be a qualified name using the dot notation, or it could be a property access expression for the “im” attribute of the value of the name “poleValue”. Disambiguation requires using static semantic information on “poleValue” (e.g., is it a local name with a type that has an “im” property), as described in Subclause 8.2.
Despite this conceptual ambiguity, the formal grammar is made unambiguous by always parsing “poleValue.im” initially as a qualified name. That is why a dot qualified name is not allowed as a name target expression. Possible disambiguation to a property access expression then happens as part of static semantic analysis (this is formally through the derived QualifiedName::disambiguation attribute specified in Subclause 13.2.42).
Note also, by the way, that the grammar as given actually does parse “this.node” as a property access expression, because “this” is a reserved word, not a name. Thus, “this” is parsed as a NonNamePrimaryExpression (a ThisExpression, to be exact), not a NameTargetExpression.

In order to play with ALF I have thrown together a parser for my own use.
Along the way I have found a small error in the spec regarding the Abstract Syntax for ALF. Many clauses in the spec (Beta 1) refer to 'StructuredElement' and those same clauses say that StructuredElement is defined in clause 10.4.4. However, in clause 10.4.4 the element appears to be named 'StructuredMember' instead.

It looks to me like StructuredMember should be renamed to StructuredElement since the term 'Element' appears to be the convention used throughout the rest of the spec.

The intent was actually to change StructuredElement to StructuredMember (which is a better name for it), but the rest of the document outside Subclause 10.4.4 does not seem to have been properly updated for this (note that the parser grammar in the Annex uses StructuredMember).

Subclause: 6.2 Templates

The rule in Subclause 6.2 for constructing the name of an equivalent bound element does not account for the possibility that one of the arguments may be null (i.e., “any”). While the syntax for template bindings in qualified names (Subclause 8.2) does not allow “any” to be used as a template argument, such an argument can result from the rules for the implicit binding for a template behavior as given in Subclause 8.3.9.

agreed

Need to replace the CMOF file for the abstract syntax by a UML file for UML 2.4

Agreed, the Alf abstract syntax is supposed to be based on UML 2.4.

The Model file includes the UML Primitive Types package rather than referencing it.

This occurs in the Alf Standard Library model XMI file. This file actually contains a spurious UML package, with a nested AuxiliaryConstructs, with PrimitiveTypes nested within that (as well as a number of other, empty packages). This included UML package should be removed. Note that all primitive type references elsewhere in the file already use hrefs with normative URIs, not references to the nested PrimitiveTypes package

[Sridhar Iyengar] Wf rule for Interaction: The OCL expression appears to
be wrong based on the associated text - I am not sure. I think there is
an extra 'action' in the fragment 'm.action.action.allNestedActions'.
Next para has a minor typo - change 'an procedure' to 'a procedure'.

accept

[Sridhar Iyengar] 37. Page 2-274 : Changes to semantics of Class "a
method realizing ... parameters of kind in and out match input pins...".
For some one not concerned with implementing Action Semantics - it is an
optional compliance point after all, adding this text to the basic Class
specification causes additional confusion because this introduces new
terminology 'pins' without providing appropriate context. This text can
simply be in the Actions package specifciation and reference parameters
without any loss of information. If for some reason submitters believe
this explanatory text is important, please refer to the Action Semantics
spec sections to provide additional context that explains why this
information is relevant.

[Conrad] BTW, the relation of parameters to pins is added to the seventh
paragraph of the semantics of Class on page 2-74, starting with a
modification of the seventh sentence (see asterisks)

A method realizing an operation has the same signature as the
operation and match those of a procedure implementing the
specification of the operation. Pins of procedures have two
direction: in and out, while method and operation parameters have
direction in, out, inout, and return.

accept

[Sridhar Iyengar] 36. Messaging chapter: 'Optional profile for
Resolution of Operations and Signals' May be this section is a carry
over of some earlier work. Since the whole action semantics spec is an
optional compliance point, what is the point of mentioning an additional
optional profile? Is this is a separate compliance point? This is not
called out in the Preface "Compliance Issues". The two stereotyped
Associations - are these derivations of any existing MetaAssociations in
UML 1.x.? If these are not, then these two associations are proposed
changes to UML 1.4 and will change the UML 1.x DTD. Note that in
general profiles are NOT intended to change the UML DTD. If these
stereotyped Associations are expected to be implemented using 'Tagged
Values', then that should be clearly specified - in which case the DTD
does not change.

So we now have an optional profile that is part of the optional Action
Semantics spec? Please clarify the intent and if appropriate mark this
proposed profile package as an additional optional compliance point.
Also this profile is not documented in the same form as other UML
profiles adopted by OMG.

accept

[Sridhar Iyengar] 35. General question : In describing messaging
actions, most of the examples apply to programming language examples.
However, examples related to middleware invocations (in CORBA, DCOM...)
are equally if not more significant. Are these messaging actions,
intended to be used with distributed component middleware or messaging
middleware? What is the intended use case of this section of the spec?

decline

[Sridhar Iyengar] 25. CreateLinkObjectAction class: Please clarify how
attributes defined in AssociationClasses are handled - Do you simply use
'AddAttributeValueAction'? - This was my assumption. See also comment 25
which states semantics of creating instances of AssociationClasses is
undefined.

Accept

[Sridhar Iyengar] 21. Page 2-262, Section 2.19.3 Identifying a Link :
Please clarify the term 'end Objects' and this terms relationship to The
terms 'link object' and 'link'. These terms are used - but not
consistently when defining Association Actions. I could generally
understand the intention (because in the MOF spec we describe this in
gory detail!), but UML will be used a larger number of vendors and we
should nail this better.

22. Page 2-262 308, Para 2 , fix the grammar. Once again the spec says
'link always have exactly one object at its ends', Hopefully you mean
'link always has exactly one object reference at its end'. The
difference between 'object' and 'object reference' is subtle in many
systems and it looks like in this spec the term 'object' is used to mean
both.

Accept

[Sridhar Iyengar] 29. Various pages : I have come to the conclusion that
parts of the spec where Inputs/Outputs are defined are not all that
useful. I suggest the FTF consider whether these should be carried over
in the spec. Since not much guidance is given on how to handle
"RuntimeObject" and "RuntimeInstance" and this is left as an
implementation issue anyway - I dont see the value. May be all that is
needed are the examples in the Appendix. Note I had to read carefully to
find out the intended differences between "RuntimeObject" "and
RuntimeInstance" - I expected this to be a typo but then realized "that
the former refers to 'objects' and the latter refers to 'values' - See
especially Page 68. This is a bit too 'subtle'.

decline

[Sridhar Iyengar] 28. ReadLinkAction class : The explanatory text -
first sentence - is confusing.

accept

[Sridhar Iyengar] 26.5. I recommend that the FTF add a section that
clearly identifies the parts of the UML::Foundation::Core package that
are NOT supported by Action Semantics specification (ex: features that
use TargetScope, Changeability, certain multiplicity constraints etc.) -
This will serve as a useful guide for designers planning to use
executable models who can chose to not use these capabilities of UML.

decline

[Sridhar Iyengar] 26. CreateObjectAction class: "This action
instantiates classifier" - It is later stated in the same para, the
semantics is undefined for creating objects from abstract classifiers or
from AssociationClasses. Note that since Classifier itself is an
abstract class, the text in this section is confusing at best. Suggest
it be reworded to 'This action instantiates a specific Class - instead
of the general term 'classifier'. Since this spec does not say much
about how any other subtype of Classifier (other than Class) is
instantiated, let us keep it simple.

accept

[Sridhar Iyengar] 27.5 ReadExtentAction class: Check the multiplcity of
the Output pins - it is 1 only in the metamodel diagram (see Other
Actions diagram) - However there is a well formedness rule [3] which
states that the result output pin has a multiplicity of unlimited -
which would make sense since we are dealing with extents. Fix the
metamodel multiplicity and removing the wellformedness rule would
resolve this confusion.

decline

[Sridhar Iyengar] 27. ReadExtentAction class : For what classifiers is
this Action expected to be implemented ? Classes and AssociationClasses?

accept

[Sridhar Iyengar] 34. ReduceAction para 2 : In the example, it looks
like the result of the binary associative subaction addition should be
the scalar 11. The spec says 9. Did I miss something?

accept

[Sridhar Iyengar] 33.5: Also for the 'uninitiated' what is an '

' - see Figure 2-56, page 2-303. How is this
constraint used? Is this what is meant by collection sizes and types of
the collection have to be the same? If so a one line explanation in the
spec that defines the term would be useful.

References to congruent removed

[Sridhar Iyengar] 42. Page C-19, section C.5 Messaging Actions, 2nd
para, the text refers to the local variable 'my_customer' and refers to
object inuvocation of validate(). The class diagram in Page C-20, figure
C-16, refers to the valdiate() operation but the figure shows a
marshalAction on CustomerDeleteRequest class. Please fix the figure (Or
remove it!) to be consistent with the example. Note that Figure C-17
does show the validate() operaton invocation correctly.

accept

[Sridhar Iyengar] 32. MarshallAction : The type of marshalType in the
text is 'Class' - but in the metamodel diagram - page 74, the type is
Classifier'. If the intention is indeed 'Class' fix the metamodel.
Class appears to be correct if the intention is not to support any other
subtypes of Classifier. Note this comment also applies to
UnmarshalAction on page 79.

accept

[Sridhar Iyengar] 20. In a number of places in the spec (see Page 2-261,
para 3 for an example, Page 2-266 314 next to last paragraph...) , the
following statement 20. In a number of places in the spec (see Page
2-appears "The semantics of adding a value that violates the
multiplicity of an attribute is undefined". Why did the submitters not
choose to treat this event as a violation of well formedness rules and
raise an exception (for example by invoking an exceptionAction)? For
vendors that implement UML tools that implement these constraints, it
would be better if the semantics of actions handles these violations
consistently. At some point in time when enough tools implement the
Action Semantics spec issues such as these will become more important
for interoperability reasons. Imagine a programming language interface
(MOF 2 IDL or JMI) used to manipulate a UML metamodel server which has
been extended to support the Actions package. It would be good if
conformant client implementations treated multiplicity violations
consistently. (the fact that the spec leaves this undefined is one way
to be consistent I suppose!). Should the spec reviewer assume that for
those parts of the spec where the semantics is explicitly marked as
undefined, we should raise a red flag for modelers using these
capabilities because those models 'may not be executable'?

See also Page 2-266, next to last para. 'creating a link that violates
20. In a number of places in the spec (see Page 2-maximum multiplicities
has undefined semantics'.. 'modeler must determine when minimum
multiplicity associations should be enforced'. There isn't a standard
way (I know of), this can be done consistently in UML. May be this will
get sorted out as part of UML2 as part of the OCL Metamodel RFP.

Multiplicity constraints are very popular in UML and we should look at
providing some clear guidelines of when and how these (and other
constraints) are checked or ignored in UML.

Finally in Page 128 of revised submission the following text "When a
semantic variation point' is mentioned.

24. ClearAssociationAction class. I suggest that handling
multiplicity be a semantic variation point as opposed to making the
arbitrary choice that minimum muliplicity be violated when links of the
association in which the object participats is destroyed.This could for
example be handled by tags that can be customized (preferably at the
package level) to (a) ignore multiplciity constraints (b) enforce them
and raise an exception if the constraint is violated. I did notice the
the choice to ignore minimum multiplicity is being consistently made -
so this will minimize confusion.

Decline

[Sridhar Iyengar] 15.Page 2-238: Figure 2-41. Looking at the metamodel,
it looks like the same 'Clause' can be owned by a LoopAction and a
ConditionalAction. For pragmatic reasons, there should be an OCL
constraint preventing this from happening - unless the submitters feel
the same clause can be 'owned' by both types of Actions. (I tried to
find the constraint and did not see one). I usually see a red flag when
multiple composite associations point to the same Class. (In this case
both LoopAction and ConditionalAction have a composite Association to
Clause. In other parts of the spec where this pattern recurs, I did see
the OCL constraint! (See Figure 3, Page 15 and related well formedness
rule on Page 21 that makes sure an 'input pin must be owned by either an
Action or a Procedure but not both'.

accept

[Sridhar Iyengar] 13. Page 22-223: 'Procedure is a set of actions that
may be attached as a unit to other parts of the metamodel' It is not
clear from the metamodel which model elements a procedure can attach to.
Can a procedure be attached to a use-case? operation? statemachine? Some
guidance would be useful.

Fixed in the adopted spec.

[Sridhar Iyengar] 11. page 2-231: States that 'Since UML does not
provide any standard Classifier that is the ancestor of all classifiers,
untyped pins can be used for the purpose of accepting input of "any"
type' I think you mean a standard 'class' that is an ancestor of all
modelelements - not just classifiers. (This would be similar to
RefBaseObject in MOF or 'Object' in smalltalk or java.lang.object in
Java - is this the intent?). Note that the 'type' of Pin is a
'Classifier' in the metamodel.

Decline

[Sridhar Iyengar] 6,8, 10. Typos:

Page 2-209, Figure 2-36 heading "An fragment"

Page 2-217, section 2.16.1 missing 'of' in last sentence.

page 2-228 : Association 'antecedent' and page 2-221, figure
2-38 Aciton foundation metamodel 'antecedant' in the Figure 3
need to be consistent. P.S If the metamodel definition
changes the association name, note that the IDL and XML DTD
will need to be regenerated.

accept

[Sridhar Iyengar] 42. Page C-19, section C.5 Messaging Actions, 2nd
para, the text refers to the local variable 'my_customer' and refers to
object inuvocation of validate(). The class diagram in Page C-20, figure
C-16, refers to the valdiate() operation but the figure shows a
marshalAction on CustomerDeleteRequest class. Please fix the figure (Or
remove it!) to be consistent with the example. Note that Figure C-17
does show the validate() operaton invocation correctly.

duplicate of 4924 --close issue

[Sridhar Iyengar] 4. I was confused when trying to interpret
'runtimeinstance' data type - but after the explanation (from
Conrad/Steve/Jim) about the removal of the execution model (with the
associated ripple effect on change bars in most of the submission which
slowed my review), I realize that this will not cause any interchange or
interoperability problems. I recommend that this usage be clarified in
the spec, so others dont get confused either.

30. ReclassifyObjectAction class. The text specifies the Association
'input' to be of type 'RuntimeObject'. This clearly cannot be right
because 'RuntimeObject' is not defined as a class in the metamodel. The
type should be 'InputPin'.

see below

Variable to VariableAction association should have multiplicity *

accept

ApplyFunctionAction should work with any user-defined
function, including those that operate on objects, and that
have no outputs.

decline

TestIdentityAction should have an output

accept

PrimitiveFunction should have a supertype

accept

The description of ReclassifyObjectAction does not specify whether the
states of the object's state machines are preserved across
reclassification. What if a current state before classification does
not exist after reclassification? Are exit actions run? Can
reclassification interrupt an RTC step?

accept

Document: OMG Unified Modeling Language Specification (Action Semantics)
Sections: 2.15 - 2.23

Description:
The style of the action semantics sections are not entirely consistent with the other sections in the Semantics chapter, and, to some extent are not even consistent among themselves (compare, for example, the structure of the Composition Actions, Read and Write Actions and Computation Actions chapters). While complete consistency of subsection organization is not necessary, at least the following should be consistent:

o The use of the terms "abstract syntax", "well-formedness rules" and "semantics".
o The style for presenting descriptions of attributes and associations.
o The way OCL is presented (e.g., in the UML 1.4 spec, context clauses are used to define additional operations).

decline

[Joaquin Miller] Does the messaging mode support CORBA's messaging styles?

Joaquin,

> But the three ways of invoking a procedure in CORBA are:
>
> One is synchronous, which works just as you write above.
>
> The second is asynchronous or one-way, which is not exactly
> the same as you describe above for the action semantics.
> But close enough, perhaps.

I can't tell the difference.

> The third has the silly name, deferred synchronous; it is a kind
> of asynchronous invocation.

The CORBA spec says this is a synchronous operation called
asynchronously, but the caller still has the option to get the results
at a later time. Action semantics does not support this. The
workaround would be complicated.

decline

Make spec reflect package structure.

accept

[Michael Latta?] Deletion action should have option for executing or not
executing the state machine exit actions, for example.

Decline with clarification

Marit Skrede, marit.skrede@netcom.no] I suspect there should be an
"#include Actions.idl" line at the start of ActivityGraphs.idl - and
just thought I'd let you know. (BTW, I've jusst used the #includes as
"lists" when using the idls for Java.)

decline

[Conrad Bock] More support for exceptions across procedure boundaries.

Already supported