UMLR — UML/OCL spec mismatch-Constraint.context vs Constraint.constrainedElement

There is an clash/mismatch between the UML2.0 and OCL2.0 specs on constraint semantics.
The UML superstructure doc 05-07-04, chapter 7.3.10 states,
that Constraint has context and constrainedElement associations(properties).

The Semantic section of the paragraph states, that the context property of
the constraint is used in OCL constraint evaluation as a "self".

However the OCL2.0 specification doc 05-06-06, chapter 12 specifies different
rules, how OCL expressions are evaluated in the UML models. In most cases it is mandated that
the self (a.k.a. contextual classifier) should be derived from the constrainedElement property.

In particular, for most common case - invariant constraints, 12.6, 12.6.1 paragraphs state, that
the contextual classifier should be the classifier, specified by the constrainedElement property:

contextualClassifier = self.constraint.constrainedElement->any(true).oclAsType(Classifier)

The other conditions are irrelevant for the issue at hand:
constraint should have <<invariant>> stereotype (self.constraint.stereotype.name = ?invariant?)
constraint.constrainedElement should have a single element (self.constraint.constrainedElement->size() = 1)
constraint.constrainedElement should be classifier (self.constraint.constrainedElement.any(true).oclIsKindOf(Classifier))
expression result should be boolean (self.bodyExpression.type.name = ?Boolean?)

So we have a conflicting specs here. Which one of these is correct?

I am inclined to believe, that the OCL spec, being more concrete, is correct -
UML spec mentions the usage of "self" only casually, in one sentence.
However if this true, what is the meaning of the context property of the constraint in the UML?
It seams that this property is then unnecessary and not used (at least for OCL constraints) anywhere...

Note that the upcoming UML2.1 superstructure spec, 06-04-02, introduces small changes to the context
property of the constraint. Context is now changed to subset namespace.
However the issue, described above, is not mitigated and is still present in 2.1.