In section 11.5 "Operations and Well-formedness Rules" for the five standard PrimitiveTypes Boolean, Integer, Real, String, and UnlimitedNatural, we have specifications for logical comparison operators <, >, <=, >= but no specification for the equality operator.

It seems to me that if these operators must be explicitly implemented by tools, they must also implement a method for equality which should be specified. In C++, this is of course necessary. The operation String::equalsIgnoreCase(), for example, depends on it directly:

"Queries whether s and self are equivalent under case-insensitive collation.
post: result = (self.toUpperCase() = s.toUpperCase())"

Issue 12948 "Making OclAny denote any object" was resolved to allow Collection to conform to OclAny.

A.2.6 still states "A simple set inclusion semantics for subtype relationships as described in the next sub section would not be possible due to cyclic domain definitions if OclAny
were the supertype of Set(OclAny)."

A premise for Annex A has therefore been violated requiring rework to consider at least a less simple set inclusion semantics.

According to section 9.3.49, there are two forms of comments, line comments (-- this is a comment) and paragraph comments (/* this is a comment */):

It is possible to include comments anywhere in a text composed according to the above concrete syntax. There will be no
mapping of any comments to the abstract syntax. Comments are simply skipped when the text is being parsed. There are
two forms of comments, a line comment, and a paragraph comment. The line comment starts with the string ‘--’ and ends
with the next newline. The paragraph comment starts with the string ‘/’ and ends with the string ‘/.’ Paragraph
comments may be nested.

In section 7.4.12, only the syntax for line comments is described:

Comments in OCL are written following two successive dashes (minus signs). Everything immediately following the two
dashes up to and including the end of line is part of the comment.

For example:
– this is a comment

The two possibilities should be mentioned in 7.4.12.

Fig 10.2 presents some classes that to the best of my knowledge have never been used in an OCL implementation. The LocalSnapshot is a possible way of reconciling the need for two distinct system states when evaluating @pre or oclIsNew. It is however perhaps no more than some draft thoughts. Some much more promising work has evolved as 'Filmstrip's in conjunction with the USE tool. A Filmstrip supports OCL expressions that apply across time.

The LocalSnapshot and associated support are absolutely not a normative part of an OCL implementation.

OCL25-80 comment 1 identifies that the xxxValue classes are misleading and could be trivially rephrased as "xxx value semantics".

Similarly the xxxEval classes are unhelpful and could be triially rephrased as "xxx evaluation semantics".

Simple or efficient implementations of OCL have no need to reify each evaluation as an instance, the execution can just return the appropriate result. Only an implementation with rigorous tracing for debugging or incremental execution need reify the execution and the implementation should be free to choose its own implementation details.

There is absolutely no need for a normative existence of xxxEval classes. Only the semantics is normative.

Figure 10.5 StringValue only appears here. No explanation was given before the diagram. Add definition or explanation of StringValue before this diagram

Special Types violate UML Generalization Semantics The definition of OclAny as a general of all classes in the UML model and of OclVoid and OclInvalid as specializations of all classes in the UML model are in violation of the semantics of generalization. Classifiers in the UML may only specialize other classifiers of the same or a conformant metaclass. From the description of Classifier in the UML: [3] A classifier may only specialize classifiers of a valid type. self.parents()->forAll(c | self.maySpecializeType(c)) [8] The query maySpecializeType() determines whether this classifier may have a generalization relationship to classifiers of the specified type. By default a classifier may specialize classifiers of the same or a more general type. It is intended to be redefined by classifiers that have different specialization constraints. Thus, it is not valid for OclAny (an instance of the AnyType metaclass) to be the general of any other class. Likewise, OclVoid and OclInvalid may not specialize any other class at all. This could be corrected in OclVoid and OclInvalid by redefining the maySpecializeType() query. For OclAny, the solution is not so straight-forward, as I don't see that OCL can redefine maySpecializeType() on behalf of the UML metaclasses; according to Section 7.4.4, it is not permitted to attempt to define an additional operation that clashes with an intrinsic operation of the context classifier.

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".

Section 8.3.8 neglects to specify what it means for allInstances to be invoked for a Classifier that does not have a finite number of instances.

The Real/Integer/UnlimitedNatural/String PrimitiveTypes, CollectionType, TupleType, DataType, ,,, overloads could reasonably return invalid or an empty Set. Just need the specification to say which by specifying each of the overloads in Section 8 / 11.

Overloading Classifier::allInstances() with a crash (invalid) seems unkind, so suggest the empty set to avoid users needing to exclude many metatypes in a many-classifiers loop..

The flawed resolution of issue 8937 introduced Section 7.5.10 in which it is suggested that :: is an operator that can be contrasted with the . object navigation operator.

It isn't. It is a name qualification operator allowing e.g. A::B::C::d to clearly locate a feature with respect to any prolematic name clashes.

If :: is an invocable operator, which of the :: in A::B::C::d are to be executed, and how?

As a qualification operator the referredOperation/referredProperty field in an OperationCallExp/PropertyCallExp is assigned at compile-time to the unambiguous resolution of the qualified reference. No extra execution for the qualification.

The flawed resolution of issue 8937 introduced Section 7.5.10 and the Employee::id() example that invokes the static Employee::uniqueID() to initialize each Employee instance with a presumably distinct unique id.

This can only work if uniqueID() returns a distinct value from each call. It is therefore not a query and not side-effect-free. It cannot be invoked from OCL.

Unless the execution semantics introduces some new magic static-time between load-time and run-time in which a side-effecting static semantics is defined and supported, this is impossible. No idea how this could be made deterministic on a multi-processor execution engine.

Rather we need to be declarative and do everything at once, rather than one at a time imperatively.

context Employee
static def: allEmployees : Sequence(Employee)
= Employee.allInstances()->asSequence()
def: id : String
= 'ID' + allEmployees->indexOf(self).toString()

The quadratic cost of indexOf can be avoided if we have maps and co-iterators:

context Employee
static def: employee2index : Map(Employee,Integer)
= Employee.allInstances()->collectByValue(key with value | key)
def: id : String
= 'ID' + employee2index->at(self).toString()

An optimized execution engine could recognize the idiom and optimize away the single use static Map.

toString() is a familiar debug facility that OCL currently provides ony for logical / numeric usage. This is unfriendly.

Better to provide toString() for all values including null and invalid, with a carefully designed formatting to ensure that a monotonic forward/reverse round trip is possible.

(OCL25-75 vaguely suggests toString()).

The Isabelle evolution for Annex A highlight two errors in the OCL 2.4 clarifications.

OclVoid::oclIsKindOf/oclIsTypeOf should return true/false rather than invalid.

? oclIsKindof true for all types except OclIsInvalid.

There seems to be some confusion in ptc-13-08-13 regarding the relation of OclAny to other OCL types. Sections 8.2 and 11
state that it is a supertype of all other OCL types, including collection and tuple types, but Annex A excludes collection/tuple types from inclusion in OclAny.

in UML the rules for distinguishable names are:

• Have different Names
• Same Names but different Types
  metaclasses are different
  Neither is a (direct or indirect) generalization/specialization of the other
  (e.g. Operations distinguished by signature)

so we can have a class Person and a DataType Person... each could have an association to it... so the association end implicit name is the same... and would need to be differentiated by its Type... this is not currently supported in OCL