Specialized model elements and support boundary

The public core reference focuses on packages, data, services, resources, components, and applications. The CMN grammar also contains specialized families for component behavior, persistence, scenarios, landscapes, and user interfaces.

Their presence in the parser does not by itself promise that every public facility transforms them or generates output. This page identifies the families and points to the public facility contract where one exists.

1. Extended component contents

The grammar permits the following ordered groups inside a component:

1. typed property declarations;
2. use or uses data declarations;
3. route declarations;
4. included component fragments (... Fragment);
5. operations;
6. pages, provide/implement declarations, and persists blocks;
7. nested components.

The order is part of the grammar; these groups cannot be mixed arbitrarily. The general component header, dependencies, API boundaries, and application composition are covered in Components and applications.

Publicly documented generator support is narrower than the grammar:

• Base interprets provided resources and selected component behavior for OpenAPI documents and diagrams; see Components.
• SpringBoot interprets persists for persistence and schema-migration generation; see Flyway schema migrations.
• Quasar experimentally interprets selected pages, routes, data, widgets, and actions; see the Quasar facility.

Component fragments are parser and Core Model constructs. Treat their generated effect as facility-specific until the chosen facility documents a buildable fragment example.

2. Persistence declarations

The grammar shape is:

persists Name [property ...] {
    ComplexType [property ...]
    ...
}

It also accepts a package-wide form with ... Package and an optional exclude list. The package-level exclude list is parsed but not applied by the canonical-model transformation. Do not rely on that exclusion form.

persists has no universal database meaning in CMN. Use only the forms the active persistence facility documents as supported.

3. Scenarios, actors, and behavior

The grammar contains:

• actor and scenario declarations;
• activities and interactions;
• conditions, alternatives, loops, calls, and referenced scenarios;
• implementation pseudocode delimited by [[ ... ]];
• an application's supports { ... } section for scenario references.

Base can interpret selected component and scenario information for diagrams, but the complete scenario grammar is not currently a cross-facility public generation contract. The component-pseudocode subset covered by the public contract is described in Components.

supports is valid application syntax:

application Name {
    supports {
        ScenarioName
    }
}

Use it only when the active facility documents how supported scenarios are processed.

4. Landscapes

A landscape can group owned and used applications:

landscape Name {
    consists of {
        ApplicationName
    }
    uses {
        ExternalApplication
    }
}

The declaration is grammar syntax, but no stable public cross-facility artifact contract is assigned to it.

5. Pages, widgets, routes, and data

The UI-oriented grammar family includes:

• widget, slot, and event;
• page, content, conditions, and action;
• component route declarations;
• resource- and operation-backed data declarations;
• event handling, value expressions, and command flows.

The Pages and Page Conditions reference describes the platform-independent Page structure, Page-local Conditions and their modeling role. Generated bindings, component references, Action aliases, command execution, application shells and output ownership are facility-specific. Consult the selected facility and platform before relying on them. Grammar constructs not covered by that facility are not implicitly promoted to supported output features.

6. Styles and formatters

formatter Name accepts properties and can be referenced by a supporting profile or cartridge. Base, for example, models its UUID format this way.

The grammar also accepts style declarations and a / StyleName suffix in a stereotype specification. JoinedWorkz does not transfer that style selection as a general canonical-model generation contract. Do not rely on styles unless a facility explicitly documents them.

7. Parser-only or partially transferred forms

The following distinctions are especially important when reading the grammar:

• ... ReferencedResource parses as a resource-method spread, but its methods are not transferred.
• package-wide persistence exclude entries are parsed but not applied.
• service abstract and extends clauses parse, but are not transferred to the canonical Core Model.
• page extends parses, but is not transferred as page inheritance.
• additional, excluded, and style-qualified stereotypes are not all transferred reliably; use one positive stereotype unless documented otherwise.
• a standalone unknown identifier can parse as a generic model element without obtaining useful canonical-model semantics.

Parser success therefore proves syntax only. For specialized elements, require the facility documentation and a complete project build before depending on generated behavior.