Show TOC

NamingLocate this document in the navigation structure

Use

Every component, either a software component (SC) or a development component (DC) has a globally unique name. Component names are structured hierarchically and contain a unique vendor ID. You must define the name when you create the component; the name cannot be changed later.

The segments of a name are separated by slashes (/), and must start with the unique vendor identifier, followed by at least one more segment.

The syntax for component names is defined by the following rules:

component_name = vendor_id "/" name_segments
vendor_id      = *( domainlabel "." ) toplabel
domainlabel    = alphanum | alphanum *( alphanum | "-" ) alphanum
toplabel       = alpha | alpha *( alphanum | "-" ) alphanum
name_segments  = segment *( "/" segment )
segment        = *pchar
pchar          = alphanum | mark
mark           = "-" | "_" | "." | "!" | "$"
alpha          = "a" .. "z"
alphanum       = alpha | "0" .. "9"
Example

According to this pattern, allowed names are:

  • sap.com/technology/logging, example.org/component_1.0

  • example.org/customer-releations/accounting .

In this case, sap.com and example.org are vendor IDs derived from Internet domains.

The following names are not allowed:

  • accounting (vendor ID is missing)

  • example.org/component~accounting ("~" is forbidden)

  • example.org/Component/ACCOUNTING (no uppercase)

The development infrastructure restricts the overall length of a component name to 40 characters . The requirements concerning the case, the character set to be used, and the maximum length of component names originate in the restrictions for paths and field names when the components are mapped to the file systems of certain operating systems.

Note

Use only lowercase letters in DC names and uppercase letters in SC names.

Besides this technical name, a component should have a legible name intended for displaying and browsing. Define this display name when you create the component; it can contain any character from the Unicode character set.

Tips for Naming Components

When naming components, adhere to the following rules:

  • The names of the components must be globally unique and static. The name of a component must be defined upon creation of that component and must not be changed afterwards.

  • Dependencies between SCs are not declared for actual states or versions. Therefore, the names of software components should not contain explicit version or release identifiers.

    Example

    Avoid names like example.org/component_1.0 and example.org/technology_6.30 .

    Instead, use simple names like example.org/component and example.org/technology .

  • The assignment of DCs to SCs is not static and may change over time. Therefore, the name of a DC must not contain the name of the SC to which it will be assigned, nor a version or release identifier of the SC.

    Example

    Avoid names like example.org/sc/1.0/accounting . Instead, simply use example.org/accounting . Only if it serves to avoid ambiguity (for example, if another SC contains a component of the same name) can it be reasonable to use the SC name as a prefix, for example, example.org/sc/accounting .

  • Dependencies between DCs are not declared for actual states or versions. Therefore, the names of components should not contain explicit version or release identifiers.

    Example

    Avoid names like example.org/accounting/release_6.30 . Instead, simply use example.org/accounting .

  • The parent/child relationship between DCs is not static and may change over time. The name of a child DC can reflect the enclosure relationship, but this is not recommended because such a name may lead to confusion when the relationship is changed. If it is probable or known that the structure of a component hierarchy will change (for example, a child component will be taken out of its parent's enclosure), the name must not refer to the relationship.

    Example

    The name example.org/customer_releations/accounting can become a problem if example.org/customer_releations/accounting is now a child component of example.org/customer_relations , but is meant to be assigned to the new component example.org/financials later.

  • Certain states of a DC may simultaneously be referenced from different workspaces (for example, from DEV and CONS). Therefore, the workspace identifier must not be part of the DC's name.

    Example

    Avoid names like example.org/accounting/DEV and example.org/accounting/CONS .

  • Component names should not contain versioning or state information of any kind. This includes, for example, things like specification and implementation versions used on the Java EE platform.

  • Component names must have a globally unique vendor identifier. This identifier is usually derived from an Internet domain that belongs to the vendor (for example, sap.com ).

    Example

    If the Internet domain with the identifier example.org belongs to you, use it as a prefix to your component names, for example, example.org /a ccounting. This makes your component names unique among all vendors.

  • Component names should not contain identifiers of developers, groups, or departments of a company. Responsibilities may change, but component names must not. Furthermore, do not use time-stamps, dates, hosts, and so on.

    Example

    Avoid names like example.org/department4711/accounting , example.org/john.dow/accounting or

  • example.orgaccounting/09_11_2003_09.27pm. Component names should reflect the intended purpose and functionality of a component, and nothing else.