Less is morML

In a world overloaded with JSON, YAML, TOML, and XML, there’s room for a new approach — a minimalist, human-readable configuration language that treats arrays and objects naturally, without punctuation noise. Enter morML — the mORMot-inspired Configuration Language.

⚠️ Disclaimer: morML is a conceptual format, not yet implemented anywhere. It’s an idea for a cleaner, smarter alternative for configuration files. It is not a general-purpose exchange format like JSON or YAML.

The Philosophy of morML

First, you can pronounce it "more-ML", "mormal" - as you wish. We don't care enough.

The core idea is simple:

Readability Comes First Indentation defines hierarchy. Repeated property names define arrays. No braces, no brackets, no closing symbols — just clean, human-friendly structure.
Arrays Are Repeated Keys Instead of [ ] or commas, arrays are expressed by repeating the property name. For example, a DHCP server might have multiple pools:

scope
  name office
  pool
    min 192.168.10.20
    max 192.168.10.50
  pool
    min 192.168.10.100
    max 192.168.10.150

Here, the parser recognizes pool occurs twice, so it’s an array — no punctuation or “pools:” key needed.

Nested Arrays & Rules morML handles nested arrays naturally. Repeated rule or static keys form arrays, even inside pools or PXE blocks:

pool
  min 10.0.50.30
  max 10.0.50.70
  rule
    all
      user-class iPXE
    always
      tftp-server-name 10.0.50.5
  rule
    any
      vendor-class PXEClient
    requested
      boot-file-name ipxe.efi

Repeated rule keys indicate multiple rules — clean and obvious, no commas or braces required.

RTTI — Making Arrays Type-Safe

To distinguish between a single object and an array with one element, morML proposes using RTTI (Run-Time Type Information):

Each property’s type is inspected at runtime.
If RTTI marks it as an array, even one repeated key counts as an array.
If RTTI marks it as a single object, it’s treated as one object.

This makes morML both human-readable and type-aware, without relying on punctuation or explicit array syntax.

Why morML Matters

Human-first: easily scanned top-to-bottom, like an outline.
Machine-friendly: arrays and objects are unambiguous when RTTI is used.
Minimalistic: no braces, no brackets, no closing symbols.
Diff-friendly: adding a new pool, rule, or static is just repeating the key.

Imagine configuring DHCP scopes, PXE rules, or hierarchical policies with a few readable lines — no JSON braces or YAML indentation quirks to slow you down.

Example morML Config Snippet

scope
  name office-with-pxe
  subnet 10.0.50.0/24
  gateway 10.0.50.1
  pool
    min 10.0.50.30
    max 10.0.50.70
    rule
      all
        user-class iPXE
      always
        tftp-server-name 10.0.50.5
    rule
      any
        vendor-class PXEClient
      requested
        boot-file-name ipxe.efi
  pool
    min 10.0.50.100
    max 10.0.50.150

Arrays are implied by repeated pool and rule keys — no brackets, commas, or colons required, yet the hierarchy and multiplicity are clear.

The Underground Philosophy

morML embodies a rebel approach to configuration:

Minimal syntax, maximal clarity.
Arrays defined by repetition, hierarchy defined by indentation.
RTTI-aware parsing ensures type correctness and array/object distinction.
Human-readable, machine-parsable, and diff-friendly.

It’s a vision for a future where config files are concise, readable, and intelligent — proving that less really is more.

morML Tutorial Example: Full DHCP & PXE Config

Here’s a full, tutorial-style morML example showing multiple scopes, pools, PXE rules, MACs, and UUID statics — using repeated keys to indicate arrays throughout. It’s fully in the minimalistic style we discussed:

scope
  name office
  subnet 192.168.10.0/24
  gateway 192.168.10.1
  dns 8.8.8.8,1.1.1.1
  main
    min 192.168.10.100
    max 192.168.10.240
  pool
    min 192.168.10.20
    max 192.168.10.50
    static
      192.168.10.20
      00:11:22:33:44:55 192.168.10.25
      2f:af:9e:0f:b8:2a 192.168.10.30
      550e8400-e29b-41d4-a716-446655440000 192.168.10.35
  pool
    min 192.168.10.200
    max 192.168.10.230
    static
      aa:bb:cc:dd:ee:ff 192.168.10.210

scope
  name office-with-pxe
  subnet 10.0.50.0/24
  gateway 10.0.50.1
  main
    min 10.0.50.100
    max 10.0.50.240
  pool
    min 10.0.50.30
    max 10.0.50.70
    all
      circuit-id LAB-PXE
    rule
      all
        user-class iPXE
        client-architecture 5
      always
        tftp-server-name 10.0.50.5
        vendor-class-identifier PXEClient
      requested
        boot-file-name undionly.kpxe
    rule
      any
        user-class Realtek
        vendor-class PXEClient:Arch:00007
      always
        tftp-server-name 10.0.50.5
      requested
        boot-file-name ipxe.efi
  pool
    min 10.0.50.100
    max 10.0.50.150
    static
      aa:bb:cc:dd:ee:ff 10.0.50.120

scope
  name new-pxe-subnet
  subnet 10.1.100.0/24
  gateway 10.1.100.1
  main
    min 10.1.100.100
    max 10.1.100.200
  pool
    min 10.1.100.101
    max 10.1.100.150
    all
      circuit-id LAB-TEST
    rule
      all
        user-class iPXE
        client-architecture 5
      always
        tftp-server-name 10.1.100.5
        vendor-class-identifier PXEClient
      requested
        boot-file-name undionly.kpxe

✅ What This Shows

Multiple scopes: scope repeated for each subnet.
Pools as arrays: pool repeated within each scope.
Nested arrays of rules: rule repeated inside each pool, with all and any blocks.
Statics for IPs, MACs, and UUIDs: clearly distinguished without extra punctuation.
Human-readable hierarchy: indentation alone shows parent-child relationships.
Diff-friendly: adding/removing pools or rules requires just adding/removing blocks — no braces, brackets, or commas.

This illustrates the full potential of morML: minimal syntax, fully hierarchical, and expressive enough for complex DHCP/PXE setups — all without JSON verbosity or YAML noise.

synopse/morML.md

Select an option

No results found