CMN reference

The CMN reference describes the public core of Canonical Model Notation (CMN). It is a syntax-oriented lookup resource for model authors. Conceptual explanations and guided workflows remain in the Modeling section.

Reading the reference

The same CMN syntax combines three different kinds of information:

Kind	Meaning
CMN grammar	Syntax parsed by the CMN language itself, such as type, resource, component, cardinalities, and reference forms.
Profile/facility-defined	Names and metadata supplied by an imported model or selected platform, such as String, the entity stereotype, read, or controller. Other facilities can add their own names.
Generator semantics	The effect a cartridge gives to valid model information, such as generating Java sources, OpenAPI documents, or diagrams.

The reference marks facility and generator behavior where it matters. A valid grammar position does not make every property, stereotype, type, or method type universally available: the selected platform and imported models must provide the referenced names.

Contents

File and common syntax

• File header & packages Declaration order, packages, relative and absolute subpackages, layers, imports, aliases, platform selection, and cartridge exclusions.

• Common syntax Documentation delimiters, structured descriptions, summaries, request and response sections, named examples, labels, abstract, stereotypes, styles, properties, values, names, and references shared by several model elements.

Types and data

• Simple types Facility-provided and custom simple types, constants, arguments, and specialization.

• Complex types Containments (:), references (->), cardinalities, dictionaries, fieldsets, relations, and field inclusion.

• Enums Enum declarations, values, properties, and usage.

The terms entity and DTO describe roles assigned to complex types. entity is a Base stereotype, not a CMN keyword; DTO is a modeling role rather than a separate grammar element. See Entities & DTOs for the conceptual distinction.

Services and resources

• Services & operations Services, grammar relationships and their current support boundary, operations, parameters, return types, opaque statement bodies, named statement parts, and augmentation.

• Resources & method types Resources, nested paths, method types, parameters, identifiers, representations, responses, and generated operation names.

Components and applications

• Components & applications Component boundaries, provided and internal APIs, dependencies, uses, component behavior, and application composition.

Pages and UI

• Pages & page conditions Platform-independent Page structure, data, content, Page-local derived Conditions and the boundary between CMN modeling and facility output.

Rules and language boundary

• Additional model elements Public-support boundaries for specialized component, persistence, scenario, landscape, UI, style, and behavior syntax.

• Validation Syntax and linking checks, active core validation rules, Maven-wide package uniqueness, and facility-specific validation.

• Language elements and facility-defined names Grammar keywords and symbols, HTTP verb values, and the distinction from names contributed by facilities.

Scope

This section covers the public core used to model packages, data, services, resources, components, and applications. The grammar also contains specialized constructs for scenarios, actors, landscapes, widgets, routes, styles, fragments, and command flows. Their availability and generated effect depend on the selected facility; they are listed in the language-element index but are not presented as universally supported output features. Pages and Page Conditions have a separate platform-independent CMN reference; generated effects remain part of the selected facility's contract.

For the platforms documented publicly:

• Base, Java, and SpringBoot are stable;
• Quasar is experimental.

The syntax reference does not make unpublished or internal facilities part of the public support surface.

Syntax and generated behavior

Valid CMN syntax alone does not prove that imports resolve, a profile supplies every referenced name, a semantic validator accepts the model, or a particular cartridge generates the intended artifact.

Use the buildable examples for complete models and the relevant facility page for generator behavior. A Maven build of the complete project is the authoritative check for cross-file resolution, build-wide validation, and generation.