Currently, the default visibility for an Import relationship is public (see KerML specification, 8.3.2.4.1, Figure 8). This is consistent with the default visibility for Membership relationships. This means that, by default, any memberships that are imported into a namespace are also visible memberships that are "re-exported" out of the importing namespace.

Now, imports are often used just to make names from on namespace available without qualification within another namespace, with no real intention of re-exporting those names. Nevertheless, unless a modeler explicitly changes the import visibility to private from the default of public, then the names will still all be re-exported anyway. Such re-exporting when unnecessary can have a significant, unintentional impact on the performance of name resolution for a large textually represented model by greatly increasing the space of visible names that need to be searched.

If, on the other hand, import relationships were private by default, then they could still be easily used for importing into a namespace. However, the modeler would then need to make an explicit decision to change the visibility to public if it is desired to re-export the imported names, with, presumably, an explicit consideration of the consequences of doing so.

The functionality of recursive importing is specified in the Namespace::visibleMemberships operation. If the isRecursive parameter of this operation is true, then the operation calls itself recursively on each Namespace that is a visible member (or any member, if isIncludeAll also is true) of the Namespace the operation was called on originally. This includes not only owned namespaces, but also those that are imported.

Further, the visibleMemberships operation is redefined in Type to also include the visible inheritedMemberships of the Type. This nominally includes memberships inherited via implied Specializations as well as explicitly Specializations. This means that a recursive import will also potentially include a large number of names of standard library elements from Types in the recursive import graph, which is likely not what is intended by the modeler.

So, as currently specified, recursive import unavoidably degrades the performance of any name resolution implementation, while including unintended functionality. To improve this, the following restrictions are recommended on the functionality of recursive import:

1. Require recursive imports to be private.
2. Only recurse on owned Namespaces.
3. Do not included Memberships that are inherited via implied Specializations.

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;

It is allowable to have imports at the top-level in a root namespace. If such an import is public, then anything so imported becomes visible in the scope of the global namespace, without qualification. This can potentially introduce name resolution ambiguities that makes global namespace resolution much more difficult.

For example, consider the following three root namespaces (perhaps from separate textual notation files);

package Namespace1 {
    classifier A;
    classifier B;
}

public import Namespace1::*;
package Namespace2 {
   ...
}

public import Namespace1::*;
package Namespace3 {
   ...
}

The classifiers A and B are now globally available not only as Namespace1::A and Namespace1::B from the first root namespace, but also by the unqualified names A and B from both of the other two root namespaces. (And this ambiguity is not invalid according to the global namespace name resolutions rules in 8.2.3.5.4.)

While it can be useful to be able to import names at the top-level into a root namespace, it does not seem necessary to be able to publicly re-export such names into the global namespace. So, disallowing public imports in the root namespace would simplify global name resolution without really removing any particularly useful functionality.

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.

The OCL for the operation Feature::isFeaturedWithin, as updated in the resolution to KERML-82, is still not correct. If a Feature has no featuringTypes, then it is implicitly "featured within" any Type. Therefore, isFeaturedWithin(type) should always return true in this case. Currently, though, the OCL specifies that it only returns true if type = null.

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;

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.

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 seems to be more restrictive than was intended for this constraint.

1. In 8.3.4.5.3 Connector, in the OCL for checkConnectorBinaryObjectSpecialization, "AssocationStructure" should be "AssociationStructure".
2. In 8.3.4.5.4 Succession, in the OCL for checkSuccessionSpecialization, "Occurences" should be "Occurrences".

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.