Ed Willink , the driving force behind the standard AND implementation tasks for the OCL language has just announced the availability of OCL 2.4. According to Ed:

The OCL 2.4 specification has now been formally adopted and is available from http://www.omg.org/spec/OCL/2.4/.

The revision contains the easy maintenance changes that can be done now prior to the move to a model-defined specification for OCL 2.5. The more significant fixes are outlined below. All changes can be seen in the change-barred version of the specification.

The implicit to set conversion has been clarified as a shorthand for the new library operation OclAny::oclAsSet(), which has OclVoid and OclInvalid overloads. Use of “->” on a non-Collection therefore always converts to a Set of the source. The Set is empty for a null source, and invalid for an invalid source.

=() and <>() are clarified to compare DataTypes by value and Classes by object identity. true is now always equal to true and 1 is now always equal to 1.0.

The spelling of oclInState/oclIsInState is resolved to be oclIsInState.

String::indexOf() now considers an empty String to be a substring of any String.

The logical operations involving null no longer violate idempotency. not null is therefore null.

The conflict between ‘all operations are strict’ but ‘some operations are non-strict’ is resolved by explicitly defining all OclVoid and OclInvalid overloads.

The non-strict behavior of ‘and’ and ‘or’ has been explicitly carried over into ‘forall’ and ‘exists’ which are defined in terms of ‘and’ and ‘or’.

Ambiguity in Collection::any() has been removed to require an invalid return in the absence of a match.

A reverse CollectionRange such as 1..0 is now defined to be invalid; previously the well-formedness rule looped forever. Oops; it was realized too late that the Sequence{1..x->size()} idiom requires a reverse CollectionRange to be empty. Issue 18985 raised; hopefully fixed in OCL 2.5.