Namespaces and Fully Qualified Names

Where a Block lives

Every BML definition — Blocks, Libraries, types, and every other BlockML definition — must reside below its owning domain's bml package, in the general form domain.bml.*.

Physical layout mirrors the FQN

Physical source layout mirrors the FQN, so a Block's package alone tells a reader exactly where its file lives — no separate directory convention is needed.

How a Library groups Blocks

A Library groups related Block and ValueType definitions into one publishable unit, whose FQN is derived from its own package path; membership is defined exclusively by what the Library's blocks list names, not by directory layout.

Reading a package into a prefix

An xmlns binding maps a short authoring prefix to the full package FQN, so a qualified reference stays readable without repeating the whole package name.

<!-- xmlns:acme binds the prefix "acme" to the package "com.acme.example" -->
<acme:Basket xmlns="http://blockml.org/bml"
  xmlns:acme="com.acme.example"
  xmlns:core="org.blockml.bml.core">

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

The root tag acme:Basket expands to the FQN com.acme.example.Basket, and baseType's core:Block expands to org.blockml.bml.core.Block using the same kind of binding. The prefix in the example is authoring convenience only — the canonical FQN it expands to is what actually identifies the Block, and that FQN is what a reader could reconstruct from the package's physical file location alone.

What to carry into the next pages

After this page, readers should be able to compute a Block's FQN from its package and know what a Library groups, before distinguishing identifiers from references on the next page.

Continue with identifiers and references