Aggregations
An owned collection member
An Aggregation describes a Block member that owns a collection of Block instances — its children are always Block instances, and its type attribute selects what kind of Block the collection may hold.
There is no default aggregation
On a Block instance, aggregation children always sit directly inside the named aggregation element — there is no default aggregation, so a bare child instance directly under the parent instance is invalid.
Filling the definition, opening on the instance
An initial fill on the Block definition nests inside composition, but a Block instance opens the same aggregation directly by name with no composition wrapper — the two contexts never mix.
Declaring and filling an aggregation
An aggregation declaration states its payload type and, optionally, an initial composition fill with one child instance.
<!-- Definition: "items" aggregation, with one Widget instance filled by composition -->
<acme:Basket xmlns="http://blockml.org/bml"
xmlns:acme="com.acme.example"
xmlns:core="org.blockml.bml.core">
<baseType>
core:Block
</baseType>
<aggregations>
<items type="acme:Widget">
<composition>
<acme:Widget bml:id="firstWidget" />
</composition>
</items>
</aggregations>
</acme:Basket>
<!-- Instance: opens the same aggregation directly by name, with no composition wrapper -->
<acme:Basket bml:id="myBasket">
<items>
<acme:Widget bml:id="secondWidget" />
</items>
</acme:Basket>
firstWidget, nested inside composition, belongs entirely to Basket's items aggregation — it has no separate existence outside it, which is the ownership the example is meant to illustrate. myBasket then opens that same items aggregation directly, without a composition wrapper, to add secondWidget on the instance.
What to carry into the next pages
After this page, readers should be able to declare and fill an owned collection member and open it correctly on an instance, before contrasting ownership with the non-owning links Associations describe next.