BML Namespaces

Prefixes that resolve to packages

An xmlns declaration binds a short authoring prefix to a full package — the mechanism behind every qualified reference this handbook's examples have used, from core:Block onward.

Every definition lives under a bml package

Every BML definition must reside below its owning domain's bml package, in the general form domain.bml.* — the same rule this handbook's Namespaces and FQNs page introduced, now tied directly to the xmlns prefixes that address it.

A bare prefix means BlockML core

A bare short prefix such as core or type conventionally names BlockML itself, while a domain mirroring the same segment adds its own token in front — mb for MachineBlocks core, for example — so authors never steal a framework alias for domain use.

Declaring a prefix for a new package

A new Block document declares an xmlns prefix for its own domain package, placed under that domain's bml namespace, alongside a core prefix for anything it extends from BlockML itself.

<!-- "acme" names this document's own domain package; "core" names BlockML core -->
<acme:Widget xmlns="http://blockml.org/bml"
  xmlns:acme="com.acme.example"
  xmlns:core="org.blockml.bml.core">

  <baseType>
    core:Block
  </baseType>
</acme:Widget>

acme resolves to com.acme.example, the domain package this document's own definitions live under, while core resolves to org.blockml.bml.core and is used only for baseType. Both prefixes in the example are pure authoring convenience over the two package FQNs they name — exactly the mechanism this handbook's examples have relied on from the very first page.

What this handbook has covered

Readers can now declare an xmlns prefix and place a new definition under the correct package — the last piece of a path that began with BlockML's basic purpose and moved through Blocks, the type system, the member model, and behaviour and values, to this handbook's own authoring format.

Back to the handbook contents