Extending OOML
A general-purpose modelling language cannot anticipate every industry, technology, governance regime or downstream representation. OOML therefore aims to provide a stable core together with mechanisms through which more specialized semantics can be expressed outside that core.
Classes as the primary modelling abstraction
Where a domain concept needs additional structure, model it using classes rather than continually expanding the primitive type system.
This keeps the language small and mirrors a familiar pattern from modern programming languages: semantically meaningful value objects are built from simpler primitives rather than added to the language one at a time.
A postal address, a monetary amount or a measurement with a unit are all better expressed as modelled structures than as new built-in types.
Metadata profiles
Typed model metadata provides a second dimension of extensibility. A metadata profile can describe information required by a particular organization, standard or tool without altering the underlying domain hierarchy.
The model remains an OOML model. Additional profiles give specialized consumers more information about how that model should be interpreted or processed.
A plugin-like ecosystem without plugins in the language
OOML’s metadata architecture has a plugin-like quality without requiring executable plugins to be part of the specification.
A tool can publish a model describing the metadata it understands. Models that wish to participate can provide metadata conforming to that definition. The tool can then consume it deterministically, because the shape of what it will receive was itself modelled.
If multiple implementations converge on the same metadata model, that model can become a shared community profile rather than a vendor-specific extension. Ecosystem conventions can therefore evolve independently of the core language, and standardize on their own timescale.
Two kinds of extension, kept separate
Inheritance expresses semantic specialization in the domain: a subclass genuinely is a more specific kind of its superclass.
Metadata profiles add information about model elements — governance, provenance, tooling instructions — without claiming anything about what the modelled concept is.
Keeping these separate matters. Domain inheritance hierarchies should not be reshaped to attach tooling or governance concerns where metadata is the appropriate mechanism.