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.

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

A Collection containing both 'a', and

must be typed as a
Collection of OclAny since that is the only common type.

This is unhelpful for tree structures.

Suggest introduction of a pseudo-collection type Tree(T) to which
both T and Collection(Tree(T)) conform.

A String content tree then then be declared as a Tree(String).

12: Why no applicability to Essential MOF models?

Although EMOF::Operation has no precondition feature, there is no problem in an operationContextDecl imposing a truth upon the operation.

Similarly, if Initial value and Derived values are defined as Constraints in the same way as PreConditions, then the propertyContextDecl can constrain EMOF by imposing a truth upon the Property.default : String even though String is not an Expression

Sections 12.5.1, 12.6.1, 12.7.1 specify the "invariant", "precondition", "postcondition" spellings.

Sections 12.8, 12.9, 12.10, 12.11 do not specify their corresponding spellings.

Suggest: "initial", "derivation", "body", "guard" as the conventional adjective used to qualify "constraint".

OCL supports a '*' value for UnlimitedNatural in order to accommodate the
full range of UML multiplicities.

UnlimitedNatural conforms to Integer and Real, so that any UnlimitedNatural
conversion must perform a run-time check in order to convert '*' to invalid.
This conversion cannot be replicated in the reverse direction.

Suggest that '*' be aligned with the conventional IEEE math notion of
infinity, so that

• and -* are valid values for Integer and Real. UnlimitedNatural is then a
  simple restriction of Integer which is a simple restriction of Real.

OCL supports feature overloading and attempts to comply with UML. OCL does not define feature overloading itself. UML leaves feature overloading as a semantic variation point.

The OCL behaviour is therefore undefined. However a variety of behaviours particularly those involving null and invalid only make sense if operations are selected at run-time according to the dynamic type.

The example from an earilier pending issue:

Sequence(OclAny)

>count((-3)) = 2

wherein

UnlimitedNatural 3 widens to Integer 3 for successful comparison with Integer 3
Real 3.0 is successfully compared to Integer 3 widened to Real
String '3' widens to OclAny and fails to compare to Integer 3 widened to OclAny.

is difficult to realise if static type resolution is applicable in which case all pair-wise value comparisons would use OclAny::= rather than Real::=.

Suggest:

OCL define that features are selected dynamically at run-time.

Synthesized attributes, [D], [F], [G] The meaning of “and” at the end of the line is not clear and seems inconsistent with other parts. Are these logical operations? Add text to clarify this

Issue 12953 considered the problem of the element type of an empty collection and rejected OclVoid (Option 1) because Set{}->including(1) would fail.

This rejection is appropriate when the collection is modified as in Java, but is inappropriate for OCL where a new Collection is created. There is therefore no problem in deciding that the most derived common element type of Set{} (OclVoid) and 1 (Integer) is Integer causing Set(Integer)::including(Integer) to be invoked.

Given the following:

context MyClass
def : isaMethod() : Boolean =
let Collection(Operation) myOperations = oclType().oclAsType(Class).ownedOperations()
in myOperations->exists(name = 'isaMethod')

is the value of isaMethod() true or false?

This is a more fundamental way of looking at the AST serializability problem in Issue 12854. (The suggested referredDefinition : Constraint [0..1] will not work because there may be 3 operation constraints and two property constraints.)

isaMethod() = false: OCL defininitions are not first class features and so there is no need to support their serialization.

isaMethod() = true: OCL definitions do as implied by Section 12.5 and provide reusable sub-expressions that can be used in an identical way to an atribute or operation.

It seems that an OCL evaluation needs to be defined in the following way.

Phase 1. Load MOF/UML meta-models and OCL contributions
Phase 2: Merge OCL definitions into MOF/UML meta-models
Phase 3: Execute the OCL to support queries/invariants/... on models

Phase 2 solves 12854 by requiring a merged meta-model to reify all definitions.

How the merged model is serialized is an implementation issue

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.
Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2.

Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

The above suggests that the specification should consistently treat iterators as having a 1..2

multiplicity.

12.2 defines a syntax for a standalone OCL document, but provides no mechanism to assist an implementation in locating packages or to partition into multiple reusable documents.

a) Suggest addition of an ImportDeclarationCS

ImportDeclarationCS ::= import StringLiteralExpCS

where StringLiteralExpCS is a URI whose MOF/UML model content an implementation should make visible within the root environment.

import is a new reserved word.

b) Suggest addition of an IncludeDeclarationCS

IncludeDeclarationCS ::= include StringLiteralExpCS

where StringLiteralExpCS is a URI whose OCL document content an implementation should interpret (at most once) before proceeding.

include is a new reserved word.

c) Suggest addition of an OclDocumentCS

OclDocumentCS ::= (ImportDeclarationCS)* (IncludeDeclarationCS | PackageDeclarationCS[A])*

d) Suggest an OclPackage to own the Constraints for each Package and bypass the problem that Constriants do not have distinguishable names as required by Package content.

12.5 define a definition body as one or more LetExps. No example wraps the expression as a LetExp.
Is this an obsolete specification or an unobserved AST structural constraint?

12.5 defines synthesis of a variable or function, but fails to distinguish these from the equivalent property or operation

UML-alignment of OCL type signatures
--------------------------------------------------------

Following discussion in the "Vagueness about meaning of 0..1 multiplicity in OCL and UML" threads
of the UML2 and OCL RTFs the following problems exist in alignment of the UML and OCL type systems.

The OCL specification does not provide a clear description of the comparative semantics of for instance
Integer[1] and Integer[0..1].

The Complete OCL syntax for an Operation Context Declaration uses OCL type decalarations and so
fails to provide the same expressivity as a UML operation declaration with multiplicities.

Suggest:

a) a clear indication that

An Integer[1] may have integer values, null or invalid, of which only integer values are well-formed.

An Integer[0..1] may have integer values, null or invalid, of which integer values and null are well-formed.

b) an enhancement to the type declaration syntax to allow

Integer[0..1] or Integer[1] to indicate a nullable/non-nullable value.

Set(Integer[1..7]) to capture the expressivity of a UML multiplicity

If meta-models provide both 'B::x' and 'A::B::x', it is not possible to access 'B::x' from a context with 'A::B' since 9.4.1[4] searches from the current scope and so resolve 'B' in 'B::x' to 'A::B'.

Suggest adoption of the C++ '::' global prefix so that '::B::x' can be used when 'A::B' occludes.

(subclause [4])
It reads: let firstNamespace : ModelElement ... in ...
self.nestedEnvironment().addNamespace(firstNamespace)
It should read:
self.nestedEnvironment().addNamespace(firstNamespace.oclAsType(Namespace))
Rationale: the signature of addNamespace is (ns: Namespace) as defined in 9.4.1 subclause [7]

The OCL specification does not make clear whether an iteration over a Collection of Collections should operate on the flattened or unflattened source.

The Appendix through lack of specification and explicit specification of flattening would suggest that the iterator for a Collection of Collections is a Collection.

Most of the description in Section 7.6 is neutral through use of the term element.

However In 7.6.1 "The variable v is called the iterator. When the select is evaluated, v iterates over the collection and the boolean expression-with-v is evaluated for each v. The v is a reference to the object from the collection and can be used to refer to the objects themselves from the collection." implies that the source collection is flattened; at least in OCL 2.0 where collections were not first class objects, this is a contradiction. In OCL 2.1, collections are nearly first class objects and so perhaps there is just an ambiguity.

Similarly:

In 7.6.2 "When we want to specify a collection which is derived from some other collection, but which contains
different objects from the original collection (i.e., it is not a sub-collection), we can use a collect operation."

In 7.6.3 "The forAll operation in OCL allows specifying a Boolean expression, which must hold for all objects in a collection:"

In 7.6.4 "The exists operation in OCL allows you to specify a Boolean expression that must hold for at least one object in a collection".

Suggest that the specification of iteration avoid the use of 'object', sticking only to 'element'. A clarifying paragraph at the end of 7.6.5 should state that for a 0 or 1 deep Collection source, element is a non-Collection object. For an N-deep Collection source, element is an (N-1)-deep Collection.

OCL supports access to a variety of properties such as self.a, self.b, self.c but provides no mechanism for indirection of the property selection.

Perhaps that the standard library support reflection more effectively with:

self.oclGet(MyClass::a)

OCL allows a user to define a run-time OCL meta-model through Property and Operation definitions that is based upon a specification-time UML meta-model.

It would be useful to allow a user to also introduce inheritance/conformance polymorphisms.

Thus:

context CommonPackage::CommonObject

context CommonPackage::CommonObject::isSerializable() : Boolean = false

context OCL::String conformsTo CommonPackage::CommonObject

context MyPackage::MyObject conformsTo CommonPackage::CommonObject

context YourPackage::YourObject conformsTo CommonPackage::CommonObject

could mix-in the capabilities of CommonObject to each of MyObject and YourObject and String.

This would allow common functionality to be mixed in once and used polymorphically rather than being added in amorphously and requiring an if-tree of per-context invocations of that functionality.

Issue 9796 responded to the problem with the undefined (and undefinable) withAtPre().

However the textual replacement of ".withAtPre()" by ".isPre = true" is not valid.

For instance

[D] AttributeCallExpCS.ast.source = if isMarkedPreCS->isEmpty()
then OclExpressionCS.ast
else OclExpressionCS.ast.withAtPre() endif

should be elaborated to:

[D] AttributeCallExpCS.ast.source = OclExpressionCS.ast
[D] AttributeCallExpCS.ast.isPre = isMarkedPreCS->notEmpty()

Section 7.5.4 describes an association navigation qualification to
accommodate
recursive associations.

e.g. self.employeeRanking[bosses]

in which "bosses" is a Property role name.

OCL 2.2 has no concrete syntax for this. Superficially it resembles an
AssociationClassCallExp, but that requires OclExpression values for its
qualifiers.

Prior to OCL 2.0 (and still present in many obstinate residual artefacts in
OCL 2.2),
there was an AssociationEndCallExp, whose syntax was identical to an
AssociationClassCallExp
and so it was removed and merged with AttributeCallExp as PropertyCallExp.

It would appear that a form of AssociationEndCallExp is required with
syntaxes

OclExpressionCS '.' pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?
pathNameCS[1] ('[' pathNameCS[2] ']')? isMarkedPreCS?

in which pathNameCS[2] defines the NavigationCallExpCS.ast.navigationSource
that is currently completely undefined and very confusingly described in
Section 8.3.2:

"navigationSource The source denotes the association end Property at the end
of the object itself. This is used to
resolve ambiguities when the same Classifier is at more than one end (plays
more than one
role) in the same association. In other cases it can be derived."

Suggest:

Remove NavigationCallExp::navigationSource that currently has no semantics

Introduce QualifiedPropertyCallExp (and etc.) as a further NavigationCallExp
to support
the qualified navigation. It has two associations:

referredSourceProperty: Property (e.g. "bosses")
referredTargetProperty: Property (e.g. "employeeRanking").

Issue 7341 changed a number of syntaxes to permit a PathNameCS rather than a SimpleNameCS,
so that scope ambiguities could be resolved.

It is not clear why this was applied uniformly to all syntaxes where a name reference is in use. As a minimum
it just gives the user the discretion to clarify a subtle statement, and it avoids the impression that pathed-names
are special. It also avoids the need for some very similar concrete syntax expositions.

More specifically in an AssociationClassCallExpCS it would allow disambiguation of Left::Link and Right::Link as
alternate AssociationClasses.

Suggest allow PathNameCS in all places where there is not a specific requirement for a SimpleNameCS.

It is common in an iteration to require in iteration index.

This can be achieved rather expensively by indexOf, or less expensively by
iterating over an integer literal range.

It would be easier to define e.g.

forAllAt(index : Integer, i : T)

etc so that an implementation can supply the index efficiently.

UML supports generics/templates. OCL doesn't. This is a UML alignment failure.

Synthesized attributes, [B] TBD should not be a part of International Standard. Modify the text as appropriate

There is no attribute designation of FeatureCallExp in Fig 8.2. However, in Attribute of FeatureCallExp class description (p43), isPre is described. Add isPre to Class “FeatureCallExp” on the class diagram (Fig. 8.2)

The OrderedSet well-formedness constraints in 11.7.3 appear to have been
copied and pasted from Sequence. They need revision to consider the Set
consequences of .

Addition operations (includes, insertAt, union, append, prepend) have a
post-condition that the size increases, which is clearly not the case if
an additional element is equal to a pre-existing element.

In the particular case of insertAt there is an ambiguity as to whether
the insert index is the pre or post index. For instance when inserting 3
at index 5 into OrderedSet

the pre-index insertion
yields OrderedSet

whereas the post-index insertion yields
OrderedSet

. While the post-index insertion satisfies the
'post: result->at(index) = object' constraint, it is presumably not the
intent.

12.5.1[3], 12.6.1[2], 12.7.1[2], 12.8.1[2] are TBD.

MDT OCL implementation has assumed that OrderedSet is a subtype of Set. It has become clear (11.6.3) that this assumption was erroneous. As a result, operations which are defined on Sets in the standard library (like including, excluding, intersection, union, etc.) must be undefined on OrderedSet. However, many clients (including the ones of Operational QVT) have already written code relying on this behaviour (i.e. considering that OrderedSet is a subtype of Set, they used operations like including()). It would be very helpful to define such operations on OrderedSet. It would be also important to define these counterpart operations so that they would keep the order of the elements of the initial OrderedSet, e.g:

including(object : T) : OrderedSet(T)

The OrderedSet containing all elements of self plus object added as the last element.

post: result = self.append(object)

TupleLiteralExpPartEval is not included in Figure 10.11. Is VariableDeclEval the one? Add this element to Figure 10.11.

Three library operations do not appear to be declarable without intuitive typing semantics.

Introduction of an OclSelf template parameter that is the statically determined type of self can solve the problem. OclSelf is a reserved spelling.

Classifier::allInstances(OclSelf)() : Set(OclSelf) – set of the derived classifier
OclAny::oclType(OclSelf)() : OclSelf – my own type as statically known
OclAny::oclAsSet(OclSelf)() : Set(OclSelf) – set of my own and derived types, declared as the statically known type

[oclAsSet is the currently unspecified library operation used to realise implicit object-to-set conversion]

Without an OclSelf, almost any usage of these library operations must be followed by an oclAsType to the already known type.

e.g. with the OCL 2.3 type system the library function is

Classifier::allInstances() : Set(Classifier)

and so the usage is

MyType.allInstances() – is MyType instances as a Set(Classifier)
MyType.allInstances().oclAsType(Set(MyType)) – necessary cast to statically known type

Main text. TBD should not be a part of International Standard. Modify the text as appropriate.

The AS is referred to in a number of places as an abstract syntax tree. This is a misnomer that causes confusion in some academic circles. The AS should always be referred to as a Graph.

The intro to Section 8.2 states:

"OCL is a typed language. Each expression has a type that is either
explicitly declared or can be statically derived."

However OclMessage lacks type parameterisation and so the 7.7.2 example

context Subject::hasChanged()
post: let messages : Sequence(OclMessage) = observer^^update(? : Integer, ?
: Integer) in
messages->notEmpty() and
messages->exists( m | m.i > 0 and m.j >= m.i )

only works if the type analysis proceeds beyond "messages :
Sequence(OclMessage)" to
discover the initialiser with formal signature "Observer::update(i :
Integer, j : Integer)".

This will not in general be possible and so expressions such as "m.i > 0"
cannot be
statically checked, and cannot be dynamically expressed. Indeed since m is
an OclMessage,
"m.i" is not well-formed.

Suggest that OclMessage is redefined as:

OclMessage<OclOperation> or OclMessage<OclSignal>

requiring the type to be determinate or discovered by oclAsType.

I hope someone can explain to me why OCL does not have a reference to "super" (similar to the existing reference to "self"). Wouldn't you want to sometimes call the redefined version of an operation from an OCL exrpression, similar to how you can do that in Java?

From my limited knowledge of ALF (the action language), I understand it supports the "super" reference, so this tells me there is no semantic restriction there?

Some iterations are needlessly verbose to use for simple cases.

->sortedBy(n |n) for a simple self sort could be abbreviated to ->sortedBy()

->forAll(n | n) for ANDall could be abbreviated to ->forAll()

->exists(n | n) for ORall could be abbreviated to ->exists()

->any(true) could be abbreviated by ->any()

The absence of synthesized and inherited attributes in 12.2 makes it unclear how an environment is maintained and so makes it unclear whether OCL supports forward and/or backward references.

Presumably both forward and backward references are allowed, so a two phase behaviour is needed to enter all definition names in the environment(s) in phase 1 so that they are visible for lookup in phase 2.

The Collection(T)::product(c2 : Collection(T2))

signature carefully uses T2 to distinguish self and argument element types.

The same distinction is missing from

Collection(T)::"="(c : Collection(T))
Collection(T)::"<>"(c : Collection(T))
Collection(T)::includesAll(c : Collection(T))
Collection(T)::excludesAll(c : Collection(T))
Set(T)::union(s : Set(T))
Set(T)::union(b : Bag(T))

etc etc

The current definition makes at least one of

Set

->excluding(1.0)

invalid through lack of a suitable collection operation.

For some operations, such as union, a T2 conforms to T well-formedness constraint is appropriate,
but for others, such as removeAll, T2 and T can be independent.

12.1, 12.2 refer to UML 1.4.

12.1.1, 12.9, 12.12 defers until UML 2.0 is defined.

12.5, 12.8 uses Attribute and AssociationEnd rather than Property

12.5.1[1], 12.6.1[1], 12.7.1[1], 12.7.3[1] make use of self.constraint.stereotype.name. Constraint has
keywords rather than stereotypes

8.2 Does the lack of restriction on feature types for a TupleType extend to InvalidType and VoidType? With an InvalidType feature the tuple could only be 'well-formed' when containing an invalid value. Surely a tuple with an invalid value is itself invalid and not well-formed?

8.2.2 TupleType has some ASCII code corruptions in the OCL.

8.2.2 TupleType uses unqualified names for feature types allowing an ambiguity when package path is significant.

10.2 TupleValue surely values must not be invalid?

13 TupleLiteralExp has a TupleLiteralPart which has a Property, not accommodating the OclExpression of an initExpression provided by the concrete syntax. Surely a TupleLiteralPart is a derived VariableDeclaration adding an initExpression?

OCL 2.1 currently specifies an informal run-time meta-model in which all types conform to OclAny. Contributions to this meta-model come from

• the user meta-model(s)
• the standard library and its extensions
• additional constraints

Problem 1: An OCL AST for an OperationCallExp has a referredOperation that must be able to reference an operation that may come from any of these sources. Issue 12854 raised the problem of referencing additional operations and attributes.

Problem 2: The almost trivial problem of referencing standard library features has not been raised. If an AST is to be portable between one OCL tool and another there must be a standard URI by which for instance OclAny::= is referenced. Where is this URI specified?

Problem 3: The semantics of ambiguity resolution between alternative contributions is unclear. UML appears to leave overloading as a semantic variation point, so UML compliance is not helpful. Issue 14591 suggested that a first phase execution created at least a composite UML meta-model.

Problem 4: OCL 2.1 made clear that there is no reflection at run-time, and introduced OclAny::oclType to compensate. This provides very limited capabilities, in particular there is no counterpart to Element::container().

A formal run-time model and meta-model can solve these problems. The run-time model is the OCL library model, it's meta-meta-model is the OCL library meta-model and it's meta-meta-meta-model is MOF/UML. NB The OCL library meta-model is not the OCL meta-model.

The OCL library model comprises primarily oclstdlib::Classifier instances, one of which is named OclAny. OclAny::oclType() returns its oclstdlib::Classifier (NB not a uml::Classifier).

The oclstdlib::Classifier::conformsTo property (like but not uml::Classifier::general) contributes to the reified type conformance hierarchy.
The oclstdlib::Classifier::operations property (like but not uml::Classifier::operations) unifies the three sources of available operations, and three different derivations of oclstdlib::Operation accommodate the three types of contribution.

The oclstdlib model therefore integrates the user's UML meta-model with the standard library and additional constraints and is built during the first phase of execution. The oclstdlib meta-model is much simpler than MOF; there is no need for Associations and ConformsTo is the only Relationship. The semantics of the oclstdlib model defined independently of UML ensure a clear definition of the meaning of OCL execution.

The oclstdlib model should make no pretence at being UML because it is fundamentally different. One form of oclstdlib::Operation integrates a reference to a uml::Operation into a uniform behavioural structure. oclstdlib::Classifier ::conformsTo provides the modification of the user meta-model to insert OclAny as the bottom type, without modifying the user meta-model.

With an oclstdlib metaModel, OclAny could provide reflective capabilities such as oclContainer(), oclContents(), oclGet(), oclSet() etc that provide useful reflective capabilities. self.oclType().operations can satisfactorily return a collection of operations even though the operations come from three diverse sources. self.oclType()->closure(conformsTo) will return the type conformance ancestry.

Collection::sum is defined to exploit an associative and commutative T::+(T).

However for an empty collection, the result must be a zero value of the
user defined type and there is no mechanism to determine its 0.

Suggest: require a T::zero() and provide corresponding Real::zero() and Integer::zero() and UnlimitedNatural() operations.

The minus operation should be provided for OrderedSet as well as Set.

excluding and including are defined for Bag, Sequence and Set but not OrderedSet or Collection.

The Collections would be more consistent with an OrderedSet::excluding and an OrderedSet::including.

With all concrete Collection types defining excluding and including, the abstract Collection could also
define Collection ::excluding and an Collection ::including supporting fully polymorphic addition and
querying of collections.

The text in the clause titled “Qualifying association ends with association names” points out that it is possible to qualify an accessed role name with the name of the association using the ‘::’ separator. (In the example: aC1.A1::c2.) There is no issue with this as a means to access the associated instance. However, in doing so, the clause misses the opportunity to also say that it is also possible to reference the same associated instance using the ‘.’ (dot) operator in place of the ‘..’ separator, (for example: aC1.A1.c2).

While this was also true prior to OCL 2.2, only the later technique was referenced in OCL 2.0.

Clarification is needed with respect to whether or not there are any semantic differences between the uses of these two techniques. Where the functionality overlaps, is there a preferred technique?

Nit: the last sentence of the example:

“If a C1 is aC1 access, aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

Should probably say:

“If aC1 isa C1, then aC1.c2 will not be valid since it is ambiguous, whereas aC1.A1::c2 or aC1.A2::c2 will be valid.”

At the end of Section 7.4.6 OCL 2.2 says

"For clarity, the qualified form may only be used with an explicit source
expression."

thereby requiring "self.Person::age()" rather than just "Person::age()".

This 'clarity' is surely just a stylistic issue.

An organisation may advocate an OCL-style guide that discourages the use of
implicit-self.
That is a free choice made by that organisation.

It does not seem appropriate for one corner of the OCL specification to
prohibit implicit-self
where consistency would imply that it should be present.

This is not a 'clarity', it is a confusion.

Suggest allow implicit-self before qualified path names (unless there is a
different
strong technical reason.)

The use of OclState in the specification is not defined in the normative part of the specification, where it appears solely as OclAny.oclIsInState(statespec : OclState).

A corresponding StateExp exists to convey this as a referredState of type State.

Surely the OclState type is redundant and it should be OclAny.oclIsInState(statespec : State)?

The use of OclState in Annex A may be helpful, so perhaps an introduction to Annex A could explain the mappings between the names used for clarity in Annex A and those used in the normative specification.

Aren't a StateValue and StateExpEval needed to define the semantics?

Isn't a StateExpCS needed to define the abstract/concrete syntax? Perhaps this could merge with TypeExpCS, TypeLiteralExpCS as ModelElementLiteralCS.

Issue 9796 responded to the merge of Attribute and AssociationEnd as Property in UML
by merging AttributeCallExp and AssociationEndCallExp.

This merge was not appropriate since UML made no change to the required OCL navigability.

Without AssociationEndCallExp, it is not possible to express a qualified association navigation,
since the 'replacement' PropertyCallExp does not allow for the qualifiers in:

self.customer[123456]

The OCL 2.2 specification refers to stereotypes in the UML 1.x sense. These need to be aligned with UML 2.x. Are they 'keyword' or 'Stereotype'? Is there an OCL Profile to be applied?

NB. the sterotypes are of two forms:
a) Constraint role: invaraint/precondition/...
b) UML extension: OclHelper for a Complete OCL def (see 7.4.4.)

The oclIsInState takes an OclState argument, which is referenced extensively
in
Annex A, although the OclState type is never defined in the main text and is
not
mentioned in the grammar as a reserved word.

oclIsInState is misspelled as oclInState 7 times in Section 7.5.9 and once
in A.2.6.

Yet another query on an Eclipse newsgroup has asked how stereotypes/profiles work in a transformation language, so I've taken a brief look and it appears that UML 2.5 Section 12 appears gives the only clue as to how an OCL expression might navigate a Stereotype:

self.base_Interface.ownedAttributes->size() = 0

This is a particularly unfortunate example since it uses reflection, or at least multiple meta-levels, which are not currently supported in OCL 2.x.

Once OCL supports reflection and type literals, I would expect to see something more like

Interface.ownedAttribute->size() = 0

The constraint presumably is that the stereotype has no attributes, regardless of the class to which it is applied.

Reflective operation might do something like

self.oclType().selectFragment(Interface).ownedAttribute->size() = 0

(if selectFragment is an OCL library operation that selects a type merge contribution).

The utility of the meta-level traversing 'base_xxxx' and 'extension_xxxx' seems very suspect. Does any tool support them? I know Eclipse UML2 has at least a 'base_xxxx' name, but I doubt that it is reflective. It's sole purpose seems to be to give me trouble with validation errors.

-----------------

It seems to me that in the same way that (for base classes):

A class C (with property c) may have base classes B1 (with properties b, b1) and B2 (with property b, b2) allowing implicit access such as aC.c, aC.b1, aC.b2, but requiring qualification for aC.B1::b and allowing redundant qualification for aC.B1::b1.

then (for stereotypes):

A Class C may have stereotypes S1 (with properties s, s1) and S2 (with properties s, s2) allowing implicit access such as aC.s1, aC.s2, but requiring qualification for aC.S1::s and allowing redundant qualification for aC.S1::s1. The implicit access is only permissible when it is statically known that the Stereotype has been applied, i.e for an expression whose context is the Stereotype. In more general contexts the Stereotype qualification may need a run-time check and an invalid result if the Stereotype has not been applied. Thus:

not aC.S1::s1.oclIsInvalid() implies some-expression-when-S1::s-exists

If property overloading is forbidden, but operation overloading permitted, in the above

adding a property C::b, or S1::c or S2::b2 would be a static error since the added property overloads a property name already present in the extended class. Note that this is not in accord with the current OCL specification that motivates the introduction of qualification to support access to hidden property names, which UML prohibits.

adding any operation in a stereotype is valid; it is either a new or overloaded operation. However two stereotypes contributing the same operation signature is a static error to be detected by the attempt to apply both stereotypes.

Since the WFRs for the above belong in UML, presumably the above should be in the UML specification, and the OCL specification should just map the alternate navigation syntaxes appearing in the UML specification to appropriate Concrete and Abstract Syntax Expression elements.

As part of the support for lambda expressions an ability to parse OCL from a string would be useful

For reference: http://www.omg.org/spec/OCL/2.4/
The concrete syntax for the rule invOrDefCS in section 12.12.6 seems to establish an infinite recursive relation without a terminal rule. Perhaps a question mark is needed, or some clarification?

a) an OrderedSet would be more appropriate
b) enumeration literals are instances of EnumerationLiteral; they are not instances of an Enumeration

cf. MyClass.allInstances() dynamically overloads Classifier.allInstances() to return all known instantiations of MyClass, rather than all features of MyClass.

so why does MyEnumeration.allInstances() prevent me discovering all instantiations of MyEnumeration; Enumeration is a Classifier.

The required functionality of MyEnumeration::allInstances() is available as MyEnumeration.ownedLiteral provided reflection is consistently defined.

Suggest: remove the Enumeration.allInstances() overload.

The class diagram on Fig8.6 & Fig8.7 and its class description is inconsistent. For example, there is TupleLIteralPart on the class diagram. However, there is no class description in p51. Additionally, as class description of CollectionLiteralPart, Associations describes “type”. Furthermore, PrimitiveLiteralExp doesn’t have any attributes on the class diagram (Fig 8.6). However, followed class description, p51, Attribute “symbol” is described. And, there is a referredEnumLiteral as class description. However, class diagram doesn’t have referredEnumLiteral on Fig. 8.6. PROPOSED RESOLUTION: Correct class diagram and its class description

As class description, there is a AssociationClassCallExp. However, there is no Class on the class diagram in Fig.8.3.. Proposed change: Add Class “AssociationClassCallExp” on the class diagram in Fig. 8.3.

The discussion of Issue 12953 suggests that two members of the RTF agreed that is unclear
what T in e.g Set's including(Object : T) means.

The first paragraph of Section 11.6 makes clear that the intent of the specification applies to e.g. Set(T) and
so the well-formedness rules in 11.7 refer to e.g. Set(T)::including(Object: T), so T is the known element
type of the collection. It is therefore a static error to attempt to invoke Set(T) including for an object
incompatible with the known element type T.

It would be helpful for the Section headings in 11.7 to have a (T) appended so that the 11.6 specification
of T was clearly carried over from 11.6 to 11.7. e.g.

Replace

11.7.1 Collection

by

11.7.1 Collection(T)

The 'clarified' text in OCL 2.3 for missing association ends, is still unclear.

Problem 1: if multiple association ends acquire the same name, what happens? Suggest: they all acquire the same name and the resulting lookup up finds multiple names which should be diagnosed as an ambiguity and consequently a semantic error.

Problem 2: if a missing association end is recursive, a class acquires a property with the same name as the class. Consequently invocation of e.g X.allInstances() for class X may encounter an ambiguity while resolving X. Is it self.X or global X? Suggest: auto-generated missing names may only be invoked via a navigation operator.

Problem 3: does a derived association end get a resolution for a missing name? if OCL is used to define a number of helper properties that all return the same type, then provision of the missing 'opposites' results in unhelpful clutter at best. Suggest: missing names are not provided for derived association ends.

Many figures shown by UML are not unified in line color and hatching color. Unify them.

UndefinedValue is explained in the text but is not included in any of the following diagrams. Add this element to the diagram.

Issue 6555 introduced the 'missing' Collection::=(Collection(T)) and Collection::=(Collection(T)).

Issue 12948 changed Collection to conform to OclAny

This means that "Set{} = 1" is no longer self-evidently invalid.

According to the inherited OclAny::=(OclAny), "Set{} = 1" should be semantically legal and evaluate to false.

But if Collection::=(Collection(T)) fully occludes OclAny::=(OclAny) ,"Set{} = 1" should be a semantic analysis failure and so invalid.

Conversely "1 = Set{}" is OclAny::=(OclAny) and unambiguously false (until a Real::=(Real) overload is introduced to accommodate value rather object identity).

OCL does not specify any policy for static or dynamic resolution of overloads.

A Java-like policy of static determination of the most derived valid signature, then dynamic dispatch on the self object would seem appropriate, but:

let c1 : OclAny = Set

in c1 = c2

must select OclAny::=(OclAny) as the static signature. Collection::=(Collection(T)) is not a derived operation with the same signature, so evaluation should use OclAny::=(OclAny) rather than Collection::=(Collection(T)) and give erroneous results swhen the collections are compared by object identity rather than collection kind and content.

Either:
OCL must specify multi-dimensional dynamic overload resolution on source and arguments

Or:
OCL should specify Java-like single-dimension dynamic overload resolution and the signature of derived operations such as Collection::=(Collection(T)) should be changed to match their inherited signature, i.e. to Collection::=(OclAny).

[Or:
All derived functionality must be folded into the base (OclAny) operation.]

UML models may explicitly declare that a Property is not navigable in order to simplify the complexity of the run-time representation of that Property.

In an EMOF representation, the non-navigable Property is missing and so an OCL constraint cannot use it, even though the OCL constraint is used at compile-time rather than run-time.

In a UML direction, a Property may be unnamed in one direction and the implicit naming of such opposites may be inadequate to permit unambiguous usage.

QVT Relations 1.1 partially works around this by introducing an opposite(Property) declaration that may be used for Keys and PropertyTemplateItems.

OCL, rather than QVT, should provide an ability to navigate a Property in an opposite direction.

In the Abstract Syntax, OppositePropertyCallExp is required to capture the inverse navigation semantics of PropertyCallExp.

In the Concrete Syntax, some alternate navigation operator is required. Perhaps "a.~b" indicates that "b" is in an inverted direction.

Collection::flatten is overloaded for Bag, Sequence and Set but not for OrderedSet.

UML defines Enumeration.ownedLiteral as an ordered set. Surely allInstances() should therefore return an OrderedSet for an enumeration, and perhaps an ordinal property should be added by the Standard Library.

13.1 states that "EssentialOCL is the package exposing the minimal OCL
required to work with EMOF. EssentialOcl depends on the
EMOF Package."

13.1 states that "For convenience, because BasicOCL (respectively
EssentialOCL) is - conceptually a subset of the complete OCL
language for UML superstructure."

MOF 06-01-01 defines EMOF and Figure 12.1 clearly shows a merge of
Reflection. Therefore EssentialOCL has reflection.

UML superstructure has almost everything, so BasicOCL has reflection.

Issue 12951 provides the following revised text for 13.2. "The EMOF
Reflection capability is not merged to the metamodel."
This contradicts the above. If this is intended, OCL needs to redefine an
EMOF as perhaps OMOF with the appropriate merges.

Issue 9171 discusses why reflection is not available at the modelling level,
but is available at the meta-modelling level.

Presumably the intent is that MOF Reflection is present in the OCL
meta-model, but is not necessarily present in the constrained models and so
is not necessarily useable in OCL expressions. The revised text for Issue
12951 should be revisited to align with Issue 9171.

There are references to Attribute (from Core) in sections 7.5 , 8.2, 8.3.2, 8.3.8, 8.3.9, 9.3, 9.4.1, 10.3.2, 10.4.1, 10.4.3 while the UML infrastructure defines Property instead of Attribute

Further to Bran Selic's observation on Issue 15357 that UML-specifics should not really impact the OCL core. This is easy for State via a ModelLiteralExp, but hard for Message which has associated concrete syntax.

The expression grammar could be made extensible to accommodate custom/orthogonal infix, prefix, suffix, precedence if an expression could be parsed by the generic:

expr ::= affixed (infix affixed)*
affixed ::= prefix* suffixed
suffixed ::= atom (suffix | '(' expr ')' | '[' expr ']' | '

' )*
atom ::= '(' expr ')'

The major problem is the missing 'endlet', which makes accurate parsing difficult and complex expressions easy for humans to misinterpret too.

Suggest introduce the 'endlet' keyword.

OCL already has an implicit form of Lambda function in the intuitive declaration of collect(). This should be formalised and made more versatile. It doesn't seem to be possible to formulate a declaration for collect() without a Lambda Function:

Sequence(T1)::collect(T2)(iterator : T1 | body : Lambda T1() : T2) : Sequence(T2)

The mandatory collect body is a parameter-less Lambda function whose context-type is the class template parameter T1 and the return-type is the operation template parameter T2.

For other iterators the declaration can be just OclExpression since the type is not exploited.

Usage of upper/lower case letter is inconsistent with UML.
For example, “Invariant”, “Precondition”, “Postcondition”, etc, in the text should be lower case letter. However, there are UML metamodel elements, such as “Classifier”.
Especially, “collection type” in function flatten, p158, is lower case letter. If this is designated in lower case letter, it is difficult to understand the meaning of sentence. What about “collection type” L1 on 11.2.1? It is confusing whether those are metamodel elements or not.)
It is required to be consistent with convention of UML upper case letter, since this standard is a family of UML, that is, it is required to use upper case letter only for UML/OCL Metamodel element.

It would be usefuil to have iterations analoguous to isUnique that compute max or min of a user-defined expression body over a collection.

9.3.36 states "A variable declaration inside a let must have a declared type and an initial value."

In the case of a Tuple literal assigned to a let variable, this requires that the tuple signature be entered twice.

Suggest relaxing the requirement on a type to allow deduction from the initial value.

OCL supports definition of constraints, but it is difficult for tools to offer better error messages to a user than 'Constraint <constraint-name> violated for <constrained-element-name>'.

It would be helpful if Constraints had an additional String-valued expression to be evaluated in the context of the error, so that tools could evaluate it and present the result to the user.

Suggest add an optional argument to the (not-optional) constraint name. e.g.

inv ConstraintName('Unable to find ' + self.target.name): ...

The support for messages uniquely requires dedicated concrete syntax: ^, ^^, ?

This makes provision of Essential OCL tooling without messages and Complete OCL tooling with messages hard.

The operators are hard to remember and inconsistent with OCL where "forAll" is favoured over upside-down A.

Suggest replace ^,^,? by OclElement::hasSent(), OclElement::messages() and Message::Unspecified (possibly just null), so that Messages can be modularized as an Standard Library extension of additional types, operations and attributes only. No concrete syntax change.

collect and collectNested have irregular semantics that ignore the natural (outer) collection element type when used on nested collections:

i.e Set{Set{1.0}}>collect(toString()) is Set{Set{1.0}}>collect(s : String | s.toString())

so how might an iteration over the outer collection element type be performed?

Presumably, for homegeneous collections, by explicitly specifying the iterator type as Set{Set{1.0}}>collect(s : Set(String) | s>size())

Suggest: collect, collectNested specify that the implicit iterator type is the innermost collection type, and that an explicit type may
specify a collection type that successfully iterates when all leaves of the tree are uniquely contained in a corrsponding iteration element
of the iterator type, else the iteration is invalid.

Can't see a solution for heterogeneous solutions

Dot and arrow navigation have implied definitions in the non-normative clause 7, but nothing in the normative clauses.

Implicit collect is missing from clause 9, save for the throwaway final sentence "The mapping
is not formally defined in this document but should be obvious."

This mapping is far from obvious; if it was obvious it would be easy to define.

In particular it is important to define that a static syntax determination is made to ensure that:

anObject . feature => object navigation
anObject -> feature => implicit collection (of anObject's static ordering/uniqueness) containing a non-null anObject
aCollection -> feature (or iterator) => collection navigation
aCollection . feature (or iterator) => implicit collect = aCollection -> collect(feature or iterator)
(implicit source object implicit .) feature => object navigation
(implicit source collection implicit ->) feature (or iterator) => collection navigation

with the object/collection discrimination performed statically, so that the navigation
algorithm is statically determinate; only the dynamic dispatch on self is subject to
dynamic determination.

The conformance of a collection to OclAny must never used to allow object navigation on a collection. This avoids a syntax ambiguity for "aCollection . name" between implicit collect and object navigation of a collection feature, or between implicit collect and object navigation of an object feature.

Section 10 is suffering seriously from lack of update and review.

The old AssociationClassCall/AssociationEndCall/ModelPropertyCall spellings are in use throughout.

OrderedSetValue is omitted throughout.

UnlimitedNaturalExpValue is omitted throughout.

TypeExpEval is omitted throughout thereby avoiding tackling the irregular semantics of the oclIsKindOf argument.

'undefined' does not distinguish null and invalid and is variously undefined, void, UndefinedValue, OclVoidValue and UnspecifiedValue including a reference to UnspecifiedValueExp that does not exist. There should be just an OclVoidValue and an OclInvalidValue.

OrderedSet is not used where elements are clearly unique e.g. Sequence(LocalSnapShot).

OCL is regularly spelled ocl or Ocl as a non-word prefix.

An Element::indexNr is imposed on all Collection elements. Surely a distinct OrderedCollectionValue intermediate value should use the stronger OrderedCollectionElement.

It is not specified whether Element::indexNr indexes from 0 or 1 or indeed even monontonically.

Figure 10.4 omits many

and

constraints.

Figure 10.4 omits LocalSnapShot.pred and succ.

10.2.1 Element assserts that Element is a tuple NameValueBinding.

10.2.1 OclMessageValue italicises the wrong use of 'name'.

10.2.2 LocalSnapShot[1] refers to ispre rather than isPre.

10.2.2 LocalSnapShot[2] asserts that the result of an implicit collect is a boolean (missing ->any).

10.2.2 ObjectValue omits the doubly-linked list validity constraint

10.2.2 TupleValue assserts that a NameValueBinding is an Element.

10.2.3 SequenceTypeValue omits a constraint on the sequential validity of Element.indexNr

10.2.3 LocalSnapShot uses notEmpty rather than nonEmpty()

10.3 para 2 refers to a non-existent OclEvaluation class

10.3 para 2 has erroneous figure references to 10.6,7 rather than 10.7,8

10.3.2 OperationCallExpEval relies on UML semantics, but fails to resolve UML's unspecified behavioural variation point on operator overload resolution. See Issue 15013.

10.3.2 OperationCallExpEval spells forAll as forall.

10.3.2 CollectionRangeEval uses isOclType(Sequence(Integer)). Any such use of collection types was invalid in OCL 2.0. Use of a collection type is not valid concrete syntax in OCL 2.1/2. The resolution of 10439 for OCL 2.3 provides concrete syntax support, but the semantics remains undefined although perhaps intuitively obvious.

As separately raised isOclType etc are incorrect spellings.

The x .. y syntax could be used to advantage in places such as 10.3.3 CollectionRangeEval.

The explicit iterator is unnecessary in for instance 10.2.2 TupleValue.

Figure 10.14 has layout problems.

Figure 10.14 shows instances <-> model associations for both Concrete and Abstract classes. The model for derived classes should be marked as derived.

10.4.2 BooleanLiteralExpEval has an unresolved MOF/UML alignment.

10.4.2 EvalEnvironment has a missing constraint on uniqueness of binding names.

10.4.2 IfExpEval has missing and operators

Generally: the constraints should be validated by an OCL checking tool.

9.4.2 NamedElement

NamedElement, as defined by OCL, links to ModelElement (from Core) and has an operation getType(): Classifier

Postconditions are given when the referred modelelelement is an instance of Classifier, VariableDeclaration or State.
However, from subclause [4] of section 9.4.1 it follows that the referred modelelelement may also be an instance of Namespace.
(let firstNamespace : ModelElement = lookupLocal( names->first() ).referredElement, where lookupLocal returns an OCL NamedElement)

In the UML Infrastructure, Namespace specializes Core::NamedElement, which does not defines a type attribute (Core::TypedElement does)
Namespace is a generalization of Classifier.

At least, add:
post: referredElement.oclIsKindOf(Namespace) implies
result = – TBD: when aligning with UML 2.0

Should it be result.oclIsUndefined() ?

It reads: lookupAttribute

It should read: lookupProperty

Rationale: on section 8.3.8 an operation lookupProperty(attName : String) : Attribute
is added to Classifier. The operation lookupAttribute is never defined in OCL or UML infra/superstructure (v2.1.2)

12.12: getClassifier and getPackage in text, but findClassifier and findPackage in signatures

At the end of Section 7.4.6 OCL 2.2 says

"For example, if class Employee redefines the age() : Integer operation of
the Person class, a constraint may access the
Person definition as in
context Employee
inv: self.age() <= self.Person::age()
For clarity, the qualified form may only be used with an explicit source
expression."

and in Section 7.5.8:

"Whenever properties are redefined within a type, the property of the
supertypes can be accessed using the oclAsType()
operation. Whenever we have a class B as a subtype of class A, and a
property p1 of both A and B, we can write:"

a clarifying example follows that is actually a disambiguation not a
redefinition.

In UML redefinition replaces an old definition with something else, which is
not what the above
excerpts imply.

In the case of redefining "Person::age() : Integer". If the redefinition is
"Employee::age() : UnlimitedNatural"
the redefinition is compatible (valid UML), so perhaps self.age() being
UnlimitedNatural and self.Person::age()
being Integer just might be useful. But allowing them to invoke different
operation bodies seems to violate
UML.

Suggest that use of a path qualification may select an occluded definition
signature for static analysis,
but may not use a redefined value or body.

[This then avoids a need for the AST to persist the distinction between X::y
as an explicit feature for
static resolution or as an implicit feature for dynamic resolution. All
features in the AST are identified by
static analysis and evaluated by dynamic resolution.]

In Section 8.2.2, in Classifier well-formedness rules, 'collectionTypes' is used instead
of 'collectionType'. This is not correct since in OCL, by convention, when not provided explicitly
the name of an opposite role takes the name of the target class with first letter lowerized.

No Data Available

12.12 para 3 "OCl" for "OCL".

12.8 para 1 last sentence, 12.9 para 1 last sentence; both are unreadable.

12.12.2 No [B] rule

12.12.1/12.12.2 contextDeclCS/contextDeclarationCS

The OCl typo is fixed in OCL 2.3.
The grammar typos are easily fixed.
While making the multiplicity statements readable, we can make one small step towards aligning OCL with UML 2.x properties.

When Issue 9796 updated terminology to use PropertyCallExpCS, attrOrAssocContextCS should have been updated to propertyContextCS.

In 12.12.2 contextDeclarationCS replace
[A] contextDeclarationCS ::= attrOrAssocContextCS
by
[A] contextDeclarationCS ::= propertyContextDeclCS
Replace
12.12.3 attrOrAssocContextCS
This production rule represents a context declaration for expressions that can be coupled to an attribute or
association end. The path name refers to the “owner” of the attribute or association end, the simple name
refers to its name, the type states its type.
attrOrAssocContextCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS
by
12.12.3 propertyContextDeclCS
This production rule represents a context declaration for expressions that can be coupled to a property. The
path name refers to the “owner” of the property, the simple name refers to its name, the type states its type.
propertyContextDeclCS ::= ‘context’ pathNameCS ‘::’ simpleName’:’ typeCS initOrDerValueCS

subclause [10])

It reads: let foundElement ... in result = if foundAttribute ... else foundElement ...

(foundAttribute is undefined, I understand it means to "foundElement")

simple typo

Related to Issue 7539)

It reads: isOclKind

It should read: oclIsKindOf

Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

This typo is addressed by Issue 14882
Disposition: Merged

The second half of 7.3.3 uses a named-self syntax that is missing from 12.2.5.

context c : Company inv:
c.numberOfEmployees > 50

In 12.12.2 classifierContextDeclCS replace
This production rule represents a context declaration for expressions that can be coupled to classifiers.
classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
by
This production rule represents a context declaration for expressions that can be coupled to classifiers. The
variable declaration to the classifier context is 'self' for the A form and explicitly specified for the B form.
[A] classifierContextDeclCS ::= ‘context’ pathNameCS invOrDefCS
[B] classifierContextDeclCS ::= ‘context’ simpleNameCS ':' pathNameCS invOrDefCS

(Related to Issue 7539)

It reads: isOclKind

It should read: oclIsKindOf

Rationale: per section 7.5.9 the operation name is "oclIsKindOf"

No Data Available

subclause [4]

It reads: names->tail()

It should read:
names->subSequence(2, names.size())

Rationale: tail() is not an operation of Sequence

No Data Available

The iterators of LoopExp and LoopExpEval are not ordered, but the well-formedness constraints on them use ->at() which is only available for ordered collection. Usage of the AST property is subject to a variety of spelling, ordering and multiplicity inconsistencies.

Section 7.6.3 and 7.6.4 define extended variants of forAll and exists that have two iterators.

Figure 8.2 and Figure 13.3 show an unordered * multiplicity for LoopExp.iterator. The positioning of the VariableExp.referredVariable 0..1 multiplicity makes the diagram easy to mis-read.

Section 8.3.1 LoopExp defines iterator as "The iterator variables. These variables are, each in its turn, " implying an ordered collection.

Section 8.3.7 LoopExp [2] and [3] use iterator->forAll implying a collection.

Section 9.3 IteratorExpCS synthesized attributes use iterators->at(1) and at(2) requiring an ordered collection.

Section 9.3 IterateExpCS concrete syntax supports at most one iterator and one accumulator.

Section 9.3 IterateExpCS synthesized attributes use iterator.initExpression requiring a non-collection.

Figure 10.7 shows LoopExpEval.iterators as unordered 1..n.

Section 10.3.1 LoopExpEval defines iterators as "The names of the iterator variables".

Section 10.3.7 IterateExpEval [1] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 10.3.7 LoopExpEval [1] has a two way if = 1 else, implying the upper bound is 2.

Section 10.3.7 LoopExpEval [3] uses iterators->at(1) and iterators->at(2) implying an ordered collection with upper bound 2.

Section 11.9.1 defines the mapping of forAll to iterate for multiple iterators, but IterateExpCS only supports a single iterator.

Revised Text:
In Figure 8.2 and Figure 13.3 change LoopExp.iterator from 0..1 to 1..2

.

In Section 8.3.1 LoopExp iterator replace
The iterator variables
by
The ordered set of one or two iterator variables.

In Section 9.3 IteratorExpCS replace
IteratorExpCS.ast.iterators->size() = 1
else
IteratorExpCS.ast.iterators->at(2).name = VariableDeclarationCS[2].ast.name
and
IteratorExpCS.ast.iterators->at(2).type =
...
[A] IteratorExpCS.ast.iterators->forAll(initExpression->isEmpty())
...
[C, D] IteratorExpCS.ast.iterator.type =
...
body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator
by
IteratorExpCS.ast.iterator->size() = 1
else
IteratorExpCS.ast.iterator->at(2).name = VariableDeclarationCS[2].ast.name
and
IteratorExpCS.ast.iterator->at(2).type =
...
[A] IteratorExpCS.ast.iterator->forAll(initExpression->isEmpty())
...
[C, D] IteratorExpCS.ast.iterator->at(1).type =
...
body.source.oclAsType (VariableExp).referredVariable = IteratorExpCS.ast.iterator->at(1)

In Section 9.3 IterateExpCS replace
IterateExpCS.ast.iterator.name = if VariableDeclarationCS[1]->isEmpty() then ‘’
...
IterateExpCS.ast.iterator.type =
...
IterateExpCS.ast.iterator.initExpression->isEmpty()
by
IterateExpCS.ast.iterator->at(1).name = if VariableDeclarationCS[1]->isEmpty() then ‘’
...
IterateExpCS.ast.iterator->at(1).type =
...
IterateExpCS.ast.iterator->at(1).initExpression->isEmpty()

In Section 10.3.1 LoopExpEval iterators replace
The names of the iterator variables in the loop expression
by
The ordered set of names of the one or two iterator variables in the loop expression.

The attached surprisingly large set of revised text recommendations endeavours to resolve every inconsistent use of invalid and null/void types and the failure to update the specification when undefined was split into null and invalid. The recommendations also correct many conversion errors that crept in when Word Processor formats were changed. Once these changes are incorporated, a very careful proof read against at least Annex A of 03-01-07 should be performed.

The initial discussion identifies that the approved resolutions of Issues: 6611, 10433, 10434, 12349, 12378, 12484 and 12485 are at best deficient

No Data Available

Issue 11098 resolved the missing precedence of let-in as lowest. This requires "2 * let a:Integer=1 in a + 1" to be interpreted as "(2 * (let a:Integer=1 in a)) + 1" making use of a non-trivial let body surprising and needlessly complicated. The problem with the open-ended right hand side can be resolved by assigning let-in the highest atomic expression precedence and defining its resolution as right-associative. The above example then has the obvious meaning "2 * (let a:Integer=1 in (a + 1))".

Issue 6544 introduces ^ and ^^ at higher precedence than . and ->. However since these operators can only return left hand arguments for each other, there is no need to assign these to different levels.

if-then-else-endif has an intermediate precedence in OCL 2.1. Since this term has keywords at start and end, the term is equivalent to an atomic expression. In so far as precedence is meaningful it is a high precedence.

Parentheses should be bulletted at high precedence.

Non commutative operators such as / have no defined order of evaluation leaving the value of "8 / 4 / 2" undefined. Binary operators should be specified as left-associative; i.e "(8 / 4) / 2".

Section 9.3.2 duplicates 7.4.7.

No Data Available

Define the concrete syntax of a simpleNameCS to avoid punctuation collisions, support Unicode characters, and add a double quoted form with escape sequences for awkward names.

Define the concrete syntax of a StringLiteralExpCS to support escape sequences for awkward characters.

Define the concrete syntax of RealLiteralExpCS and IntegerLiteralExpCS.

Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

No Data Available

The specification of the UnlimitedNatural type is largely missing and often trivially inconsistent.

see pages 24 - 35 of OMG document ptc/2010-12-01

Erroneous operation names 'isOclType' and 'asOclType'. The operation 'isOclType' appears four times throughout the document. I presume it refers to 'oclIsTypeOf'. The operation 'asOclType' appears six times throughout the document. I presume it refers to 'oclAsType'.

No Data Available

Specification: Object Constraint Language, formal/06-05-01

Section: 7.6 Collection Operations

Summary:

The concept of transitive closure is very useful for specifying well-formedness constraints on binary relations.

For a binary relation r:A->A and elements x,y,z in A, r(x,y) is true when r relates x to y and r is transitive whenever for any x,y,z in A, r(x,y) and r(y,z) imply r(x,z). The transitive closure of a binary relation r:A->A is the smallest relation, ^r:A->A, that contains r and is transitive.

In the UML specification, the definition of Classifier::allParents() : Classifier[*] as “all the direct and indirect ancestors of a generalized Classifier” could be equivalently paraphrased as the transitive closure of the Classifier::parents() : Classifier[*] relation.

Specifying the notion of transitive closure for the OCL specification can be problematic as this notion refers to a meta-property not expressible in first order logic (i.e., the smallest relation satisfying a given property). However, the notion of transitive closure can be specified in the context of a particular API for evaluating OCL iterator expressions such as that of the Eclipse OCL implementation of the OCL2.0 specification:

http://help.eclipse.org/ganymede/index.jsp?topic=/org.eclipse.ocl.doc/references/overview/OCLOverview.html

http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.mdt/org.eclipse.ocl/plugins/org.eclipse.ocl/src/org/eclipse/ocl/internal/evaluation/IterationTemplateClosure.java?root=Modeling_Project&view=markup

A synopsis of the algorithm for computing the transitive closure as an OCL iterator expression is available here:

http://dev.eclipse.org/newslists/news.eclipse.modeling.mdt.ocl/msg01390.html

No Data Available

[Splitting a major issue off from a number of minor issues in 14357, so that the resolutions do not get confused.]

Define a variety of effectively reserved words such as true, self, Bag, String as reserved.

Define which Complete OCL reserved words are Essential OCL reserved words.

No Data Available

Description:

9.3 Concrete Syntax
As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «›, firstly the symbol is lookup in the metamodel. If not found, the same symbol with the «_» skipped is tried.

Should be

As a convention to the concrete syntax, conflicting properties or conflicting class names can be aliased using the «» (underscore) prefix. Inside an OCL expression that is written with the concrete syntax, when a property name or a class name is found to start with a «», the symbol with the «_» skipped is looked up in the metamodel.

Explanation: Consider that some class in the metamodel has two properties called '_self' and 'self' correspondingly. With the resolution rule defined in 9.3 one can never access 'self' property. On one hand, you cannot refer to it directly because it clashed the keyword self. One the other hand, '_self' would refer to '_self' property according to 9.3. Thus, both variants 'aClass.self' and 'aClass._self' are not helpful here.

Discussion:
Issue 14357 introduces a new underscore-prefix string syntax (_'self') to access awkward
spellings. This solves the problem of accessing either _'self' or _'_self'.

Issue 7341 resolved that a bad oclAsType in 7.4.6 should return invalid.

Issue 10437 resolved that the revised text for bad oclAsType in 11.2.5 should return null.

Issue 6532 resolved that oclAsType in 7.5.9. return a Classifier. The changed specification has OclType.

Issue 7341 is correct.; invalid should be returned by oclAsType when the type
does not conform. Issue 10437 is wrong. The 10437 revised text also incorrectly
uses t rather than T.
Issue 6532 specified an 'instance of Classifier' return for oclAsType. The
convenience document has not been updated.

The expression

'a'.oclAsType(String)

is not well-formed since the invocation of oclAsType is an OperationCallExpCS[E] for which String must be an OclExpressionCS.

String is intended to be a literal expression with a Classifier value, but there is no well-formed OclExpressionCS that can represent such a value.

Syntactically:

String could be a VariableExpCS but is not the name of a visible VariableDeclaration.

String could be a PropertyCallExpCS[B or C] or AssociationClassCallExpCS[B] but is not the name of a property.

A TypeLiteralExpCS is required to allow use of at least typeCS[A] and more flexibly any typeCS.

In 9.3 LiteralExpCS add
[E] LiteralExpCS ::= TypeLiteralExpCS
and
[E] LiteralExpCS.ast = TypeLiteralExpCS.ast
and
[E] TypeLiteralExpCS.env = LiteralExpCS.env
In 9.3 add
TypeLiteralExpCS
This production rule references a type name.
Abstract syntax mapping
TypeLiteralExpCS ::= typeCS
Synthesized attributes
TypeLiteralExpCS.ast = typeCS.ast
Inherited attributes
typeCS.env = TypeLiteralExpCS.env
Disambiguating rules
– none

Disambiguating rule 1 for TupleLiteralExp requires each VariableDeclaration to have a type and initExpression.

However some examples in 7.5.15 omit the type, which is easily inferred from the initializer.

However neither 8.3.7 nor 9.3 specifies this inference.

Presumably the type is optional and to be inferred when omitted.

The synthesized attributes for VariableDeclarationCS should infer when possible.

The definition of the CollectionRangeCS grammar is

CollectionRangeCS ::= OclExpressionCS[1] ‘,’ OclExpressionCS[2]

but everywhere else the operator is '..'

Suggest change to

CollectionRangeCS ::= OclExpressionCS[1] ‘..’ OclExpressionCS[2]

simple typo

Issue 9913 defines the missing InvalidLiteralExpCS and NullLiteralExpCS, but they are never referenced in the grammar.

Suggest:

Add to PrimitiveLiteralExpCS

[E] PrimitiveLiteralExpCS ::= NullLiteralExpCS
[F] PrimitiveLiteralExpCS ::= InvalidLiteralExpCS

and

[E] PrimitiveLiteralExpCS.ast = NullLiteralExpCS.ast
[F] PrimitiveLiteralExpCS.ast = InvalidLiteralExpCS.ast

(not forgetting UnlimitedNaturalLiteralExpCS

Yes; resolution 9913 is incomplete

The OCL 2.0 specification would be much easier to read if:

1) The PDF had a full set of titles visible in the bookmarks:

8.3.*, Annex A.2 , Annex B and Index are missing completely.

A.1 and A.3 apppear as subsections of 13.3.

2) There are a number of large sections such as 8.3.*, 9.3 and 10.4 with unnumbered headings for each AS or CS class.
[11.5 is much better in this respect.]

These are not in alphabetical order, not page aligned and not particularly distinct.

It would be helpful to

a) give them numbers so that they appear in the Bookmarks and are more distinct.
b) put them in alphabetical order.
[c) consider page aligning them.]

[It would be good if the index was much more comprehensive too.

e.g "at", "null", "any", "iterator", "UnlimitedNatural" ...]

PDF bookmarks were fixed in OCL 2.3.
Alphabeticizing must wait until autogenerated in OCL 2.5.
Provision of a manually maintained index in OMG specifications is strongly discouraged.
Disposition: Closed, no change

The well-formedness constraints for IteratorExp are confusing, incomplete and sometimes wrong.

The revised text below resolves these issues