KERML_ — Make imports private by default

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.

Make imports private by default

As stated in the issue, it makes sense to have the visibility of an Import default to private in the abstract syntax. However, it is still desirable to have the visibility of a Membership default to public. This inconsistency could be confusing to a modeler. Therefore, this resolution requires that the the visibility of an Import always be shown in the concrete syntax, even if it is the default visibility of private.

In addition, it is confusing that protected visibility is currently allowed for Imports, but is stated in the Language Description as being the same as private for Imports, even for the purposes of Specialization. Therefore, the resolution also removes that statement from the Language Description, explicitly allowing protected imported memberships. This also further permits a modeler to avoid public imports when only visibility to subtypes is desired, which is consistent with the intent of the issue to promote limited use of public imports.