Summary: The current specification for OCL lacks many of the features we commonly
use when doing formal specification of class interfaces, e.g. the ability
to specify the frame condition, the ability to specify postconditions
case-wise, the ability to specify when exceptions are thrown, etc.

To bring OCL closer to the state of the art, I would like to see these
considered as future extensions.

This issue was forked off from UML 1.x 15 years ago. It doesn't seem to have anything to do with OCL at all. But rather than throw the issue back to UML, let's address it anyway.
One could imagine a UML extension that introduced a Frame class and an Operation.ownedFrameCondition to host it. OCL expressions could then impose the semantics.
However a Frame would be specific to a particular implementation approach, and so it would seem more appropriate to use stereotypes to model the implementation characteristics. Perhaps one of the standard UML profiles already provides this capability.
Disposition: Closed, no change

Typo. contaxt, change to context

Initial Comment: contaxt->context
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

In A.2.1.2 Operations on p193, toLowerCase is referred to as toLower "case translations are possible with toUpper and toLower" and again in Table A.1

Also toUpperCase is referred to as toUpper in the same places

No Data Available

12.12 para 3 "OCl" for "OCL".

12.8 para 1 last sentence, 12.9 para 1 last sentence; both are unreadable.

12.12.2 No [B] rule

12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

The OCl typo is fixed in OCL 2.3.
The grammar typos are easily fixed.
While making the multiplicity statements readable, we can make one small step towards aligning OCL with UML 2.x properties.

When Issue 9796 updated terminology to use PropertyCallExpCS, attrOrAssocContextCS should have been updated to propertyContextCS.

In 12.12.2 contextDeclarationCS replace
[A] contextDeclarationCS ::= attrOrAssocContextCS
by
[A] contextDeclarationCS ::= propertyContextDeclCS
Replace
12.12.3 attrOrAssocContextCS
This production rule represents a context declaration for expressions that can be coupled to an attribute or
association end. The path name refers to the “owner” of the attribute or association end, the simple name
refers to its name, the type states its type.
attrOrAssocContextCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS
by
12.12.3 propertyContextDeclCS
This production rule represents a context declaration for expressions that can be coupled to a property. The
path name refers to the “owner” of the property, the simple name refers to its name, the type states its type.
propertyContextDeclCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS

11.2.3 states clearly that "Any property call applied on null results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclVoid results in invalid, except for the operations oclIsUndefined(), oclIsInvalid(), =(OclAny) and <>(OclAny)."

11.2.4 states clearly that "Any property call applied on invalid results in OclInvalid, except for the operations oclIsUndefined() and oclIsInvalid()." This is being revised by Issue 14197 in OCL 2.3 to: "Any property call applied on OclInvalid results in invalid, except for the operations oclIsUndefined() and oclIsInvalid()."

Therefore invalid.oclIsTypeOf(OclInvalid) => invalid and null.oclIsTypeOf(OclVoid) => invalid.

But the above are widely used in the specification as for example:

"oclIsUndefined() : Boolean
Evaluates to true if the self is equal to OclInvalid or equal to null.
post: result = self.isTypeOf( OclVoid ) or self.isTypeOf(OclInvalid)"

clearly expecting isTypeOf (a typo) to return true/false, not invalid sometimes.

Issue 14197 relaxed the OclVoid property list to allow = and <>. Perhaps all oclXXX operations should have an explicitly defined semantics for OclVoid and OclInvalid, supporting rather than denying reflective usage of the values as in self.isTypeOf( OclVoid ).

Merged with Issue 18437.
Disposition: See issue 18437 for disposition

The specification is very vague as to how and when a non-collection is converted to a collection.

11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

7.5.3 states that 'Such a single object can be used as a Set as well. It then behaves as if it is a Set containing the single object. The usage as a set is done through the arrow followed by a property of Set.'

The collection type inconsistency between Bag{} and Set

makes compile-time type resolution difficult, since the null-ness of x cannot be known till run-time. It would be better to have either Set or Bag uniformly as the conversion collection type. Bag{} as the least useful seems more appropriate.

When a conversion is applicable is unclear.

In the example, self.manager->isEmpty() is intended to be interpreted as

if self.manager.isUndefined() then Set{} else Set

endif->isEmpty()

so that null->isEmpty is also valid.

However is

null->excludesAll(null)

equivalent to

Bag{}->excludesAll(Bag{})

and so true?

A simple policy of 'wherever a collection is required and a non-collection is provided perform an implicit conversion to collection-literal' resolves this.

However are

null = Bag{}

or

Bag{} = null

both equivalent to

Bag{} = Bag{}

and so true?

In this case we have a problem of asymmetric overloading.

null = Bag{} satisfies the signature for OclVoid::=(OclAny) and so returns false.

Bag{} = null could satisfy the signature for Bag::=(Bag) and so return true with the help of an implicit conversion.

Presumably an additional OclVoid::=(Collection) overload is needed to restore symmetry.

Resolved by Issue 15009, where the explicit synthesis of oclAsSet() avoids the troublesome conversions above.
Disposition: See issue 15009 for disposition

OCL 2.2 defines equalsIgnoreCase as returning an Integer. Given that the operation determines equivalence of two Strings, I would expect it to return Boolean: either the strings are equivalent (true) or they are not (false).

No Data Available

The Issue 14981 considered use of explicit null as a Collection.

11.2.3 states that 'If the source is the null literal, it is implicitly converted to Bag{}'.

Surely when the null arises as a navigation result, the isOrdered and isUnique characteristics of the navigated property should determine what CollectionKind the null result is converted to?

However meta-modelling tools and meta-modellers pay little attention to the isUnique and isOrdered characteristics of zero and unit multiplicity properties. Using this overlooked information may cause surprises.

7.6.3 Navigation over Associations with Multiplicity Zero or One suggests non-collection are converted to Sets. Similarly 7.6.5, 9.7. So there is a contradiction in the normative conversion to Set or Bag. Set seems more sensible and what the non-normative clauses suggest.
Using the accidental ordered/unique attributes of non-collections would lead to horrible surprises for existing usage, so it must be conversion to a set.
Since the conversion of null yields an empty set, whereas any other object yields a single element set, the Set size is data dependent and so must be determined at run-time and cannot be expressed as a CollectionLiteralExp. Rather, evaluation of PropertyCallExp and OperationCallExp must detect a mismatch between a non-collection source type and a collection-type referredOperation class.
Delayed resolution is inconsistent with OCL's static typing, so let us make it explicit by defining OclAny::oclAsSet() for the static analysis to invoke and perform the conversion. The conversion is represented as a regular OperationCallExp in the AST and only type-dependent run-time decisions need to be made.
Note that the revisions below do not address the deficiencies in the normative Clause 9 text raised by Issue 15790. We continue to rely on the final sentence of 9.7: "The mapping is not formally defined in this document but should be obvious."

OCLAny::=() is defined as 'True if self is the same object as object2.'

This is not overloaded for numeric types, and it is not specified that a numeric value may not have multiple instances.

The definition therefore implies that:

1 = 1

may often evaluate to false, and that

1.0 = 1

must evaluate to false even though (1.0 <= 1) and (1.0 >= 1) will evaluate true

Suggest overload

::

to use values rather than objects.

The use of object should be clarified so that
Class instances are compared by object identity.
DataType instances are compared by value.
This resolution overlaps with null/invalid clarification and so the change below includes changes for Issue 18437.

8.3.8 states that in regard to allInstances

"returns all instances of the classifier and the classifiers specializing it. May only be used for classifiers that have a finite
number of instances. This is the case, for example, for user defined classes because instances need to be created explicitly,
and for enumerations, the standard Boolean type, and other special types such as OclVoid and OclInvalid."

While it is true that OclInvalid has exactly one instance, the corresponding return of Set

is not well-formed.

Therefore the invocation OclInvalid.allInstances() must return invalid.

Suggest:

Replace "and OclInvalid" by ". But not for OclInvalid, for which the return is invalid"

No Data Available

subclause [10])

It reads: let foundElement ... in result = if foundAttribute ... else foundElement ...

(foundAttribute is undefined, I understand it means to "foundElement")

simple typo

Related to Issue 7539)

It reads: isOclKind

It should read: oclIsKindOf

Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

This typo is addressed by Issue 14882
Disposition: Merged

The second half of 7.3.3 uses a named-self syntax that is missing from 12.2.5.

context c : Company inv:
c.numberOfEmployees > 50

In 12.12.2 classifierContextDeclCS replace
This production rule represents a context declaration for expressions that can be coupled to classifiers.
classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
by
This production rule represents a context declaration for expressions that can be coupled to classifiers. The
variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form.
[A] classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
[B] classifierContextDeclCS ::= ‘context’ simpleNameCS ':' pathNameCS invOrDefCS

(Related to Issue 7539)

It reads: isOclKind

It should read: oclIsKindOf

Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

No Data Available

subclause [4]

It reads: names->tail()

It should read:
names->subSequence(2, names.size())

Rationale: tail() is not an operation of Sequence

No Data Available

At the top of the page, there is a formula to define the equal operator. The formula begins with I(=t). That t should be subscripted as we see in the sentence that precedes the formula.

The original report against OCL 2.3 A.2.2 has migrated to A.4.2 in OCL 2.3.1.

In the table A.1 (Schema for operations on basic types), the operations

are defined as applicable to

.
While the result is certainly Boolean, the parameters can't be Boolean in general, unless UML defined such operators for Booleans. According to section 11.5.4, there is no definition for the operators. Then Boolean should be removed in the set.

No Data Available

Whereas there are some infix operator definitions in later document, this list of infix operators isn’t described sufficient. For example, there is ‘>’ definition on 7.6.1. However, ‘>’ is not included in this list. Additionally, ‘=’ is defined on 11.6.1, 11.6.2, 11.6.4, 11.6.5. However, there isn’t ‘=’ on this list. By the way. ‘=’ is not defined for Integer, and Real. Is that no problem? Furthermore, “implies” definition could not be found. Add infix operator sufficiently. And, clarify the operator definition.

Not much of a title.
Section 7.5.8 is not normative so it is not necessary to enumerate every infix operator.
None of the logical operators, and, or, xor, implies are listed.
The "->" and "." tokens occur between their arguments and so could be regarded as infix, however navigation operators are not normally regarded as infix operators and so listing them would be more confusing than omitting them.
In most languages, "=" is not an infix operator, however in OCL it is, so omitting it when all other operators with punctuation spelling are listed is indeed a bit confusing.
(The punctuation of the list is dreadful.)
Issue 15009 introduces a missing section on "->" and "." operators.
Issue 14918 revises the definition of OclAny::= to be sensible for DataTypes.
implies is defined in 11.5.4

It is difficult to understand which “latter” indicates. Make clear which “latter” implies.

Initial Comment: Make clear which “latter” implies.

1st paragraph: Single quote does not close in two places:
’The Expressions Package
’The Types Package
Complete the quote like the following.
’The Expressions Package’
’The Types Package’

Initial Comment:
Complete the quote like the following.
’The Expressions Package’
’The Types Package’
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

Main text. References like [Kleppe2001] and [Clark2000] are not appropriate in the main text of International Standards. Modify the text as appropriate

Initial Comment/Suggestion: Modify the text as appropriate.
Comment: The explicit academic referenced may remain in the informative bibliography but
should not remain in the core document of the specification

Section 9.3.18 BooleanLiteralExpCS, 9.3.19 CallExpCS, 9.3.24 TypeCS,, 9.3.37 OclMessageExpCS, 9.3.39 For instance in case of 9.3.18, numbered list are shown like below.
“[2] [A] BooleanLiteralExpCS ::= ‘true’
[3] [B] BooleanLiteralExpCS ::= ‘false’”
The numbering are not consistent with others.
PROPOSED RESOLUTION: For instance, replace
“[2] [A] BooleanLiteralExpCS ::= ‘true’
[3] [B] BooleanLiteralExpCS ::= ‘false’”
with
“[A] BooleanLiteralExpCS ::= ‘true’
[B] BooleanLiteralExpCS ::= ‘false’”.
Apply the same type of modifications to all identified clauses.

Initial Comment:
For instance, replace
“[2] [A] BooleanLiteralExpCS ::= ‘true’
[3] [B] BooleanLiteralExpCS ::= ‘false’”
with
“[A] BooleanLiteralExpCS ::= ‘true’
[B] BooleanLiteralExpCS ::= ‘false’”.
Apply the same type of modifications to all identified clauses.
Comment: Close as Fixed by OCL 2.3

Abstract syntax mapping and Synthesized attributes
(two places)
Reference” simpleNameGr” is incorrect, Replace this with simpleNameCS

Initial comment: Replace this with simpleNameCS.
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

Table 7.3 doesn’t understand easily, because “condition” column doesn’t give sufficient explanation. Write more explicit explanation

The condition is an extra rule which must be satisfied in order to say that the type in the first
column conforms to the type in the second column. An extra sentence to explain that will be
provided. Besides, the UnlimitedNatural condition looks like an explanation rather than a
condition. So this explanation will be rather located below the table.

There are same element names in both OCL and UML. Those are confusing. I wonder whether those are UML elements or OCL elements. Besides, it seems there is no clear distinction between UML/OCL (upper case letter) term and general term (lower case letter), since these are used in mixture.

• It is confusing to distinguish OCL “Constraint” from UML “Constraint” in the text. Furthermore, there are some “constraint” s (in a lower case letter). The lower case letter/upper case letters for “constraint” are mixed.
  OCL “Constraint” should be distinguishable from UML “Constrain”.

Not much of a title.
There are many element names that are the reused in UML; presumably class names were meant. I think that these are all distinct and not confusing to me. No convincing example is given. The example of a Constraint is where UML and OCL overlap so it is obviously the same class.
Spelling is separately raised as Issue 16126 so there is no need to address it here as well.
Disposition: Closed, no change

Synthesized attributes, [B] The if-then-else-endif indentation of “The referred operation” part is not appropriate. Replace that part with the list below this table (Listing#1).

Initial Comment/Suggestion: Replace that part with the list below this table (Listing#1).

As keywords, it is necessary to include “forAll”, “exists”, “any”, “one”, collect”, “select”, “reject” etc., since there are definitions for these on p161 and other clause. This key word list is insufficient. Add “forAll”, “exists”, “any”, “one”, “collect”, “select”, “reject”.

No Data Available

Disambiguating rules. [1] [1] is redundant. Replace this with [1].

Initial comment: Replace this with [1].
Comment: Close as Fixed by OCL 2.3
Disposition: Closed

Typo. "This clause describes teh abstract syntax ...""This clause describes the abstract syntax ..."

Closed as Fixed by OCL 2.3
Disposition: Closed

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.

Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2.

Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

Revised Text:
In Figure 8.2 and Figure 13.3 change LoopExp.iterator from 0..1 to 1..2

.

In Section 8.3.1 LoopExp iterator replace
The iterator variables
by
The ordered set of one or two iterator variables.

In Section 9.3 IteratorExpCS replace
IteratorExpCS.ast.iterators->size() = 1
else
IteratorExpCS.ast.iterators->at(2).name = VariableDeclarationCS[2].ast.name
and
IteratorExpCS.ast.iterators->at(2).type =
...
[A] IteratorExpCS.ast.iterators->forAll(initExpression->isEmpty())
...
[C, D] IteratorExpCS.ast.iterator.type =
...
body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator
by
IteratorExpCS.ast.iterator->size() = 1
else
IteratorExpCS.ast.iterator->at(2).name = VariableDeclarationCS[2].ast.name
and
IteratorExpCS.ast.iterator->at(2).type =
...
[A] IteratorExpCS.ast.iterator->forAll(initExpression->isEmpty())
...
[C, D] IteratorExpCS.ast.iterator->at(1).type =
...
body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator->at(1)

In Section 9.3 IterateExpCS replace
IterateExpCS.ast.iterator.name = if VariableDeclarationCS[1]->isEmpty() then ‘’
...
IterateExpCS.ast.iterator.type =
...
IterateExpCS.ast.iterator.initExpression->isEmpty()
by
IterateExpCS.ast.iterator->at(1).name = if VariableDeclarationCS[1]->isEmpty() then ‘’
...
IterateExpCS.ast.iterator->at(1).type =
...
IterateExpCS.ast.iterator->at(1).initExpression->isEmpty()

In Section 10.3.1 LoopExpEval iterators replace
The names of the iterator variables in the loop expression
by
The ordered set of names of the one or two iterator variables in the loop expression.

The attached surprisingly large set of revised text recommendations endeavours to resolve every inconsistent use of invalid and null/void types and the failure to update the specification when undefined was split into null and invalid. The recommendations also correct many conversion errors that crept in when Word Processor formats were changed. Once these changes are incorporated, a very careful proof read against at least Annex A of 03-01-07 should be performed.

The initial discussion identifies that the approved resolutions of Issues: 6611, 10433, 10434, 12349, 12378, 12484 and 12485 are at best deficient

No Data Available

Issue 11098 resolved the missing precedence of let-in as lowest. This requires "2 * let a:Integer=1 in a + 1" to be interpreted as "(2 * (let a:Integer=1 in a)) + 1" making use of a non-trivial let body surprising and needlessly complicated. The problem with the open-ended right hand side can be resolved by assigning let-in the highest atomic expression precedence and defining its resolution as right-associative. The above example then has the obvious meaning "2 * (let a:Integer=1 in (a + 1))".

Issue 6544 introduces ^ and ^^ at higher precedence than . and ->. However since these operators can only return left hand arguments for each other, there is no need to assign these to different levels.

if-then-else-endif has an intermediate precedence in OCL 2.1. Since this term has keywords at start and end, the term is equivalent to an atomic expression. In so far as precedence is meaningful it is a high precedence.

Parentheses should be bulletted at high precedence.

Non commutative operators such as / have no defined order of evaluation leaving the value of "8 / 4 / 2" undefined. Binary operators should be specified as left-associative; i.e "(8 / 4) / 2".

Section 9.3.2 duplicates 7.4.7.

No Data Available

Define the concrete syntax of a simpleNameCS to avoid punctuation collisions, support Unicode characters, and add a double quoted form with escape sequences for awkward names.

Define the concrete syntax of a StringLiteralExpCS to support escape sequences for awkward characters.

Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.

Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

No Data Available

The specification of the UnlimitedNatural type is largely missing and often trivially inconsistent.

see pages 24 - 35 of OMG document ptc/2010-12-01

Erroneous operation names 'isOclType' and 'asOclType'. The operation 'isOclType' appears four times throughout the document. I presume it refers to 'oclIsTypeOf'. The operation 'asOclType' appears six times throughout the document. I presume it refers to 'oclAsType'.

No Data Available

Specification: Object Constraint Language, formal/06-05-01

Section: 7.6 Collection Operations

Summary:

The concept of transitive closure is very useful for specifying well-formedness constraints on binary relations.

For a binary relation r:A->A and elements x,y,z in A, r(x,y) is true when r relates x to y and r is transitive whenever for any x,y,z in A, r(x,y) and r(y,z) imply r(x,z). The transitive closure of a binary relation r:A->A is the smallest relation, ^r:A->A, that contains r and is transitive.

In the UML specification, the definition of Classifier::allParents() : Classifier[*] as “all the direct and indirect ancestors of a generalized Classifier” could be equivalently paraphrased as the transitive closure of the Classifier::parents() : Classifier[*] relation.

Specifying the notion of transitive closure for the OCL specification can be problematic as this notion refers to a meta-property not expressible in first order logic (i.e., the smallest relation satisfying a given property). However, the notion of transitive closure can be specified in the context of a particular API for evaluating OCL iterator expressions such as that of the Eclipse OCL implementation of the OCL2.0 specification:

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.ocl.doc/references/overview/OCLOverview.html

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl/src/org/eclipse/ocl/internal/evaluation/IterationTemplateClosure.java?root=Modeling_Project&view=markup

A synopsis of the algorithm for computing the transitive closure as an OCL iterator expression is available here:

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01390.html

No Data Available

[Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.]

Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

Define which Complete OCL reserved words are Essential OCL reserved words.

No Data Available

Description:

9.3 Concrete Syntax
As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried.

Should be

As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «», the symbol with the «_» skipped is looked up in the metamodel.

Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here.

Discussion:
Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward
spellings. This solves the problem of accessing either _'self' or _'_self'.

Issue 7341 resolved that a bad oclAsType in 7.4.6 should return invalid.

Issue 10437 resolved that the revised text for bad oclAsType in 11.2.5 should return null.

Issue 6532 resolved that oclAsType in 7.5.9. return a Classifier. The changed specification has OclType.

Issue 7341 is correct.; invalid should be returned by oclAsType when the type
does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly
uses t rather than T.
Issue 6532 specified an 'instance of Classifier' return for oclAsType. The
convenience document has not been updated.

The expression

'a'.oclAsType(String)

is not well-formed since the invocation of oclAsType is an OperationCallExpCS[E] for which String must be an OclExpressionCS.

String is intended to be a literal expression with a Classifier value, but there is no well-formed OclExpressionCS that can represent such a value.

Syntactically:

String could be a VariableExpCS but is not the name of a visible VariableDeclaration.

String could be a PropertyCallExpCS[B or C] or AssociationClassCallExpCS[B] but is not the name of a property.

A TypeLiteralExpCS is required to allow use of at least typeCS[A] and more flexibly any typeCS.

In 9.3 LiteralExpCS add
[E] LiteralExpCS ::= TypeLiteralExpCS
and
[E] LiteralExpCS.ast = TypeLiteralExpCS.ast
and
[E] TypeLiteralExpCS.env = LiteralExpCS.env
In 9.3 add
TypeLiteralExpCS
This production rule references a type name.
Abstract syntax mapping
TypeLiteralExpCS ::= typeCS
Synthesized attributes
TypeLiteralExpCS.ast = typeCS.ast
Inherited attributes
typeCS.env = TypeLiteralExpCS.env
Disambiguating rules
– none

Disambiguating rule 1 for TupleLiteralExp requires each VariableDeclaration to have a type and initExpression.

However some examples in 7.5.15 omit the type, which is easily inferred from the initializer.

However neither 8.3.7 nor 9.3 specifies this inference.

Presumably the type is optional and to be inferred when omitted.

The synthesized attributes for VariableDeclarationCS should infer when possible.

The definition of the CollectionRangeCS grammar is

CollectionRangeCS ::= OclExpressionCS[1] ‘,’ OclExpressionCS[2]

but everywhere else the operator is '..'

Suggest change to

CollectionRangeCS ::= OclExpressionCS[1] ‘..’ OclExpressionCS[2]

simple typo

Issue 9913 defines the missing InvalidLiteralExpCS and NullLiteralExpCS, but they are never referenced in the grammar.

Suggest:

Add to PrimitiveLiteralExpCS

[E] PrimitiveLiteralExpCS ::= NullLiteralExpCS
[F] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS

and

[E] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast
[F] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast

(not forgetting UnlimitedNaturalLiteralExpCS

Yes; resolution 9913 is incomplete

The OCL 2.0 specification would be much easier to read if:

1) The PDF had a full set of titles visible in the bookmarks:

8.3.*, Annex A.2 , Annex B and Index are missing completely.

A.1 and A.3 apppear as subsections of 13.3.

2) There are a number of large sections such as 8.3.*, 9.3 and 10.4 with unnumbered headings for each AS or CS class.
[11.5 is much better in this respect.]

These are not in alphabetical order, not page aligned and not particularly distinct.

It would be helpful to

a) give them numbers so that they appear in the Bookmarks and are more distinct.
b) put them in alphabetical order.
[c) consider page aligning them.]

[It would be good if the index was much more comprehensive too.

e.g "at", "null", "any", "iterator", "UnlimitedNatural" ...]

PDF bookmarks were fixed in OCL 2.3.
Alphabeticizing must wait until autogenerated in OCL 2.5.
Provision of a manually maintained index in OMG specifications is strongly discouraged.
Disposition: Closed, no change

The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong.

The revised text below resolves these issues

In the 3rd item of the definition A.12 (System State), the paragraph before the formula ends by :
"whereas the function i(l) projects all but the ith component):"

The function is exactly the same as the first function in the same sentence. It appears that a prime symbol is missing in the function. Indeed, a prime symbol appears in the formula.

The overline operator got lost when the Latex was FrameMakered

The symbol ≺ is used in this page. According to Unicode definition, this symbol represents a mathematical symbol whose definition is "precedes". Here is the reference of that definition :
http://unicode.org/cldr/utility/character.jsp?a=227A

I'm not a mathematician and I don't know precisely what this symbol means for mathematicians, even if I searched in many books and on the Internet. However, I find very confusing to use a symbol that means "precedes" to means "is the child of".

There is another symbol ≻ which means 'succeeds' that would be less confusing in the sense of "C1 succeeds C2" to means that C1 is the child of C2.

As I'm not mathematician, I may be completely wrong and I would greatly appreciate a sound reference where this symbol is defined formally.

The current operator has not been significantly changed by the Latex to FrameMaker conversion and so corresponds to an informed academic choice.
The requested change is less-informed and subjective.
Disposition: Closed, no change

Same diagrams are duplicated. Remove either. The referred operation:
OperationCallExpCS.ast.referredOperation =
if OclExpressionCS.ast.type.oclIsKindOf(CollectionType)
then – this is a collection operation called on a collection
OclExpressionCS.ast.type.lookupOperation(simpleNameCS.ast,
if (argumentsCS->notEmpty())
then argumentsCS.ast->collect(type)
else Sequence{} endif )
else – this is a set operation called on an object => implicit Set with one element
SetType.allInstances()->any(st|st.elementType = OclExpressionCS.ast.type).lookupOperation(simpleNameCS.ast,
if (argumentsCS->notEmpty())
then argumentsCS.ast->collect(type)
else Sequence{} endif )
endif

The unique difference, that the first diagram misses the CollectionKind.Collection
Enumeration literal. Remove the first diagram.

“ASCII or Unicode” is confusing. Use the same UML description

Initial Comment/Suggestion: Use the same UML description
Comment : Resolved by using uml infrastructure 13.2.4 definition for string type:

ObjectValue [1] The text refers to name parameter of snapshot, but LocalSnapshot in Figure 10.2 does not have “name: String” Add name parameter to LocalSnapshot in Figure 10.2.

“The value that is bound to the name parameter in the latest snapshot” implies the use of
the LocalSnapshot's bindings (NameValueBinding). Perhaps, including the word
“bindings” may avoid confusions

Figure 10.3 Explanation of TupleValue (page 107) describes its association with element, but this association is not included in Figure 10.3. Add this association to Figure 10.3

IIn section 10.2.1, the TupleValue description states the following:
“In the metamodel, this is shown as an association from TupleValue to NameValueBinding.”
Therefore the text, diagram and association description are consistent.
Disposition: Closed

I want to signal that the use of the word "meta" is confusing. Here is an example on page 47.

TypeExp
A TypeExp is an expression used to refer to an existing meta type within an expression.

According to Merriam-Webster, "meta" is usually a prefix that could be added at the beginning of a word. This particle should be merged to the main word (like in metabasis) or attached using an hyphen (like meta-analysis).

In consequence, we should read "metatype" which seems to hold the correct meaning. It is coherent with metaclass, for example. By the way, "metatype" is used at many places in the document.

In some contexts and in the familiar language, you can use "meta" as a diminutive for something when its meaning is obvious. For example, "the meta is broken" when you mean the metacarpus. In a specification document and in a context where we have to differentiate many metaconcepts, it doesn't have its place.

It is seen at many places in this document and may be other. In this one, we see "meta model" and "meta-model", while the word "metamodel" should be and is effectively used.

yes

This paragraph is confusing. It starts with Figure 10.6 but talks about elements not included in Figure 10.6. In addition it talks about “OclEvaluation” twice, which do not appear in any of the following diagrams.Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one should introduce Figure 10.7with associated elements

Initial suggestion:
Split the paragraph into two. Fist one should be just about summary of Figure 10.6, and the second one
should introduce Figure 10.7with associated elements.

On page 153 oclIsInState(statespec : OclState) is used to check if an object is in a specified state. But in Section 7.5.9 on page 22 oclInState(statespec : OclState) is used for this purpose and examples are given.

There is one more occurrence of oclIsInState on page 47 of Section 8.3.1, but this is talking about the abstract syntax, therefore it could be valid. But I think definitely not for the concrete syntax of the OCL.

Strangely enough the Eclipse Interactive OCL Console implements oclIsInState() and not oclInState().

I would appreciate a clarification which statement to use very much!

If it was a popularity contest, oclInState would win because there are many occurences in Clause 7, but Clause 7 is not normative.
Excluding clause 7, oclIsInState has two occurences to oclInState's one. More importantly, the definition in 11.3.1 is oclIsInState.
Stylistically, all other ocl-prefixed methods returning boolean are oclIs...
Let's go for oclIsInState

The term “OMG 4-layered architecture” may need to be explained or used with proper references. Modify the text as appropriate.

Not much of a title.
Anyone familiar with modeling should really know who the OMG is and what a 4-layered architecture is.
However it is surprisingly difficult to find any primary OMG references. MOF for instance refers to "a ‘Four layered metamodel architecture’ which is referred to in various OMG specifications" so maybe MOF will get some adverse comments from PAS too.

OperationCallExp. This heading should read “OperationCallExpEval.”. Modify the heading as appropriate.

Suggested action: Modify the heading as appropriate.

The last formula in the definition A.12 has unbalanced parenthesis.
The first parenthesis after the = sign seems in excess.

No Data Available

In accordance with Nicolas Rouquette's observations in the discussion on "15233 – OCL 2.2 Correction to Issue 9796 for AssociationEndCall":

The problem with OCL 2.2, Fig 7.1 are:

• give a name to the association end near Bank, e.g. 'bankAccount'
• fix the multiplicity of: Person::bankAccount from 0..1 to * – i.e., a person can have zero or more bank accounts!
• fix the multiplicity of Bank::customer from 0..* to 0..1 – i.e., there is zero or one customer for a given 'accountNumber' value.
• give a name to the association itself, e.g., BankAccount, or, if you want to use the UML notation convention, A_customer_bankAccount

and

The OCL examples for Figure 7.2, currently:

context Person inv: self.employeeRanking[bosses]->sum() > 0
context Person inv: self.employeeRanking[employees]->sum() > 0
context Person inv: self.employeeRanking->sum() > 0 – INVALID!
context Person inv: self.job[employer]

should be fixed to:

context Person inv: self.EmployeeRanking[bosses]->sum() > 0
context Person inv: self.EmployeeRanking[employees]->sum() > 0
context Person inv: self.EmployeeRanking->sum() > 0 – INVALID!
context Person inv: self.Job[employer]

That is, 'EmployeeRanking' is the name of the association shown in Fig 7.2
That figure does not have anything called 'employeeRanking' and it is misleading to suggest that in OCL the name of the association could be written with a lowercase initial letter when the name of the association itself has an initial capital letter. Since lexical names are case-sensitive in both UML and OCL, case-sensitivity should be respected to avoid creating confusion and potential ambiguity with other names that are lexically different only by their upper/lower case letter.

and

In particular, the text in clause 7.5.4 about using the name of an association class with a lowercase initial letter should be removed.
That is, change the following, currently:

To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class starting with a lowercase character:

context Person inv: self.job

The sub-expression self.job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name job used in this navigation is the name of the association class starting with a lowercase character, similar to the way described in the sub clause “Missing AssociationEnd names” above.

to:

To specify navigation to association classes (Job and Marriage in the example), OCL uses a dot and the name of the association class:

context Person inv: self.Job

The sub-expression self.Job evaluates to a Set of all the jobs a person has with the companies that are his/her employer. In the case of an association class, there is no explicit rolename in the class diagram. The name Job used in this navigation is the name of the association class.

No Data Available

The new toUpperCase, toLowerCase and equalsIgnoreCase refer to case conversion if appropriate to the locale without ever defining what a locale is or defining the preconditions for appropriateness.

These methods closely resemble Java Library methods, perhaps they should reference rather than duplicate the Java specification.

The Java toUpperCase method provides locale-dependent and local-independent variants.

Is it right for OCL to make it difficult to achieve predictable results under a Turkish locale?

It seems that the OCL standard library must provide access to the Locale and provide both Java's toUpperCase variants.

No Data Available

Collection::sum() requires that its T::+() is commutative and associative.

Associativity is necessary for predictable results.

Commutativity is not necessary, most trivially for String::+ for which sum() could usefully
concatenate an OrderedSet.

Suggest: remove the requirement for commutativity.

No Data Available

Collection::sum() requires that its T::+() is commutative and associative.

Associativity is necessary for predictable results.

However what if it isn't?

Is there an obligation on the OCL runtime to detect non-associativity and return invalid?

• probably not possible.

Is there a permission on the OCL runtime to detect non-associativity and return invalid?

• difficult to ensure implementation portability

Is there just an informal caution to users that non-associativity may lead to unpredictable results?

Suggest: reword to permit an implementation to return invalid and caution users about unpredictable results.

No Data Available

I am no longer happy with my resolution of 10439/13076 which provides a
very high resolution LALR grammar. This is inefficient to emulate with
LL and cannot provide the flexibility of configurable precedence. It
will also be very difficult to accommodate a template parameter parse
with similarly high precision. I now favour a low precision syntactic
parse augmented by high precision disambiguation/semantic checks.

If the high precision LALR grammar may need retraction, it seems
undesirable to put it into 2.3 only to remove it in 2.4.

Suggest retract the resolutions for OCL 2.3 and rewrite for OCL 2.4 once
UML-alignment of templates has been accommodated

No Data Available

In section "11.4.3 String" on p145 toLowerCase() is declared as returning Integer, correct type is String

No Data Available

I've seen, in the version 2.0, the existence of the keyword 'attr'. But then, in fact, there isn't any reference or explanation about the use of this keyword.
I've seen that this keyword is not in the new versión 2.2. But, you use it in the page 25, ln 12.

The 'attr' is a relic of a former (pre OCL 2.0) syntax.
The 'attr' should be omitted, and 'TupleType' should be 'Tuple'.

"Reject" should be replaced with "collect" in the following line:
"The value of the reject operation is the collection of the results of all the evaluations of expression-with-v."

yes

symmetricDifference: is defined as (S1 u S2) - (S1 u S2), but this always yields the empty set. I believe the intended writing is (S1 u S2) - (S1 n S2).

No Data Available

The nature of the relationship between this specification and the OCL in UML 1.4 should be clarified in an informative manner.
UML 1.4.1 needs to remain in force, because many UML models in many standards throughout the world are specified using UML 1.x notation, which is not backwards compatible with the notation in UML 2.x.
Replace:
“
This specification replaces the specification of OCL given in UML 1.4.1 and UML 1.5.
“
With:
“
This specification replaces the specification of OCL given in OCL 2.0.
The version of OCL specified in ISO/IEC 19501:2005 is intended for use in models based on UML 1.4.1 and UML 1.5. However, use of the OCL specified by ISO/IEC 19501:2005 is not prescribed by this specification.
The version of OCL specified in this International Standard is not directly applicable to models based on ISO/IEC 19501:2005. ”

No Data Available

The references need to include links to the formal OMG published specifications.

The Scope clause refers to UML 2.2, however the reference is UML 2.0

Informal references to UML 1.4.1 and UML 1.5 are included as part of explanatory text in the OCL 2.2 spec which refers to UML 1.x to explain differences of this new version of OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as an informative reference, for use in these explanations.
Change:
“
3 Normative References
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
• UML 2.0 Superstructure Specification
• UML 2.0 Infrastructure Specification
• MOF 2.0 Core Specification
• UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
«
To :
«
3 References
3.1 Normative References
The following referenced documents are indispensable for the application of this document. For dated references, only the edition cited applies. For undated references, the latest edition of the referenced document (including any amendments) applies.
• UML 2.2 Superstructure Specification <omg spec Ref URL>
• UML 2.2 Infrastructure Specification <omg spec Ref URL>
• MOF 2.0 Core Specification <omg spec Ref URL>
• UNICODE 5.1 Standard: http://www.unicode.org/versions/Unicode5.1.0/
3.2 Informative References
The following specifications are referenced in informative text:
• ISO/IEC 19501:2005 Information technology – Open Distributed Processing – Unified Modeling Language (UML) Version 1.4.2 , also <omg Spec Ref URL>
“

Change all uses of the informal UML 1.x references in the text From:
“
UML 1.x” or “UML 1.4.x”
“
To:
“
ISO/IEC 19501:2005
“

No Data Available

Nature of problem:

Informal references to UML 1.4.1 and UML 1.5 are included
as part ofexplanatory text in the OCL 2.2 spec which refers
to UML 1.x to explain differences of this new version of
OCL.. The ISO/IEC 10151 (UML 1.4.1) needs to be added as
an informative reference, for use in these explanations.

UML 1.4.1 needs to remain in force, because so many UML
models in may standards throughout the world are specified
using UML 1.x notation, which is not backwards compatible
with the new notation in UML 2.x.

Given the normative content of OCL 2.3 (after RTF
completes) is aligned technically with UML 2.4 and MOF 2.4,
its normative references should be updated before
publication of the RTF output, so that the OMG spec cross
references will remain appropriate..

The references, and their uses in the OCL 2.3spec, need to
be updated to reflect these latest UML/MOF versions.

In addition, the Output of the OCL 2.3 RTF should be
labeled as OCL 2.4, to avoid clarify the technical
alignment of OMG’s latest versions of UML and MOF.

Proposed Changes:

Change version in title to OCL 2.4.

Change all self references in the text from “OCL version
2.2” to “this OMG Specification”.

Change all references from UML 2.0 and MOF 2.0 to UML 2.4
and MOF 2.4.

In Section 1 ­ Scope Clause:

Change:
“
This specification defines the Object Constraint Language
(OCL), version 2.3. OCL version 2.3 is the version of OCL
that is aligned with UML 2.3 and MOF 2.0.
“
to
“
This specification defines the Object Constraint Language
(OCL), version 2.4. OCL version 2.4 is the version of OCL
that is aligned with UML 2.4 and MOF 2.4.
“

Section 3 ­ Normative References

Change:
“
3 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.0 Superstructure Specification
• UML 2.0 Infrastructure Specification
• MOF 2.0 Core Specification
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
«
To :
«
3 References
3.1 Normative References
The following normative documents contain provisions which,
through reference in this text, constitute provisions of
this specification. For dated references, subsequent
amendments to, or revisions of, any of these publications
do not apply.
• UML 2.4 Superstructure Specification <omg spec Ref URL>
• UML 2.4 Infrastructure Specification <omg spec Ref URL>
• MOF 2.4 Core Specification <omg spec Ref URL>
• UNICODE 5.1 Standard:
http://www.unicode.org/versions/Unicode5.1.0/
3.2 Informative References
The following specification is reference in explanatory
text, which describes differences between this
specification and the version of OCL included in the
existing standard. Its provisions do not constitute
provisions of this specification.
• ISO/IEC 19501:2005 Information technology – Open
Distributed Processing – Unified Modeling Language (UML)
Version 1.4.2 , also <omg Spec Ref URL>
“

Change all uses of the reference in the text
From
“
UML 1.x” or “UML 1.4.x”
“
To:
“
ISO/IEC 19501:2005
“

In Section 6.1 “Changes to Adopted OMG Specifications”

Replace:
“
This specification replaces the specification of OCL given
in UML 1.4.1 and UML 1.5.
“
With:
“
This specification replaces the specification of OCL given
in OCL 2.2.

The version of OCL specified in ISO/IEC 19505:2005 is
intended for use in models based on UML 1.4.1 and UML 1.5.
However, use of the OCL specified by ISO/IEC 19505:2005 is
not prescribed by this specification.

Although this issue was raised in conjunction with the First OCL 2.4 RTF that led to OCL 2.3.1, it seems appropriate to use this issue resolve all the 'boilerplate' changes for OCL 2.4.
Some of the changes outlined above occurred in OCL 2.3.1 and so need only a refresh for OCL 2.4.
The change of all OCL 2.2 references to this specification is not applicable since all references to OCL 2.2 and 2.3 intentionally refer to transitions in specified functionality.
MOF 2.0 references occur only in the boilerplate and so have been enumerated.
There are many UML 2.0 references associated with the TBD alignment with the UML 2.0 metamodel. These are very unfortunate but deserve to stay as the TBDs that they remain.

The OMG OCL 2 Revision Task force has resolved a set of defect and clarification issues against the text in DIS 19507. (Preliminary Report http://doc.omg.org/ptc/10-12-01.pdf , Change Barred Spec http://doc.omg.org/ptc/10-11-41.pdf) It is important that the corrections resolving these defects be reflected in the published ISO/IEC Standard for OCL. The editing group for OCL 2 (DIS 19607) should consider all changes against the text of OCL 2.2, resulting from RTF defect resolutions in the latest minor revision to OCL 2, approved by the OMG PTC by the time of the ballot resolution.

This is a philosophical statement without any identifiable issues. Many related issues were raised so presumably no action is necessary here.
Disposition: Closed, no change

Since you are working on the StateMachines chapter, it may be worth considering after the first submission adding an explanation about oclIsInState().
This query operation is unfortunately mispelled as oclInState(), see: http://www.omg.org/issues/ocl2-rtf.open.html#Issue15257
This query operation is confusingly listed as a predefined property and explained as an operation in OCL2.2, clause 7.5.9:

7.5.9 Predefined properties on All Objects
There are several properties that apply to all objects, and are predefined in OCL. These are:
oclIsTypeOf (t : Classifier) : Boolean
oclIsKindOf (t : Classifier) : Boolean
oclInState (s : OclState) : Boolean
oclIsNew () : Boolean
oclAsType (t : Classifier) : instance of OclType

....
The operation oclInState(s) results in true if the object is in the state s. Possible states for the operation oclInState(s) are all states of the statemachine that defines the classifier's behavior. For nested states the statenames can be combined using the double colon “::”.

I'm not sure that this correspondence on the UML RTF was really intended to be an OCL issue.
The specific oclIsInState typo is resolved by Issue 16260.
The more general discussion is appropriate for UML.
Disposition: See issue 16260 for disposition

The descriptions of CollectionRange are generally vague leaving the end inclusivities unclear.

It is only the CollectionRangeEval::getRange that provides a solid definition of well-formedness
for e.g. Sequence

as equal to Sequence

.

Unfortunately the specification is undecided about Sequence

is invalid, perhaps it should be
made useful instead, by defining .. as operating in the direction of the last wrt the first so
Sequence

= Set

.

The generalization to allow down-counts can lead to nasty surprises for e.g. Sequence

when x is empty. So just make it clear that Sequence

is invalid

Click here for this issue's archive.
Nature: Issue from PAS Ballot comment for ISO/IEC DIS 19507
Severity:
Summary:

See comment JP 5 in “…_JISC.doc” file in http://www.omg.org/members/cgi-bin/doc?pas/11-03-03.zip
Resolution:

Not much of a title.
Not much of a summary.
The referenced document jumps straight from JP4 to JP6, so no action possible.
Even if JP6 was meant rather than JP5 then we can dismiss as a duplicate of Issue 16129.
Disposition: Closed, no change

The format of normative references doesn't meet ISO format.ISO/IEC 19505-1:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 1: Infrastructure
ISO/IEC 19505-2:2011 Information technology — OMG Unified Modeling Language (OMG UML) Version 2.1.2 Part 2: Superstructure
ISO/IEC 19502:2005 Information technology – Meta Object Facility (MOF)
ISO/IEC 10646:2003 Information technology – Universal Multiple-Octet Coded Character Set (UCS)
If you want to refer OMG’s documents, see directive.

Resolved as Issue 16122. See US 1, Added 10646 as ref for Unicode. Will Fix at BRM to
most appropriate formal references, either ISO or OMG spec refs
Disposition: See issue 16122 for disposition

Regarding ptc/10-11-42 and pas/10-08-02,
It seems to be typo.

In ptc/10-11-42, 11.6.5, and
in pas/10-08-02, 11.5.5

Threre is
"A Sentence is not a subtype of Bag. The common supertype of Sentence and Bags is Collection."
^^^^^^^ ^^^^^^^^

These two "Sentence"s seem to be typo.

Substitute "Sequence" for "Sentence".

Yes. Bags is also a typo and the English can be improved

Because the content of table 2.1 is empty, this table is meaningless. Fill the table.

As the text above the table 2.1 explains, said template table is intended to be filled by OCL Tool
implementors.
Disposition: Closed