Language elements and facility-defined names

CMN combines grammar keywords and symbols with ordinary identifiers resolved from models and profiles. The distinction is essential: familiar names in a CMN file are not necessarily built into the language.

1. Core grammar elements

The following groups orient model authors within the grammar:

• File structure: abstract, package, subpackage, import, as, platform, exclude.
• Types and data: type, enum, field, fieldset, relation, specialization of, extends, implements, const.
• APIs: service, resource, methodtype, by, augments, with.
• Components: component, provide, implement, use, uses, persists.
• Applications and architecture: application, consists of, supports, landscape.
• Behavior and UI modeling: scenario, actor, page, widget, route, action, content, conditions, event, slot.
• Flow constructs include if, else, for, continue with, return with, and confirm.

The grammar also recognizes specialized declarations such as style, formatter, and component fragments. Their useful semantics and generated output depend on the selected facility.

This is a language-element index, not a promise that every public facility generates output for every construct. Consult the facility support page before using specialized scenario, UI, style, persistence, or flow elements. The platform-independent syntax and modeling semantics of page and conditions are documented in Pages and Page Conditions. Their generated effect remains facility-specific.

2. Core symbols and forms

Common punctuation has grammar-defined meaning:

Form	Core meaning
/** ... */, ''' ... '''	Equivalent model-documentation delimiters. Ordinary /* ... */ and // ... remain source-only comments.
@description, @summary, @title, @request, @response	Structured sections inside model documentation.
example:, example name:, value:	Example declarations and the optional explicit value boundary inside model documentation.
<...>	Stereotype specification, optionally with a style after /. The names inside are profile- or model-defined.
:	Containment field or type/result separator, depending on context.
->, <>	Reference fields; <-> occurs in bidirectional relations.
*	Mandatory cardinality in a field or parameter position.
**	Key-field marker.
[], [min..max], [KeyType]	Collection, bounded, or dictionary cardinality.
...	Include syntax; the grammar also has a resource-method spread form whose methods are not transferred.
::	Imported-package alias qualifier.
°name	Property flag with implicit true.
=> ... ;;	Opaque statement body on an operation or another supported declaration. An optional identifier before => names an operation statement part.
[[ ... ]]	Implementation pseudocode in supported command positions.

The surrounding grammar determines the meaning. For example, ...Type includes fields from a field container. Although ...Resource parses inside a resource, its method-spread transformation is not implemented and must not be used as a working generation feature.

3. HTTP verbs

GET, POST, PUT, PATCH, and DELETE are grammar values used in a methodtype declaration:

package com.example.api

methodtype export GET

They are not invoked directly as methods inside a resource. A resource method references a method type:

package com.example.api

methodtype export GET

resource /customers {
    export()
}

Here methodtype and GET are grammar-defined. export is a model-defined method type name.

4. Facility-defined names

Facilities contribute ordinary model and profile names, including:

• simple and complex types;
• stereotypes and constraints;
• resource method types;
• properties and their defaults;
• platforms and cartridges.

Examples from the public facilities:

• String, Id, and Name are types imported from Base models;
• entity is a stereotype supplied by the Base profile;
• raw get, post, put, patch, and delete method types are supplied by the Base API model;
• opinionated create, start, execute, read, downloadText, update, deleteInstance, query, and list method types are supplied by Base;
• createEntity, readEntity, updateEntity, queryEntities, and deleteEntity are supplied by SpringBoot;
• properties such as controller, componentNamespace, consumes, produces, and operationName are interpreted through profiles and cartridges.

These names are not reserved CMN keywords merely because they occur in official examples. Other facilities can define additional names; this page is not a global facility registry.

5. Names commonly mistaken for keywords

• A layer such as core, api, or backend is a free identifier before package; there is no layer keyword.
• Service operations are declared directly as find(...); there is no operation keyword.
• Resource methods use a referenced method type such as read(); read is not a keyword.
• entity is a stereotype name, not a type variant in the grammar.
• DTO is a modeling role for a complex type; there is no dto keyword.
• process and call are not CMN grammar keywords. A profile can still define either word as a stereotype, property, method type, or other referenceable name where the grammar permits it.

6. Context-sensitive identifiers

CMN deliberately permits some grammar words as identifiers in positions where the parser can distinguish them. Resource paths additionally allow dash-separated segments such as /customer-accounts.

For stable public contracts:

• prefer conventional identifiers for model elements;
• use explicit imports or aliases when simple names are ambiguous;
• do not infer semantics from an identifier alone;
• check the selected profile before using a name copied from another facility's example.

See Common syntax for documentation, examples, names, labels, properties, and references.