CoreLang

A common starting point, not a mandatory language

Suitable business languages should be able to reuse CoreLang's proposed structure and tool connections while keeping control of their own words and meaning.

Content-authored diagram

Add domain meaning to a reusable language base

A related business language would combine its own vocabulary and checks with common CoreLang conventions and tool connections.

  1. Business need

    People identify a rule or model that is difficult to express consistently with existing tools.

  2. CoreLang common base

    Proposed shared conventions cover structure, names, versions, source locations and tool connections.

  3. Domain vocabulary

    The language defines the words, distinctions and checks recognised by people in that field.

  4. Domain-language source

    Authors combine the shared structure with the vocabulary needed for their work.

  5. Editing and validation

    A parser checks the source and returns highlighting and clear errors through the editor connection.

  6. Useful result

    The language may produce a checked model, document, diagram or executable rule.

Read the connections
  • Business needCoreLang common base: select reusable conventions only when they fit.
  • CoreLang common baseDomain vocabulary: supply shared structure without defining domain meaning.
  • Domain vocabularyDomain-language source: give authors the terms needed for their work.
  • Domain-language sourceEditing and validation: parse and check.
  • Editing and validationUseful result: return errors or produce an agreed output.
Every step in this CoreLang common-base composition remains proposed. A second worked language will test whether reuse saves effort without distorting its meaning.

Reuse the repeated work

A rebooking language may use terms such as appointment and offer date. Another business language may use neither. They may still need the same ways to name a rule, state a condition, record an exception, attach a version and point to an error in the source.

The proposed CoreLang common base would provide those repeated language and tooling conventions. If the base is built and proves suitable, a new language could reuse agreed conventions and tool connections instead of defining each one from the beginning.

Keep each language responsible for its meaning

The common base should not define what an appointment, grant or obligation means. Each language owns its vocabulary, business distinctions and validation rules. It also decides which views people need and whether any part should run as executable logic.

This distinction matters when a shared word has different consequences in two fields. Reuse is helpful only when it preserves the meaning that the people in that field recognise.

What the first base may contain

The initial design will test whether it is useful to share:

  • consistent rules for names, structure, conditions, exceptions and versions.
  • parser conventions and locations that let an editor point to the relevant source text.
  • hooks through which a language adds its own meaning and validation.
  • connections to DSLSH and THE for editing and error messages.
  • an optional route to the CREXX execution tools for suitable executable examples.

These are design candidates, not implemented CoreLang features.

Test acceleration rather than assume it

The common base should be judged by a second language. The test is practical: which parts can it reuse unchanged, how much work does that save, and does any shared convention make the language harder for its intended readers to understand?

If the base distorts the domain or adds more machinery than it removes, that language should use another approach. DomainLang will record both successful reuse and rejected choices so that the general method can improve.

Related work

What the other projects contribute

  • DomainLang will assess whether the common base saves work without distorting a language.
  • DSLSH, THE and CREXX provide tool connections that the common base may reuse.