xYang.mojo - experimenting with compile-time semantic modeling in Mojo

Community Showcase
1

I’ve been experimenting with using Mojo’s comptime model to make schemas and semantic constraints executable instead of treating them as passive runtime metadata.

The project is called xYang.mojo.

The basic idea is:

  • model YANG-style constraints as parametric Mojo types

  • validate what can be validated at compile time

  • derive runtime validators and JSON Schema artifacts from the same semantic source of truth

For example, this shopping cart demo models purchase semantics directly in Mojo types:

@fieldwise_init
struct PurchaseItem(ImplicitlyDestructible, Movable, YangModeled):
    var sku: YangLeaf[
        YangBuiltinString,
        YangConstraints[
            MaxStringLength[64],
            Must=YangMust["/catalog/item[sku = current()]"],
        ],
    ]

    var quantity: YangLeaf[
        YangBuiltinUInt16,
        YangConstraints[
            Range=YangRange[1, 999],
        ],
    ]

That Must constraint references the catalog directly:

must "/catalog/item[sku = current()]"

which means:

  • purchase requests can only reference known SKUs

  • the validator derives this from the schema model itself

  • the same constraint participates in compile-time reflection checks and runtime validation

The response model also carries conditional semantics:

var discount_percent: YangLeaf[
    YangBuiltinUInt16,
    YangConstraints[
        Range=YangRange[0, 100],
        When=YangWhen["count(../item) >= 3"],
    ],
]

which encodes:

  • the field is only semantically valid when the cart contains 3+ distinct line items

I’ve also been experimenting with compile-time validation/reflection:

comptime assert (
    _CART_REFLECTION_OK
), "CartContainer fields do not match schema"

and:

comptime assert (
    _SCHEMA_PARSE_OK
), "embedded APP_SCHEMA_JSON failed parse"

The demo currently includes:

  • YANG AST/model

  • text YANG parser

  • JSON Schema + x-yang parser

  • XPath subset parser/evaluator

  • runtime validator

  • compile-time validation experiments

  • generated module reflection

  • small REST shopping cart example

One reason I chose YANG instead of plain JSON Schema is that it can express relationships JSON Schema handles poorly or not at all:

  • must

  • when

  • leafref

  • conditional presence

  • referential integrity

  • XPath-based semantic constraints over a data tree

Example:

must "../type != 'ethernet' or ../mtu <= 9000"

This is still very experimental, but Mojo’s comptime execution model makes some surprisingly interesting things possible here:

  • executable schemas

  • schema-derived validators

  • compile-time semantic checks

  • generated JSON Schema/OpenAPI projections

  • schema-grounded LLM tool definitions

  • typed service contracts without external codegen

I’m particularly interested in feedback around:

  • comptime modeling patterns

  • trait organization

  • parametric schema descriptors

  • compile-time/runtime boundaries

  • parser architecture in Mojo

  • whether this kind of semantic infrastructure feels useful in the Mojo ecosystem

Repo: GitHub - exergy-connect/xYang.mojo: Mojo version of the xYang Python library, supporting a subset of YANG constructs for data validation · GitHub