7.3. Namespaces, Packages and Imports

Both Packages and Types are Namespaces, in which every name must be unique. While Types also group elements, their main purpose is to classify and describe things in the domain to be modeled. Packages are only used to group elements for breaking up a large model while avoiding name conflicts. Namespaces can contain other namespaces.

An example of a package is the following:

package Annotations {
  metaclass ApprovalAnnotation {
    feature approved[1] : Boolean;
    feature level[1] : Natural;
  }
  ...
}

Imports of either specific or all elements of a package allow using these elements in other namespaces:

private import Annotations::*;
struct System {
  @ApprovalAnnotation {approved = true; level = 2;}
  ...
}

Depending on whether an import is public or private, the imported elements are either available or not available in other namespaces importing

As explained by Ed Seidewitz in a Feb 2026 forum post:

A KerML/SysML v2 model consists of a root namespace and all the elements directly or indirectly contained in that namespace. The direct owned members of a root namespace are called top-level elements. The public top-level elements of a root namespace are globally visible to other root namespaces. If a name cannot be resolved locally (i.e., within the context of a single root namespace), then the search continues with the globally visible names from all other available root namespaces. Per the KerML Specification (see, in particular, subclauses 8.2.3.5.2 Local and Global Namespaces and 10.3 Model Interchange Projects):

• The root namespaces from all the standard library models are always available.
• A project is a set of root namespaces that are all available to each other.
• If a project uses other projects, then the root namespaces of all used projects are available to the using project.

A .sysml file corresponds to a single root namespace. In the Pilot Implementation (in Eclipse), a "project" is an Xtext project in the workspace, and the root namespaces from all the .sysml (and .kerml) files in a single Xtext project are available to each other, regardless of directory structure. One project "uses" another by configuring the first project in Eclipse to have a "project reference" to the second project. And every project must have a reference to the sysml.library project. (For historical reasons, all the library models are under a single project in Eclipse, even though normatively each model library is a separate project.)

Ultimately, the intent is that project dependencies can be managed in a tool-independent way using KerML Project Archive (KPAR) files (at least for file-based interchange).