Nearly a year ago we put the UML OCL through Eclipse OCL and were able to eliminate 'all' (many hundreds of) syntactic errors and many semantic errors. Not all semantic errors, because Eclipse OCL is steadily adding stronger WFRs. Since then the authors have been using Eclipse OCL in the guise of IBM RSA and the errors have stayed away. Final checks of the UML 2.5 candidate UML.xmi identified only one semantic error.

Your report is marginal as a semantic error; perhaps a warning would be appropriate for the useless compare. I suspect an inadequacy in the Eclipse OCL determination of the application OCLAny::= specialization.

Realistically UML 2.5 paves the way for the start of a virtuous circle as feedback identifies the outright functional errors that occur when validating real models and the much harder inadequacies where the constraints are too weak.

issue already raised in the UML 2.6 RTF

A very common 'idiom' in OCL expressions is

sources->select(oclIsKindOf(T))>collect(oclAsType(T))>asSet()

to select the sub-set of type T.

This involves four library calls and requires T to be typed twice.

In practice

sources->select(oclIsKindOf(T)).oclAsType(T)

may save one operation call at the expense of the wrong collection type.

Suggest introduce

sources->selectByKind(T)
sources->selectByType(T)

to simplify this oclIsKindOf/oclIsTypeOf usage.

This is clearly useful:
Acceleo (but not MOFM2T) provides "filter".
The Dresden OCL team in http://gres.uoc.edu/OCL2011/pubs/ocl2011_submission_3.pdf suggest "selectByType" and note that QVTo provides "collectselect"
"filter" is nice and short but fails to fulfill the expectation that the argument should be some general predicate not an unmentioned type.
oclIsKindOf and oclIsTypeOf are already there and so unless they are to be changed, additions should be compatible and re-inforce the "KindOf"/"TypeOf" distinction..
There are two distinct algorithms: exact type and polymorphic type so
selectByType and selectByKind are consistent.
selectByType clearly can include/exclude OclVoid at will.
selectByKind probably doesn't want to include null elements even though null conforms to everything, so QVTo's collectselect exclusion is worth emulating.
There seems no need to introduce rejectByKind and rejectByType too, since there is no associated type conversion; reject will do.
The correct declarations should be:
selectByKind(TT)(type : Metaclass(TT)) : Collection(TT);
selectByType(TT)(type : Metaclass(TT)) : Collection(TT);
These use an operation template type TT to model the type relationship between the returned Collection element type and the metatype provided as the operation argument. Unfortunately we cannot use this until OCL '2.5' aligns with UML templates and introduces templated Metaclasses.

The accumulator in the definition of Collection::min and Collection::max is initialized as self.first().

post: result = self->iterate( elem; acc : T = self.first() | acc.min(elem) )

post: result = self->iterate( elem; acc : T = self.first() | acc.max(elem) )

The accumulator should be initialized as self.asSequence()->first(), because Collection::first() is undefined.

Nearly right.
self is of course a Collection, so needs to be self->asSequence()>first(), or just self>any(true).

Section 11.9.1.4 states that "there must be at least one element fulfilling body, otherwise the result of this IteratorExp is null." And defines

source->any(iterator|body) = source->select(iterator | body)>asSequence()>first()

However

let seq:Sequence<T>=source->select(body)->asSequence()
in source->any(body)=seq->at(1)

>From section 11.7.5

context Sequence::first() : T
post: result = self->at(1)

context Sequence::at(i : Integer) : T
pre : i >= 1 and i <= self->size()

If there is no element fulfilling body, then seq is empty and the precondition of Sequence::at does not hold because 1 > seq->size().

Related to: Issue 18125 [OCL 2.4]

The 'equivalent' OCL of
source->select(iterator | body)>asSequence()>first()
returns invalid if no elements are selected, rather than null as the words say.
As identified in Issue 18125, null could also be a valid value, so the words are clearly wrong.

"The returned collection of the closure iteration is an accumulation of the source, and the collections resulting from ..."

incorrectly includes the source. The algorithm in 11.9.1 correctly includes the source only if the source is reached by some traversal from the source.

No. The algorithm in 11.9.1 only adds the source to the result if the source was not already present. Since the anonRecurse starts with an empty result all sources are accumulated.
Just need to polish the words to avoid similar misunderstandings in the future

There is a contradiction between invalid conform to anything and invalid always propagates for e.g.

Sequence{}->first().oclIsKindOf(Class)

oclIsKindOf uses the invalid input to return true.

Invalid propagation should dominate giving invalid.

This requires OclInvalid::oclIsKindOf, oclIsTypeOf, oclType, oclAsType overloads to explicitly return invalid.

(A) It is clearly correct that OclVoid/OclInvalid conform to anything so that null/invalid can be used anywhere.
(B) It is also clearly correct for navigation on null and invalid to be invalid so that bad results propagate.
The above are not contradictory. The contradiction arises through the introduction of the oclIsInvalid() and oclIsUndefined() operations that may be used on null or invalid, despite (B).
It would appear that oclIsInvalid() and oclIsUndefined() must be privileged to violate the strictness of (B). If so, are oclIsKindOf, oclIsTypeOf, oclType, oclAsType etc. also privileged?
The specification can be clarified by making all oclXXX() operations privileged so that they can be used on null and invalid and defining their OclVoid and OclInvalid overloads explicitly.
The affected text can be clarified to eliminate the accidental omission of operation calls for null and invalid.
The affected text covers the DataType equality issue so the resolution of Issue 14918 is included

post: (result = self) and result.oclIsTypeOf( t )

requires oclAsType to change the type of self.

The constraint should be:

post: (result = self) and result.oclIsKindOf(t)

[Review all usage of oclIsType() since it's nearly always wrong to use oclIsType rather than oclIsKindOf.]

Should indeed be oclIsKindOf and the argument should be 'type' as in the signature.
Reviewing other oclIsTypeOf uses identifies just one clear error in 8.2.1 since CollectionType has derived SetType and other types. Other usages seem to be either ok but inelegant since the type is a leaf type, or deliberate constraints for an invariant

The any() iteration is specified to return null in the event that no match is found. However null could also be the return of a successful match of null. e.g

Sequence

->any(s | s = null)

Suggest: change the match-not-found return to invalid.

The resolution of Issue 18504 solves this too.
Disposition: See issue 18504 for disposition

In http://www.linkedin.com/redirect?url=http%3A%2F%2Fwww%2Ebrucker%2Ech%2Fprojects%2Fhol-ocl%2FFeatherweight-OCL%2Foutline%2Epdf&urlhash=vacm&_t=tracking_anet Burkhart Wol ff argues that lopgical consistency requires that not(not(X)) is X.

OCL 2.3.x does not satisfy this for 'null'.

Similary null and true = null not invalid ...

Issue 14197 for OCL 2.3 rationalized the vague equivalences between undefined and null/invalid.
In OCL 2.0, it was left for the implementer to determine how "not null" and "not invalid" were computed given the specification that "not undefined = undefined".
In OCL 2.3, we have clarity: "not null = invalid" and "not invalid = invalid". However this leads to the identified inconsistency that "not not X = X" is not true for all X (not not null = invalid).
The clarification of "not undefined" should have partitioned the two cases for "not undefined = undefined" so that "not null = null" and "not invalid = invalid"
Similarly other logical operations involving null but not invalid should yield null rather than invalid results. "null and true = null", "null or false = null", "null xor false = null".
We should extend this to the forAll and exists iterations that are defined as iterated and/or. Making the exists/forAll returns clear highlights that many iterator returns are only partially specified; these need expanding.
Introduction of null highlights a redundancy in the non-standard implies postcondition: (not self) or (self and b) rather than the standard (not self) or b. The standard gives the consistent result "null implies true = true" whereas the current non-standard postcondition gives null. The non-standard postcondition is already wrong for invalid.
The If expression specification words omit consideration of a non-valid condition; a null or invalid condition is of course invalid.
For arithmetic operations there is an apparently free choice between two alternate consistent logics in which "1 + null = null" or "1 + null = invalid".
"1 + null = null" is plausible if "null" denotes "don't know"; an object/value that exists but with unspecified value.
"1 + null = invalid" is plausible if "null" denotes "missing"; the absence of an object/value.
However UML provides the interpretation of "null" as "missing". UML-alignment of OCL therefore requires OCL to take the "1 + null = invalid" alternative, which is what the Issue 14197 clarification specified. So no change required for arithmetic operations.

The navigation from Association Classes does not conform to UML 2.4.1 because of 7.3.4 AssociationClass on page 44 UML Superstructure Specification, v2.4.1. the kind of navigation allowed by OCL is not allowed by UML, i.e. the navigation from the association class to the ends of the association is explicitly not allowed by UML but allowed by OCL. I see here a contradiction. I checked UML 2.1.2 from 2007 and in that UML this navigation from the association class the ends of the association was still allowed. I think that OCL 2.3.1 is not compatible with UML 2.4.2 from this point of view. Please tell me if this opinion is correct. If this contradiction that I remarked really exists than what to expect from the future: OCL or UML point of view?

The apparent prohibition in UML 2.4.1 is not present in UML 2.5 Beta.
The problem is a misunderstanding. OCL expressions are resolved at 'modeling-time' against the model and so are not restricted by visibility or any practical limitations that may occur at run-time.
Disposition: Closed, no change

ISO 639 has been replaced by a six-part series. The new reference should be: ISO 639 (all parts)
ISO 3166 has been replaced by a three part series. The new reference should be: ISO 3166 (all parts)
ISO 10646 is new and this reference should be: ISO 10646:2011, Information technology - Universal Coded Character Set (UCS)

yes

The description of String::indexOf() states "No string is a substring of the empty string.".

This modifies the axiom that every string is a substring of itself. It would appear that the empty string has got confused with null.

An extension of the library with startsWith and endsWith operations would require the modified axiom to be accommodated making corner cases equivalently strange.

This modified axiom is not observed by other String libraries such as the java.lang.String.

Suggest: Replace the text:

"The empty string is considered to be a substring of every string but the empty string, at index 1. No string is a substring of the empty string."

by

"The empty string is a substring of every string at index 1 (and also at all other indexes)."

yes

Issue 14197 finally resolved the semantiscs of OclInvalid, but the end result was that there is no OclInvalid section in 11.3. Add an 11.3.x for OclInvalid that enumerates all relevant OclInvalid behaviors; in particular = and <> return invalid for any invalid argument.

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