Naming Conventions, Namespaces and Naming Constraints

Naming Conventions for Repositories, Models and Model Versions

• You should assign a model server (repository) a unique name. They are used as directory names in the operating system.

  Please make sure you observe these strict name conventions*:
  [A-Za-z0-9][A-Za-z0-9_]{0,254} (e.g. no umlauts)

  The operating system does also not permit certain abbreviations, whether capitalized or not: CON, PRN, AUX, NUL, COM1 ... COM9, LPT1 ... LPT9.

• Please take the conventions for files names in Windows and the character set Windows‑1252 when naming independent models (unique in the repository) and local model files.

  The following special characters are not permitted: #\ / : * ? " < > |

  The operating system does also not permit certain abbreviations, whether capitalized or not: CON, PRN, AUX, NUL, COM1 ... COM9, LPT1 ... LPT9.

  These model names can have a maximum length of 255 characters, as with repositories.

  These naming conventions are recommended*:
  [A-Za-zÄäÖöÜü0-9_][A-Za-zÄäÖöÜüß0-9_-$()]{0,254}

• Please adhere to the character set Windows‑1252 when naming managed model versions and their back-ups. Conventions for file names under Windows is not relevant.

  The maximum length of the name for model versions is 128 characters.

  These naming conventions are recommended*:
  [A-Za-zÄäÖöÜü0-9_][A-Za-zÄäÖöÜüß0-9_-$()]{0,127}

  You can set alias names for Innovator links for model versions. You can use all valid characters for a URL when choosing the link name*:
  [A-Za-z0-9_-.~]{1,1024}

* Depiction as regular expression, simplified specification without masking characters for meta characters

Namespaces and Packages

Elements need to be able to be differentiated between by their names within their namespaces they are directly linked with. A package is used as an example when grouping elements and provides a joint namespace for these elements directly contained in the package.

Namespaces can be nested and contain elements which can be given names; these elements, in turn, represent a namespace for elements they contain. e.g. classes need to have unique names within a package, operations need to have unique names within a class and parameters need to have unique names within an operation.

A package's contents consists of so-called "packageable elements". Classes, events etc. belong to these, as well as packages themselves; this enables the packages to be hierarchically arranged. A package is the owner of these elements. This means that all elements contained are deleted from a model as soon as this package is deleted.

Unique Naming

The elements' stereotypes can be used when setting namespaces in the configuration. This means you can set whether case sensitivity is relevant, whether they should have a certain minimum or maximum length and in what respect a name has to be unique.

Naming Constraints

Name patterns can be defined for elements in the configuration via their stereotype. Regular expressions are used for this. Stereotypes inherit these name patterns and can then add requirements to these inherited naming constraints.