UPDM — Confusing notational conventions used in diagrams

In many cases, the diagramming indicates an association between stereotypes:
See example below - UPDMElement.
UPDMElement -> Standard
but the documentation does not specify an association, rather it show these as attributes. Is the diagramming correct, or is the document right?
UPDM/RFC::UPDMElement
Super type for many of the UPDM elements. It provides a means of extending UPDM elements in a common way. With links to the measurement set, it also allows quantitative metrics to be associated with structural and behavioral elements.

Figure 1 - Elements related to the abstract UPDMElement stereotype.
Attributes
The following are attributes of UPDMElement:
conformsTo : Standard[*] - Standard that this UPDM element is conforming to.
URL/URI : String[1] - Unique identifier for the element.
measurementTypes : MeasurementSet[*] - Types of measurements corresponding to the actual measurements.
actualMeasurements : ActualMeasurementSet[*] - The actual measurements to which the element must conform.
Extensions
The following are extensions for UPDMElement:

o Element in th esubmission
UPDM/RFC:: 6.5 Representing stereotype constraints
This section describes a profile that is applied to the UPDM Profile inorder to specify various relationships. Since this is integral to the definition of the profile, it should be defined as if it were in fact a UML profile in a formal way.
For example:
"metarelationship" dependency
"metarelationship" is a stereotype for dependency, showing that certain domain concepts will be implemented using regular UML relationships.
For example:
A Capability may depend on other Capabilities, but this concept cannot be visualized on the diagram:

Figure 2: Capabilities Generalization
We are using the "metarelationship" dependency to visualize the dependency concept:

Figure 3: Visualizing <<metarelationship"
This diagram should be read as follows:
Capability may have other Capabilities related to it, using the UML Dependency metaclass.
The "metarelationship" dependency will appear in only in the specification diagrams, but not the profile XMI.
In the actual specification:

There are 3 of these "meta-relationships" shown, but they are not defined anywhere else in the profile. They are part of the normative definition because they are in the diagram, but since they are not in the XMI, then how is that they can be considered as part of the profile?
We need to have a better understanding what these "notational conventions" used in this submission mean. The explanations in the RFC are not sufficient. We had some difficulty understanding them, and exactly what OCL constraints they imply. A formal definition with resulting OCL would clear it up, and provide guidance to tool vendors as to how to deal with these conventions.

No Data Available