Composable XML with strict block separation.

Section 01The thesis

The Memeroot composable XML architecture takes a position that is older than the systems it competes with: structure goes in one block, content in another, never the same file. Then projects them through a universal lens (TABLE_SPECIFICATIONS) into a single addressable surface where any query against any block kind returns rows in the same canonical shape.

The pattern is not new. It is the same pattern that the MBI_SCRIPT framework has used in production for a decade, that Bach used to organise the Well-Tempered Clavier, that ISO 8601 uses to address time, that Codd's relational model uses to address data. What is new in this iteration is that the framework is specified as composable XML blocks with explicit projection stylesheets, so it can be implemented in any database, any file system, any in-memory engine, against any storage substrate, without rewriting any of the model itself.

The thesis in one sentence: separation in storage, unification in projection.

Section 02Five axioms of the substrate

Axiom I · Purity of resolution

Every value resolves to exactly one canonical byte sequence. No whitespace tolerance, no attribute-order tolerance. A value matches a hash exactly or it does not.

Axiom II · Byte-stability

Parse then serialise must reproduce the same bytes. If a roundtrip changes one byte, signatures break, hashes break, the audit trail breaks. XSL projections are byte-stable transforms; the spine is byte-stable; the unit composition is byte-stable.

Axiom III · Null-strict canonicalisation

No fuzzy matching, no cosine similarity, no “close enough”. A spine row matches an address exactly or it does not. The spine has no probabilistic membership.

Axiom IV · Content addressing

The address of a cell is the cell's identity. Move a block from one file system to another; the addresses of its rows do not change. The spine is the universe of addresses; the blocks are projections into it.

Axiom V · Total provenance

Every spine row carries spec-source identifying the block kind that produced it. Anonymous content can exist, but it is marked as such; it cannot pose as attested. Where a block carries a cryptographic signature, the signature transits with the projection.

Section 03The block kinds

Section 04Strict separation rule

The rule

A block of any kind MUST NOT contain elements of another block kind. Period. The XSD or RNG schema for each block kind disallows the namespaces of all other block kinds at every level. The validator rejects cross-kind inclusion with a hard error.

Cross-references between blocks use the address attribute pattern: <schema-ref address="OWNER.NAME"/>, <invokes kind="script-block" address="OWNER.NAME"/>. The reference is a coordinate; the target is resolved at composition time by querying the spine.

Why this matters

Composability

A schema-block can be authored by a database architect, a script-block by a developer, a template-block by a code-generation specialist, a data-block by an analyst, a process-block by an orchestration engineer — independently, in different repositories, in different versions, with different signatures. The compose-unit step reads them all and produces the unified spine. Composability comes from the discipline, not from a magic tool.

Addressability

Every cell in the universe has exactly one address. The address is (target-owner, target-name, target-attribute, target-id?). Multiple block kinds can project rows at the same address, but each projection carries its spec-source so the consumer knows which lens to use. No collision; no overwriting; preservation of all views.

Substitutability

Want to swap MBI_SCRIPT's CREATE_TABLE template for a different generation engine's DDL pattern? Replace the template-block, recompose. The schema-block doesn't change. The data-block doesn't change. The process-block doesn't change. Each block is interchangeable because nothing depends on another's internal structure.

Auditability

Every spine row carries spec-source and (when signed) the publisher fingerprint. An auditor querying the spine for “everything signed by Memeroot Founder targeting OWNER_FIN” gets an answer in one query. The audit trail is the spine.

What violation looks like

Mixing kinds creates implicit dependencies. A data-block that embeds a script becomes a hybrid that can't be projected by either the data XSL or the script XSL alone. A schema-block that contains inline data values mixes the “shape of the universe” with “specific points in the universe”; queries that want one and not the other become hard to write. The discipline is the architecture. Loosen the discipline and the architecture isn't there any more.

Section 05The spine · TABLE_SPECIFICATIONS as projector

The row shape

<table-spec spec-source="schema-block | script-block | template-block | ...">
  <source owner="..." name="..." attribute="..." datatype="..."/>      // origin coordinates
  <target owner="..." name="..." prefix="..." attribute="..."
          datatype="..." nullable="N|Y" default="..." id="...">
    <function><![CDATA[ ... ]]></function>                          // the payload (column def, template line, script body, data value)
  </target>
  <index type="pk|fk|uk|idx"/>                                       // optional index marker
  <constraint filter-flag="L|S|i|d|p" condition="" join-condition=""/>
  <view owner="" filter="" prefix=""/>                                // which view this row participates in
  <ext>                                                              // block-kind-specific extensions
    <field name="block-id">...</field>
    <field name="category">...</field>
    <field name="is-loop">...</field>
    <field name="condition-token">...</field>
  </ext>
</table-spec>

The filter flags

What the spine absorbs

Any source that can be projected into the <table-spec> row shape can join the spine. The five block kinds above are the canonical sources; others can be added by writing a projection XSL. Concrete near-term candidates: Oracle ALL_TAB_COLUMNS data dictionary, Informatica metadata exports, Documentum object models, REST API specifications (OpenAPI), graph schema definitions, ontology declarations. Each becomes a projection-block emitting <table-spec> rows. Once they project, they federate.

Section 06Projections · XSL as the universal lens

The five projection stylesheets

The MBI_SCRIPT pattern as direct ancestor

The template-to-spine XSL is the XML analogue of MBI_SCRIPT_AS_TABLE_SPEC_V, the production view that has run in Rob Anderson's enterprise deployments for the past decade. The SQL view emits two row types per template line:

1. A HC (Hard Coded) row that places the template-line text as target_function at address OWNER_MBI.MBI_SCRIPT.SCRIPT_TEXT with the script's category/object-type/script-name/sequence as extension columns
2. A source mapping row that places the MBI_SCRIPT column metadata (the column itself is in the schema) at the same target

In the XML architecture, those become two separate projections: the template-to-spine XSL emits the HC rows; the schema-to-spine XSL emits the source-mapping rows. Strict separation in storage; same address in projection; both visible in the spine. The SQL pattern's UNION ALL becomes the XML pattern's compose-unit.sh — different syntax, identical semantics.

Section 07The self-referencing graph

This is not a curiosity. It is the property that makes the architecture extensible without leaving the architecture. Add a new column to the spine? Write a new schema-block, project it, the spine grows. Add a new view over the spine? Write a projection-block, register it, the spine has a new lens. Add a new block kind entirely? Define its namespace, write its projection XSL, every other block kind keeps working unchanged.

Multiple views at the same address

The same target address — OWNER_MBI.MBI_SCRIPT.SCRIPT_TEXT — appears in the composed spine from three different block kinds:

schema-block view

One row. spec-source="schema-block". The row declares what SCRIPT_TEXT is: column 5 of MBI_SCRIPT, VARCHAR2(4000), NOT NULL. This is the abstract definition.

template-block view

Seven rows. spec-source="template-block". Each row carries one template-line value in <function>, with the template's category/object-type/script-name/sequence in ext. These are specific values that SCRIPT_TEXT holds, projected from the template-block's structured view of those values.

data-block view

Four rows of data-block-sourced cells. spec-source="data-block". Each carries one cell value with <function> as the raw value. The same content as the template-block view, projected from a different block-kind perspective.

The consumer chooses which lens to query through. A code generator looks at the template-block rows (sees the structured template metadata). A data analyst looks at the data-block rows (sees raw cells). A data architect looks at the schema-block row (sees the column definition). All three are valid; all three are present; none overrides another.

Views on views

The spine is itself a view (the UNION ALL of all projections). Additional views can be defined on the spine, in pure XSL, that filter, group, or join spine rows for specific purposes. A “templates-only” view filters for spec-source="template-block". A “control-coverage” view joins schema-block rows to data-block rows by target address. A “dispatch-trace” view filters for spec-source="process-block" and orders by step-seq.

Each derived view is its own projection-block XSL. Views can be views on views. The graph is acyclic in dependency (no projection depends on its own output) but expressive in topology (any DAG of projections is valid).

Section 08Worked example · eight blocks → 77 spine rows

The eight input blocks

The composed spine

A sample query against the composed spine

# “Show me every projection that targets MBI_SCRIPT.SCRIPT_TEXT”
xmllint --xpath "//table-spec[target/@name='MBI_SCRIPT' and target/@attribute='SCRIPT_TEXT']" spine.xml

# Returns 12 rows:
#   - 1 schema-block row defining SCRIPT_TEXT as VARCHAR2(4000) NOT NULL (column #5)
#   - 7 template-block rows (4 from CREATE_TABLE, 3 from GEN_LPV_TRANS_FEAT)
#   - 4 data-block rows (the SCRIPT_TEXT values of the CREATE_TABLE data rows)
#
# All twelve preserved. Consumer chooses spec-source to filter.

Section 09Composition into the unit · the zip

Unit zip structure

memeroot-composable-xml/
├── README.md                              # quickstart
├── ARCHITECTURE.html                      # this document
├── manifest.json                          # list of every block + its hash + signature
│
├── schemas/
│   └── spine.schema.xml                   # the universal projection target
│
├── blocks/
│   ├── schema/
│   │   ├── ts-TABLE_SPECIFICATIONS.schema.xml
│   │   └── ts-MBI_SCRIPT.schema.xml
│   ├── script/
│   │   ├── sc-pmexecutequery.script.xml
│   │   └── sc-exe_var_deletefolder.script.xml
│   ├── template/
│   │   ├── tp-CREATE_TABLE.template.xml
│   │   └── tp-GEN_LPV_TRANS_FEAT.template.xml
│   ├── data/
│   │   └── dt-MBI_SCRIPT-rows-CREATE_TABLE.data.xml
│   └── process/
│       └── pr-bounded-dispatch.process.xml
│
├── projections/                            # pure XSL; no domain content
│   ├── schema-to-spine.xsl
│   ├── script-to-spine.xsl
│   ├── template-to-spine.xsl
│   ├── data-to-spine.xsl
│   ├── process-to-spine.xsl
│   ├── spine-to-html.xsl                   # render unified spine in Memeroot style
│   └── compose-unit.sh                     # orchestrates the projections
│
└── examples/
    ├── spine.xml                           # the composed spine (77 rows)
    └── spine.html                          # human-readable view

Reproducibility

Every consumer of the zip can recompose the spine independently. The inputs are byte-stable. The XSL is byte-stable. xsltproc is deterministic. bash compose-unit.sh emits the same bytes from the same inputs. Verification is a hash comparison: re-run, hash, compare to the publisher's signature.

MMP and set-independent dispatch

Each block in the unit can be projected independently. The unit doesn't need to compose the entire spine to use any one piece. A massively-parallel-processing layer reads the manifest, dispatches per-block projections to independent worker processes, collects the resulting <table-spec> streams, and merges them into the spine — or routes them to whatever execution substrate makes sense for that block kind. Set independence in dispatch follows from the strict separation in storage.

Section 10What was built · file inventory

Spine schema (1)

• schemas/spine.schema.xml — the universal projection target shape with row-form documentation, projection rule, composition rule, strict-separation rule

Blocks (8)

• blocks/schema/ts-TABLE_SPECIFICATIONS.schema.xml — 21 columns of the spine itself
• blocks/schema/ts-MBI_SCRIPT.schema.xml — 9 columns of the template-storage table
• blocks/script/sc-pmexecutequery.script.xml — Rob's 2017 Informatica wrapper, with typed inputs and env-required declarations
• blocks/script/sc-exe_var_deletefolder.script.xml — minimal POSIX delete helper
• blocks/template/tp-CREATE_TABLE.template.xml — 4 template lines with loop, condition tokens, indent levels
• blocks/template/tp-GEN_LPV_TRANS_FEAT.template.xml — translation-view generator from the AFFIRM spec
• blocks/data/dt-MBI_SCRIPT-rows-CREATE_TABLE.data.xml — 4 MBI_SCRIPT rows storing CREATE_TABLE as data
• blocks/process/pr-bounded-dispatch.process.xml — 4-step bounded-execution dispatch pattern referencing schema, template, script, audit blocks by address

Projections (6)

• projections/schema-to-spine.xsl — schema-block → spine rows (one per column)
• projections/script-to-spine.xsl — script-block → spine row for body + one per parameter
• projections/template-to-spine.xsl — template-block → spine row per line, replicating MBI_SCRIPT_AS_TABLE_SPEC_V Row Type 1 semantics
• projections/data-to-spine.xsl — data-block → spine row per cell
• projections/process-to-spine.xsl — process-block → spine row per step invocation
• projections/spine-to-html.xsl — composed spine → Memeroot-styled HTML view with per-kind counts, colour-coded spec-source pills, sortable

Driver (1)

• projections/compose-unit.sh — walks blocks/, routes each file to the right projection by directory, emits <spine> UNION ALL output, generates the HTML view

Reference outputs

• examples/spine.xml — 44 KB, 77 spine rows from the eight input blocks
• examples/spine.html — 63 KB, human-readable Memeroot-styled view of the same data

Section 11Integration with the existing Memeroot stack

How existing region kinds map

What this enables

• Cross-region queries via the spine. “Show me every signed audit packet that contains a captured-hash iframe-region from a publisher whose fingerprint matches X” — one XPath against a composed spine.
• Skill packs become composable from blocks. A new skill pack is: one or more schema-blocks (input shape), one or more template-blocks (output templates), one or more script-blocks (helpers), one process-block (workflow). Authoring a skill is composing blocks, not editing monolithic XML.
• Catalog publishers' federation becomes addressable. Each publisher's signed entries are blocks in their own zip; the catalog curator's manifest is a process-block referencing them by address; the spine projection shows the federation as data.

What does NOT change

None of the existing deliverables in the previous 22-entry catalog need to be reauthored. The composable XML architecture is a refinement of how new content is structured going forward, not a breaking change. Existing region XML continues to parse, sign, verify, render. The new discipline applies to additions.

Section 12Roadmap & open frontiers

Completed in this delivery

• Five block-kind XML conventions with strict separation
• The TABLE_SPECIFICATIONS spine schema
• Six projection XSL stylesheets covering five block kinds + an HTML renderer
• A compose driver that orchestrates the projections via xsltproc
• Eight worked block examples from Rob's real 25-year practice
• A composed reference spine (77 rows) demonstrating self-referencing graph properties
• This documentation

Immediately possible (next deliveries)

• address-block and binding-block — complete the eight-block model. Address blocks declare pure coordinates without payload; binding blocks resolve coordinates to physical sources (Oracle, MinIO, REST, file). Projection XSLs for both. Adds the federation-of-stores layer.
• Cryptographic signing per block. Each block gets a <signature> direct child, signed canonical form via XMLSerializer, fingerprint visible in the spine ext fields. Plumb publisher attribution through to spine row provenance.
• RNG or XSD schemas for each block kind, enforcing strict separation at the validator layer rather than just at the documentation layer.
• Canvas feature for spine rendering. Load a composed spine into MR-CANVAS-v0.8 via a new feature-spine-renderer.xml; clicking any row navigates to the source block. The spine becomes interactive.
• Reverse projection. Project from the spine BACK into a specific block kind. Given a spine query result, emit the equivalent schema-block or data-block. The inverse of the forward projections.

Open frontiers

• Live binding to Oracle 26ai Free instances. A binding-block whose target is an Oracle external table; the projection XSL becomes a SQL query generator that produces a view definition over the external source. The spine becomes a queryable layer over live Oracle data, in line with MEMEROOT-REF-2026-001.
• Multi-database federation. Multiple binding-blocks targeting different databases — Oracle, Postgres, DuckDB, SQLite. The spine federates them via database links and pipelined functions, with no replication.
• Standards proposal. The block-kind taxonomy + spine projection pattern is not Memeroot-specific. It could be the basis of a broader standard for composable structured-content interchange. The substrate just needs naming.
• Substrate-native LLM training. Training corpora composed of typed blocks with strict separation and total provenance. Models trained on this can emit blocks that round-trip the projection; the spine becomes the dataset.