Sub-Blocks

A nested definition, sharing the parent's FQN prefix

A Sub-Block is a Block definition nested inside a parent Block, analogous to a Java static nested class — it shares the parent's FQN prefix and may declare its own generic type parameters.

Deriving a Sub-Block's identity

Preferred authoring uses the unqualified element tag under subBlocks as the Sub-Block's name, while its type is normally omitted and derived as the parent's resolved type plus a dot plus that name.

No outer generic or instance scope

A Sub-Block has no enclosing-instance and no outer generic-type scope — a parameter declared on the enclosing Block must be forwarded explicitly on the Sub-Block's own baseType if it is still needed there.

Nesting one Sub-Block

A parent Block nests one Sub-Block under subBlocks, using the unqualified tag as the Sub-Block's name with no explicit type needed.

<!-- Handle's tag under subBlocks supplies its name; no type element is needed -->
<acme:Basket xmlns="http://blockml.org/bml"
  xmlns:acme="com.acme.example"
  xmlns:core="org.blockml.bml.core">

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

Handle resolves to com.acme.example.Basket.Handle — the parent's own FQN with its tag name appended after a dot — exactly the derivation rule this page states, with no explicit type needed to see it.

What to carry into the next pages

After this page, readers should be able to nest a definition inside a parent Block and know how deep nesting resolves, before Embedded Blocks contrasts this with a very different kind of nested document.

Continue with embedded Blocks