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

Issue 12953 made changes to the CollectionLiteralExpCS grammar and these appear in OCL 2.3 but not in OCL 2.4.

It would appear that some major editorial snafu occurred while reconstructing a FrameMaker base for OCL 2.4 after the OCL 2.3.1 corruptions.

Application of OCL 2.2, 2.3, 2,3.1, 2.4 changes need to be checked to understand the snafu.

Typo in sentence "If the constraint is shown in a diagram, with the proper stereotype and the dashed lines to connect it to its contextual
element, there is no need for an explicit context declaration in the test of the constraint."

test should be text

The sortedBy iteration provides an elegant solution to a sort problem in which the sort metric is a projection of the sorted object. Thus sortedBy(p|p.name) or just sortedBy(name) is short and avoids the opportunities for typos from a more conventional exposition involving comparison of two objects. The natural solution may well be an efficient one for large collections with non-trivial metrics.

However the sortedBy solution is unfamiliar and so confusing for newcomers and unsuitable for multi-key sorting for which an artificial compound single key may need to be constructed.

One solution might be to provide a more conventional iterator such as sort(p1, p2 | comparison-expression) allowing a two key sort:

sort(p1, p2 | let diff1 = p1.key1.compareTo(p2.key1) in
if diff1 <> 0 the diff 1 else p1.key2.compareTo(p2.key2) endif)

However this has poor readability and ample opportunities for typos.

Alternatively sortedBy with a Tuple-valued metric might support multiple keys as:

sortedBy(Tuple

)

(The alphabetical order of the Tuple part names determines the priority.)

(Since sortedBy is declaratively clear and compact, inefficient small/trivial implementations can be optimized to their sort() equivalents.)

The following problems are common to all definitions of sortedBy in 11.9:

Invalid algorithm:

• When the current element is not the first one, but is the
  greatest one so far, for example 2 in
  Sequence {1,2}

  ->sortedBy(x|x),
  then
  result->select (item | body (item) > body (iterator))
  is empty and calling ->first on it would result in invalid.

Inconsistent use of < and >:

• The text descriptions mention using < operation on the elements,
  but the algorithm uses > operator.

Typos:

• The accumulator initialization incorrectly uses : instead of =.
• The source for the iterate expression is missing.
• The closing parenthesis for the iterate expression is missing.
• The operations append and insertAt are called by . operator.

SOLUTION:

• Introduce a new local variable upperBounds, containing elements from the
  accumulator that are greater than the current element.
• Swap body (iterator) and body (item).
• Fix typos.

Corrected algorithm for Set (11.9.2) and OrderedSet (11.9.5):

****************************************
source->sortedBy(iterator | body) =
source->iterate( iterator ; result : OrderedSet(T) = OrderedSet {} |
let upperBounds : OrderedSet(T) =
result->select (item | body (iterator) < body (item) )
in
if upperBounds->isEmpty() then
result->append(iterator)
else
let position : Integer = result->indexOf ( upperBounds->first() )
in
result->insertAt(position, iterator)
endif
)
****************************************

Corrected algorithm for Sequence (11.9.4) and Bag (11.9.3):

****************************************
source->sortedBy(iterator | body) =
source->iterate( iterator ; result : Sequence(T) = Sequence {} |
let upperBounds : Sequence(T) =
result->select (item | body (iterator) < body (item) )
in
if upperBounds->isEmpty() then
result->append(iterator)
else
let position : Integer = result->indexOf ( upperBounds->first() )
in
result->insertAt(position, iterator)
endif
)
****************************************

FURTHER SUGGESTIONS:

• The presented algorithm works only under assumption that indexOf(obj:T)
  on Sequence(T) returns the first occurence. This is not mentioned in the
  definition of indexOf. If indexOf can return any index, for example:
  Sequence {2, 2}

  ->indexOf(2) = 2,
  then the above algorithm could insert the element at the wrong place,
  for example:
  Sequence

  {2, 2, 1}

  ->sortedBy(x|x) = Sequence

  {2, 1, 2}
• The algorithm is stable for Sequence and OrderedSet, this fact could be
  mentioned in the description, to make it clear that successive
  sortedBy iterations can be used to sort by multiple criteria.

The pseudocode for OrderedSet::insertAt assumes that the inserted element is not already contained.

Presumably insertion of an existing element does not increase the OrderedSet size.

Design choice. Is the old element retained or is the old element removed and the new element inserted? The latter might preserve the postcondition that the element at the index is the inserted object, but what if the removed element was earlier so that everything moved along first?

Surely the only predictable behavior is that the old element is retained?

"asSequence" and "asOrderedSet" are specified as returning an unknown ordering. How deterministic is this? repeatable with the same tool version, the same tool, the same CPU, the same number of CPUs, any OCL tool?

"any" is specified as indeterminate.

Non-determinism is a very bad language characteristic.

Surely "any" should be the earliest element in asSequence()?

If a tool avoids anarchic sets, perhaps keeping a list and set for each 'set', the resulting behavior can be deterministic. But is specifying deterministic set evaluation algorithms appropriate for the OCL specification?

Suggest the specification should just require that a re-execution with:

• the same tool version
• the same Operating System etc
• the same single CPU
• the same command line options
  shall give the same result (unknown but deterministic).

OCL is an executable specification language that uses "invalid" as its exception handling mechanism for untoward execution, which clearly includes deterministic internal program control faults:

• divide by zero
• null-navigation
• ordered collection index out of bounds
  Does this behavior also include non-deterministic external problems:
• network/disk access failure
• stack overflow
• tooling malfunction

Without an answer to this question, it i impossible to know whether e.g. "aSequence->includes->last()" can be optimized to "x" or not. Is it necessary to fully evaluate aSequence, perhaps run out of memory, in order to incur an external issue that influences an evaluation?

The % (modulo/remainder) operator is realtively standard operator in many langages. It is missing from the OCL Standard Library. There is only Integer::mod().

QVTo 1,3 8.4.4 4 implies that there is a % modulo operator even though there isn't. See QVT14-44.

Suggest add Real::%

UML/OCL hardwire three capabilities of an Operation.

"body" is very useful
"precondition", "postcondition" are sometimes useful
anything else is unsupported.

Some users want frame conditions.

Code generation/analysis wants other forms of meta-evaluation.

Rather than expand the hardwired options, allow an Operation to have an extensible set of named capabilities.Some names such as "body", "precondition", "postcondition" can be standardized. Others could be reserved in anticipation.

A UML InstanceSpecification introduces classification within the M1 level. OCL is normally applicable to inter level typing. M0/M1 or M1/M2.

Does anInstanceSpecification.oclIsKindOf(XXX) use a same-level or meta XXX?

Does anInstanceSpecification.YYY use the YYY feature of the InstanceSpecification metaclass or any one of the anInstanceSpecification.classifier?

Is a new navigation operator needed to distinguish the two cases?

Practical evaluation of stereotypes requires OCL to reify the Stereotype instances. These instances should be accessible by Stereotype.allInstances().

e.g. if an ElementExtension is the Stereotype instance and Element.extensions are the applied stereotypes.

Stereotype.allInstances() is equivalent to

Element.allInstances().extensions->selectByKind(MyStereotype)

The last sentence of the first paragraph on page 37 says "All metaclasses defined as part of the OCL abstract syntax are shown with a light gray background.", but subsequent abstract syntaxs show OLC defined metaclasses in yellow

asOrderedSet() : OrderedSet(T)
Redefines the Collection operation. An OrderedSet that contains all the elements from self, in undefined order.

If asOrderedSet() is invoked more than once on the same Set, then presumably the subsequent calls have a defined order; the order previously used.

When used by QVTo the lack of determinism of Set ordering is a significant debugging nuisance. Suggest that there is a repeatable but unspecified underlying order determined perhaps by object creation order.

object.assoc[qualifier] returns a particular element from a qualified association.

With Map already suggested/prototyped for OCL, let object.assoc[] return a Map<qualifier,element> that avoids the loss of information from object.assoc that returns Collection<element>

null-in-Collections was added by the OCL 2.0 FTF in Issue 5972 in the unanalyzed hope that it would be useful.

https://ocl2015.lri.fr/OCL_2015_paper_0921_1400.pdf examines the null safety of OCL nad concludes that an ability to declare null-free collections is essential.

Since almost all collections in practical OCL are null-free, suggest that the OCL default should be for null-free collections, with an option to have null-full collections when really needed.

The spec defines the following postcondition for the append/prepend operations on OrderedSet:

result->size() = self->size() + 1

However, if self does already contain the added element, the size does not increase by one since the elements are unique.

Issue 14918 went most of the way to clarifying '=' behaviour.

But the Real::'=' and Real::'<>' overloads were omitted.

Consequently the fix to ensure that 1.0 = 1
evaluates to true when (1.0 <= 1) and (1.0 >= 1) will evaluate true is missing.

Change to identified

The example of collect in terms of iterate given in section section 7.6.6 is not flattened. Actually it is a copy of the definition of collectNested in section 11.9.2.

The Issue 17220 clarification that the empty string is a substring at index 1 failed to revise the postcondition that the index of of any string in the empty string is at index 0.

Replace:

post: self.size() = 0 implies result = 0

by

post: self.size() = 0 and s.size() > 0 implies result = 0

and move it to the second postcondition

In Integer::/ change "r is equal" to "i is equal"

Add isInteger/isReal predicates to avoid need to test invlaid on toInteger/toReal

Add isBoolean/toBoolean/toString

The clarification of Issue 15836 is too strong.

For an empty collection it is im,portant that

let s = Sequence{} in Sequence

is Sequence{}, i.e. the valid indexes of an empty Sequence are empty not invalid.

The non-normative text defines iterate() and suggests that all iterators may be defined in terms of iterate() and notes that the use of iterate() on Bag/Set is indeterminate.

The normative text omits iterate() and states that all iterators are defined in terms of iterate().

Suggest: Add iterate() to Section 11.

Suggest: explicitly asSequence() all unordered iterate() inputs.

Suggest: retract availability of iterate() on Bag/Set forcing an explicit asSequence().

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.

Descriptions of Collection::InEmpty(), notEmpty() refer to the implicit cast to Bag rather than use of oclAsSet().

Add not oclIsInvalid() precondition on all non-Collection inputs.

e.g including(object : T)

pre: not object.oclIsInvalid()

To Integer::mod all

pre: i <> 0