UMLR — clarification on Behavior::specification / meaning of InterfaceRealization

In 7.3.25 InterfaceRealization Semantics the UML2 spec says "For behavioral features, the implementing classifier will
have an operation or reception for every operation or reception, respectively, defined by the interface. For properties, the
realizing classifier will provide functionality that maintains the state represented by the property."

While section 7.3.45 Realization Semantics says "A Realization signifies that the client set of elements are an implementation of the supplier set, which serves as the
specification. The meaning of ‘implementation’ is not strictly defined, but rather implies a more refined or elaborate form
in respect to a certain modeling context. It is possible to specify a mapping between the specification and implementation
elements, although it is not necessarily computable."

If you interpret this as a literal constraint, then the realizing Classifier would need to copy all of the BehavioralFeatures it realizes. However, it seems unnecessarily redundant to realize an interface and to have to copy all the operations into the realizing classifier too. This means that for an Activity, the "signature" content of an operation could have to be specified up to 6 times:
1. An Operation in a provided Interface
2. The same Operation copied into a realizing Class used as the type of a Port
3. An Operation of a Component containing the Port
4. The method Behavior whose specification is the Operation owned by the Class
5. If the Behavior is an Activity, the ActivityParameterNodes
6. The InputPins and OutputPins of a CallOperationAction that invokes the operation

In addition, there would be no way for an ownedBehavior's specification to refer to an Operation of an Interface provided through a Port since different ports can realize the same interface but have different implementations.

There is no explicit constraint that the Classifier has to have a matching Operation, so you could read the above semantics to mean that adding the InterfaceRealization effectively means the Realizing Classifier has the Interface's behavioral features. This seems to be common practice, you don't often see all the realized operations cloned into the realizing classifier as this is redundant and somewhat tedious to do and maintain.

Consider changing the description of property Behavior::specification in section 13.3.2 from:
Designates a behavioral feature that the behavior implements. The behavioral
feature must be owned by the classifier that owns the behavior or be inherited
by it. The parameters of the behavioral feature and the implementing behavior
must match. If a behavior does not have a specification, it is directly associated
with a classifier (i.e., it is the behavior of the classifier as a whole).

to:

Designates a behavioral feature that the behavior implements. The behavioral
feature must be owned by the classifier that owns the behavior or be realized or inherited
by it. The parameters of the behavioral feature and the implementing behavior
must match. If a behavior does not have a specification, it is directly associated
with a classifier (i.e., it is the behavior of the classifier as a whole).

The possible problems with this change are:
1 Subclasses cannot redefine realized operations of their superclasses unless the operation is duplicated in the superclass. This is because there would be no redefined element to reference in the superclass. This can be solved by cloning the operations that need to be redefined, or (more likely) redefining an ownedBehavior of the Superclass, not an Operation. So there is no change here.
2. Setting the specification of an ownedBehavior would result in an update of the realized interface since the opposite of the specification property is the Interface's method property. This is unfortunate coupling between an interface and its method implementations, but there are many other such cases in UML2, and the method property is multi-valued. So this isn't really that much of a problem.

Some advantages are:
1. It matches the common understanding or realization
2. It reduces redundancy in the model
3. It allows an ownedBehavior's specification to be an Operation of an Interface provided through a Port in an EncapsulatedClassifer. This allows a EncapsulatedClassifier to provide different implementations for the same operation provided through different ports. This would not be possible if the specification operation had to be owned by the containing classifier as there would be no way to distinguish which operation the different behaviors corresponded to.