Model one situation at a time
In the rebooking example, the language must identify the service that cancelled the appointment and the person who may have asked to close the case. It must also identify the team responsible for the next action, the deadline, the exception and the rule version that applied.
That small situation introduces the main kinds of meaning CoreLang is expected to describe:
- people, organisations, roles and authority;
- facts and the sources from which they came;
- events and the changes they cause;
- work, responsibility and deadlines;
- decisions, rules, obligations and exceptions; and
- dates, times and policy versions.
The first version should include only the parts needed by a few worked examples. More general features should be added when another example requires them.
Keep meaning separate from its written form
A semantic model is a structured record of what a statement means. For the rebooking rule, it might record the responsible team, the deadline of five working days and the exception for a closed case. Those meanings should remain the same if the rule is displayed as text, a table or a form.
The visible form is called the notation. CoreLang may begin with readable text, but its notation has not yet been agreed. It should not pretend that unrestricted English is precise. Related constructs should use the same ordering and naming rules, and an important ambiguity should produce a clear error instead of a guess.
Do not expose execution machinery as business language
The first implementation may translate executable parts of CoreLang into RXAS, the readable assembly language used by the CREXX tools. That choice must not expose registers or bytecode instructions in CoreLang, and it would not make CoreLang use the syntax of the separate cREXX language.
Some CoreLang material may describe a domain without running at all. Execution is useful for a calculation or decision rule; it is not a requirement for every model.
Use the old work as history, not specification
Earlier CoreLang drafts explored packages, functions, classes, delegation and persistence. They remain useful language-design history. The new business language will not treat that general-purpose draft as its current specification.