OCL25 — need clear specification for how to write OCL that refers to the stereotypes applied to a model within a UML profile

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.