UMLR — Constraint.context vs Constraint.constrainedElement

The situation is now more-or-less clear.
We will use a variant specified OCL spec for evaluating OCL constraints.

However in my humble opinion, UML spec could also benefit if the descriptions
of context and constrainedElement were clarrified a bit on how one should use them.
As Karl correctly notes, when 2 properties can be used to specify the same thing,
this introduces ambiguities in the model.

Even if "nothing prevents the context and constrainedElement from beeing the same object",
on the other hand nothing prevents these 2 from beeing different objects.
Hence if author produces some UML model with constraints where constrainedElement!=context,
the readers of this model cannot interpret it unambiguously.
And I can imagine many cases, where constrainedElement will not be equal to context.
For example if constraints are placed in a separate package from their constrained elements
(perhaps constrained elements are in a separate, read-only library and constraints can not
be added there; or for other packaging reasons). In this case context of these constraints
will be their owner package (per UML2.1 rules) and constrainedElement will be completely
unrelated to it.

PS
And this applies not only in the narrow case of constraints, specified in OCL.
Almost all other languages need contextual information.
For the sake of argument, lets say the constraint is specified in English language.
Well, it so happens, that English language also needs some context to interpret sentences.
The pronouns, such as "this", "these" or "such", can play the same role in English as the "self" variable in OCL.

E.g. Imagine the constraint with specification=OpaqueExpression

placed into the class Box, having property contents:Apple[*] and constrainedElement pointing to this property.
Now there is an ambiguity.
If the constraint.context field is used for interpretting the phrase "these must be yellow" then the boxes must be yellow.
If the constraint.constrainedElement is used, then apples in the box must be yellow.

> Karl Frank wrote:
>
> Agreed. But imo it is a defect for the same thing to be specified in two equivalent ways. EVen if the context is by definition the constrained element, in the case of a
> constraint, it remains an opening for confusion and doubt to specify it using different terms even when equivalent.
>
> But context means something different in regard to a behavior, so I believe constrainedElement is the right term, which is the one used in the OCL spec.
>
> - Karl
>
> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> From: Branislav Selic bselic@ca.ibm.com
> Sent: Thursday, May 18, 2006 5:21 PM
> To: Karl Frank
> Cc: Juergen Boldt; ocl2-rtf@omg.org; Tomas Juknevicius; uml2-rtf@omg.org
> Subject: RE: UML/OCL scpec mismatch - Constraint.context vs Constraint.constrainedElement
>
> I was indeed raising a separate OCL issue (a major one, I believe), but I was also saying that there is no real issue with the UML 2 spec. In fact, if you think about it,
> there is nothing to prevent constrainedElement and context from being the same object. There is no real contradiction here.
>
> Bran