What is OML?
OML — Object Modelling Language — isn't a specific
format. It's a category: any language or notation whose job is to
describe structured object data as text. JSON is one. YAML is one.
XML with a schema is one. Protocol Buffers' .proto
files are one. AML — ANVL's own modelling dialect — is one too.
What separates a good OML from an adequate one isn't feature count. It's whether the shapes it gives you already match how you think about objects in whatever language you're actually working in — or whether you have to translate.
The impedance mismatch problem
Every general-purpose language already has native ways to represent structured data: a record/dict/map/struct for keyed data, a list or array for ordered sequences, some flavor of typed literal for scalars. An OML's job is to describe that same shape in text — and the friction shows up exactly where the OML's model and the language's native model don't line up.
JSON gets the basics right (objects, arrays, a handful of scalar types) and that's most of why it won — almost nothing needs translating. But it stops there: no comments, no way to say "this value is the same as that one," no way to say "this shape extends that shape," no metadata channel separate from the data itself. Protocol Buffers goes the opposite direction — rich modelling (messages, enums, oneofs) but only reachable through a schema compiler and generated code, which is its own kind of impedance mismatch: you're not writing your language's native objects anymore, you're writing what the generator handed you.
How AML approaches it
AML's bet: keep the JSON-level shapes that already need no translation (objects, arrays, scalars), then add the handful of things config/data authors actually reach for — by naming them after concepts that already exist in essentially every mainstream language's own type system, not ANVL-specific inventions.
| AML construct | Maps onto | Already familiar from |
|---|---|---|
Object — { ... } |
A record / dict / map / struct | Every language has one |
Array — [ ... ] |
An ordered sequence | Every language has one |
Tuple — ( ... ) |
A fixed-arity, heterogeneous group | Python tuples, C# ValueTuple, Rust tuples, Go multi-return |
Inheritance — Child : Base := { ... } |
A base/derived class relationship | JS extends, Python subclassing, C# : Base, Java extends |
Attributes — @[key=value] |
Metadata attached to a field, separate from its value | Java annotations, Python decorators, C# attributes, Go struct tags |
$identifier VarRef |
A named reference to a value defined once | A variable or named constant, in any language |
None of that requires a schema compiler, a generated-code step, or learning ANVL's own mental model from scratch. If you already think in terms of records, base classes, and annotations — and you probably do, in whatever language brought you here — AML's shapes are ones you already have names for.
What actually makes something an OML
Strip away the syntax and every real OML is doing the same three things: naming a kind of object (a class, a shape, a schema), giving it attributes (the data a given instance carries), and describing how instances relate to each other — composition (one object contains another) and generalization (one shape extends another, inheriting its attributes). Get those three right and the concrete syntax is just a detail; get them wrong and no amount of syntax fixes it.
UML — Unified Modeling Language, the field's own namesake — is the
textbook case, worth checking directly rather than taking "object modeling language" on
faith. A UML class diagram names a class (Vehicle), gives it attributes
(vin: String, year: Integer), and draws a generalization arrow
to a Car class that inherits them and adds its own. Composition — a
Car contains an Engine that doesn't exist independently of it —
is its own distinct relationship, drawn as a line with a diamond. None of that is prose;
it's a formal notation with its own semantics, which is exactly why UML earns the right to
call itself a modeling language and not just a diagramming convention. A stereotype or
tagged value — metadata attached to a class itself, separate from its attributes — is the
same idea AML's own @[key=value] attributes cover.
UML's own concrete syntax is almost always graphical — boxes, arrows, diamonds — with a textual serialization (XMI) that exists mainly for tools to exchange diagrams with each other, not for a person to hand-write. AML is the same three ideas, aimed the other direction: a concrete syntax meant to be hand-written and read as plain text.
| UML concept | AML construct |
|---|---|
| A class, naming a kind of object | An object statement — Vehicle := { ... }; |
| An attribute on that class | A field inside the object — vin := "1FA..."; |
Generalization (Car extends Vehicle) |
Inheritance — Car : Vehicle := { ... }; |
| A stereotype or tagged value on a class | Attributes — @[key=value] |
Same three ideas UML is judged by — naming, attributes, relationships — just written as text a parser reads directly, instead of shapes a tool renders. That's the actual bar an OML has to clear, and it's the same bar AML clears too.