Figure 4. Elements defines the relationship attribute, as well as several subsets depend on the same relationship though the attribute isn't anywhere to be found exept for in the figure 4.

The properties Expression::result and Function::result subset parameter, which means they do not have to be ownedFeatures.

The description of deriveExpressionResult states that

If an Expression has a parameter owned via a ReturnParameterMembership, then that is its result parameter. Otherwise, its result parameter is the result parameter inherited from its function.

As written, the OCL interprets this as meaning that the result parameter of an Expression is either owned by that Expression or inherited from the function of that Expression. However, this derivation does not allow for the possibility that an Expression might inherit its result parameter from a supertype Expression. It would seem to make more sense just to select the result as the parameter owned via a ReturnParameterMembership, whether directly owned or inherited (i.e., owned by a supertype) .

Somewhat similarly, the description of the constraint deriveFunctionResult states that

The result parameter of a Function is its parameter owned via a ReturnParameterMembership (if any).

However, the OCL requires that the result parameter of a Function be owned by that Function and cannot be inherited. That is seems to be more restrictive than was intended for this constraint.

The description of the checkFeatureParameterRedefinition constraint is

If a Feature is a parameter of an owningType that is a Behavior or Step, other than the result parameter (if any), then, for each direct supertype of its owningType that is also a Behavior or Step, it must redefine the parameter at the same position, if any.

However, the OCL for the constraint does not exclude the result parameter as stated in the description.

In the Language Description, in 7.4.9.4 Base Expressions, in the fourth bullet for, it states that "A construction expression is an invocation expression in which the invocation target is a classifier that is not a function." However, in the Abstract Syntax, in 8.3.4.8.5 InvocationExpression, the constraint checkInvocationxpressionConstructorBindingConnector considers a constructor expression to be an InvocationExpression that "does not have an ownedTyping that is a Behavior or an ownedSubsetting of a Feature that is typed by a Behavior, then it must own a BindingConnector between itself and its result parameter." Further, in the Semantics, in 8.4.4.9.4 Invocation Expressions, it states

An InvocationExpression may also have the form T(e1, e2, ...), where the invoked Type T is not a Function. If T is a Behavior other than a Function, then the InvocationExpression performs the Behavior, but has a null (empty) result value. If T is a Type that is not a Behavior, then the InvocationExpression acts as a constructor for an instance of the Type T.

Now, invoking a behavior and having it return a null value doesn't really seem very useful. It would actually be more useful if, consistent with the language description, "invoking" a non-function behavior was considered to be a constructor expression, evaluating to a performance of that behavior. This would, in particular, allow out parameters to be referenced from the instantiated performance. For example:

behavior B {in x; out y; out z;}
feature y1 = B(1).y;
feature b = B(2);
feature y2 = b.y;
feature z2 = b.z;

The mapping given in 9.2.17 from the MOF abstract syntax model to the reflective KerML in abstract syntax model is missing instructions for what to do if a property is ordered or non-unique. Therefore, appropriate annotations for these are missing from the normative KerML.kerml file.

In the KerML Specification, 8.2.4.3.1 Features, the production FeatureIdentification references the properties shortName and name. These should instead be declaredShortName and declaredName.

In 8.4.4.11 Feature Values Semantics, the following binding declaration appear in the second textual notation snippet:

member binding f = e.result featured by T;

and the fourth snippet:

member binding f = e.result featured by that.startShot;

These are both syntactically incorrect. The correct syntax is:

member binding b featured by T of f=e.result;

and

member binding b featured by that.startShot of f=e.result;