Example:

The example defines a default namespace, an additional namespace with prefix "c", three scopes, and a default type system.

Name

The model name. Required.

 

Namespaces

Namespaces are globally unique identifiers. We use URIs to identify namespaces.

The default namespace

The default namespace identifies the model, therefore it is mandatory. The default namespace applies to all assets within the model that do not specify a namespace prefix.

Namespace prefixes

All other namespaces must be declared with a prefix. The syntax is prefix=namespace. All namespace prefixes used in assets must be declared here.

 

Scopes

defines a limited context for the model. Multiple scopes are allowed. A typical example for using scopes is versioning.

All assets are valid within the specified model scope(s), unless an asset specifies a particular scope. The definition of scopes is optional. If no scope is supplied, the model is valid in a global scope.

 

Type systems

The type systems used for simple types, e.g. Java, XML Schema, SQL. 

Type systems are identified with a globally unique URI.
First, we define a default type system that applies to all types within the model that do not specify a type system prefix.
Then we define all type system prefixes used in the model. The syntax is prefix=typeSystem.
The definition of type systems is optional but should be declared when types are used in assets.

Subject Ontologies

The ontologies used for definining Subject IDs.

Ontologies are identified with their namespace URI. A typical example would be urn:oasis:names:specification:ubl:schema:xsd:CommonBasicComponents-1.0.
First, we define a default subject ontology system that applies to all subject IDs within the model that do not specify a prefix.
Then we define all subject ontology prefixes used in the model. The syntax is prefix=subjectOntology.
The definition of subject ontologies is optional. Subject IDs are allowed to specify their namespace exlipicitly.

 

Constraint language

The language used for specifying constraints, e.g. OCL, XPath, or a user defined abstract constraint language. 

Constraint languages are identified with a globally unique URI.
First, we define a default language that applies to all constraints within the model that do not specify a constraints language prefix.
Then we define all constraint language prefixes used in the model. The syntax is prefix=constraintLanguage.
The definition of a constraint language is optional but should be declared when constraints are used in assets.
For abstract constraints a constraint vocabulary can be specified instead using the syntax prefix=constraintVocabulary. A special vocabulary named ##local can be used to specify abstract constraint names without restriction. In this case the constraint names belong to the asset namespace. Otherwise, constraint names belong to the namespace of the specified vocabulary.

 

Operation vocabulary

The user defined vocabulary used for specifying operations. 

Operation vocabularies are identified with a globally unique URI.
First, we define a default vocabulary that applies to all operations within the model that do not specify a vocabulary prefix.
Then we define vocabulary prefixes used in the model. The syntax is prefix=operationVocabulary. 
The definition of a vocabulary is optional but should be declared when operations are used in assets. A special operation vocabulary named ##local can be used to specify operation and mode names without restriction. In this case the operation and mode names belong to the asset namespace. Otherwise, operation and mode names belong to the namespace of the specified operation vocabulary.

 

Annotations

The definition of annotations is optional. 

 

Design Patterns

lists all Design Patterns applied to this model. Each Design Patterns is specified with its default namespace (which identifies the pattern) and the (optional) location of the pattern. The location does not identify the pattern but acts as a hint where the pattern can be found. The syntax is {namespace, location}. 
The patterns and the current model are combined according to the merging rules. 

 

Submodels

lists all included submodels. Each submodel is specified with its default namespace (which identifies the submodel) and the (optional) location of the pattern. The location does not identify the submodel but acts as a hint where the pattern can be found. In addition, a prefix is specified denoting the submodel's default namespace in the context of the current model. The syntax is prefix={namespace, location}. 
The submodels and the current model are combined according to the merging rules.