Capabilities

Behaviour, expressed as a member

There are no special language concepts for constructor, getter, setter, or render — all behaviour is expressed as ordinary Capabilities, declared like any other member.

Four communication shapes

A Capability's kind describes its payload shape: Inbound requires only inputType, Outbound requires only outputType, Transformation requires both, and Action requires neither.

What an implementation body means

A Capability implementation is a language-tagged body that may serve as intent for humans and LLMs, as a companion template a renderer transpiles, or as a deterministic function a host evaluates — with no ranking among these readings.

Declaring a Transformation capability

A Transformation capability declares both inputType and outputType, alongside an implementation body tagged with its language.

<!-- priceWithTax is a Transformation: it declares both inputType and outputType -->
<acme:Basket xmlns="http://blockml.org/bml"
  xmlns:acme="com.acme.example"
  xmlns:core="org.blockml.bml.core"
  xmlns:cap="org.blockml.bml.capability"
  xmlns:type="org.blockml.bml.type"
  xmlns:lang="org.blockml.bml.language">

  <baseType>
    core:Block
  </baseType>
  <capabilities>
    <priceWithTax type="cap:Transformation" inputType="type:Decimal" outputType="type:Decimal">
      <implementation language="lang:PseudoCode">
        return input * 1.19
      </implementation>
    </priceWithTax>
  </capabilities>
</acme:Basket>

priceWithTax's type, cap:Transformation, is what requires both inputType and outputType to be present; its PseudoCode implementation states intent for a human or LLM reader, while a renderer or host remains free to read the same body as a template to transpile or a function to evaluate — neither reading is mandatory.

What to carry into the next pages

After this page, readers should be able to declare a Capability and know there is no separate constructor concept, closing out the four member kinds before override mechanics get their own page.