7.4.6 states: If the actual type of the object, at evaluation time, is not
a subtype of the type to which it is re-typed, then the result of oclAsType is invalid.

7.5.8 states: self.oclAsType(A).p1 – accesses the p1 property defined in A - this is incompatible with the no-class-change-to-A so A::p1 is not available for null.

But the normative 11.3.2 states: oclAsType(type : Classifier) : T
Evaluates to self.

The OCL 2.4 contribution to 11.3.2 was a typo. It should be "evaluates to invalid".

Languages such as Groovy have found it helpful to intrioduce the safe navigation operator ?: so that navigation over null yields null rather than a problem (invalid in OCL).

In OCL it could be a pure syntax sugar:

(x?.y) = (if x == null then null else x.y endif)

or perhaps an additional PropertyCallExp operator

Issue 15836 suggests that a negative CollectionRanbge should be invalid even after considering the Sequence

->forAll idiom.

The idiom clearly requires that a negative range gives an empty range.

OCL 9.4.5 gives no recommendation on how to handle the multiple out capability of UML.

Suggest that the mapping of a UML operation with out or inout parameters to an OCL operation do the following:

remove all 'out' parameters from the OCL parameter list so that the OCL parameter list contains only 'in' and 'inout' parameters with 'read-only' behavior

change the return type to a Tuple whose part-names and types are determined by the conventional 'result' and the 'out' and 'inout' parameters.

It is also desirable to relax the upper multiplicity bound to allow multiple bodyExpressions in Complete OCL, one bodyExpression per returning parameter.

OCL 12.10 awaits alignment with the UML 2.0 metamodel.

Consequently, the relationship between a result-valued OCL bodyExpression and a Boolean-valued UML bodyCondition is unspecified. A common pragmatic resolution has been to equate the two and ignore the Boolean-valued requirement of a UML Constraint.

In order to accommodate prevailing practice and also support UML's multiple out/inouts, suggest:

Reinterpret the grammar

prePostOrBodyDeclCS ::= ‘body’ (simpleNameCS)? ‘:’ OclExpressionCS

such that

the simpleNameCS is the name of the return parameter with 'result' as the anonymous default

OclExpressionCS is a result-valued bodyExpression if OclExpressionCS does not reference the simpleNameCS or its defgault.
OclExpressionCS is a Boolean-valued bodyCondition if the return parameter is referenced.

[Allow multiple body declarations.]

Thus

"body: ..." is a shortform of "body result: ..." which is a shortform for "body result: result = ..."

and

body: ...
body A: ...
body B: ...

could be the specification of a UML operation

f(out a : A, inout b : B, in c : C) : Z

In order for a UML model to import some Complete OCL for use in the model's constraints, a Complete OCL document must be a (derived) Package. Any tool can therefore import Complete OCL using its conventional metamodel import syntax; just needs per-tool support.

Complete OCL documents must not conflict. For instance if MM imports COD1 for its own purposes and then your usage imports MM (and COD1) and also COD2, the declarations in COD2 may not introduce anything that requires re-analysis of the OCL expressions in MM or COD1; the only change to MM+COD1 execution may arise through additional derived virtual functions.

Avoiding conflicts requires some strong WFRs.

Once conflicts are avoided, Complete OCL documents can be pre-compiled and loaded in compiled form.

In 11.6.2: "It [Set] contains elements without duplicates."

What is a duplicate?

In 10.2.2.13 SetTypeValue
"All elements belonging to a set value have unique values.
self.element->isUnique(e : Element | e.value)"

>From 11.9.1.3 isUnique, the basis of comparison is <>:
forAll (x, y | (x.iter <> y.iter) implies (x.value <> y.value))

But what is the Element::value to which "<>" is applied. It is far from clear that the semantics of the Element in Section 10 which is completely unrelated to MOF::Element leads to the obvious answer.

Suggest adding the obvious WFR.

context Set
inv: forAll(x | self->count = 1)

(count is already defined using "=")

[And chnage 11.9.1.3 isUnique to use this much more readable formulation.]

A.5.1.5 suggests that an invariant may be specified for many contexts. The Complete OCL syntax does not support this.

Many users like to write grandiose truths:

context X
inv: X.allInstances()->...

These do not use the context and so naively increase the complexity from O(N) to O(N*N).

Suggest allowing such constraints to be context-less constraints provided by the Package rather than a spurious Classifier.

The OCL expression syntax is difficult to extend for other purposes. The @pre postcondition operator, and the ^,^,? tokens are examples of extension of the core syntax.

Perhaps @pre could be generalized as an instance of an @token

suffix which could be parsed as an AnnotationExp for tooling to ignore but support extension for.

Can more arbitrary punctuation such as ^,^,?,#,% be generalized?

Please add that the StateSpec may include the names of Regions.

The name of the predefined property is "oclInState" according to chapter 7.6.9. In chapter 11.3.1 the name "oclIsInState" is used.