Zwei zusammenwirkende Grundlagen
REZICS modelliert getrennt, „was der Inhalt ist“ und „wo der Inhalt erscheint“.
- Block Schema legt fest, aus welchen typisierten Blöcken ein renderbares Dokument besteht und wie jeder Block stabile Identität, Version und Validierungsregeln bewahrt.
- Inhaltsstruktur legt Auftretensorte von Inhaltseinheiten, Eltern-Kind-Beziehungen, Reihenfolge, Ziele und veröffentlichte Revisionen fest.
Durch diese Trennung kann dasselbe Kapitel oder derselbe Beitrag an mehreren Stellen wiederverwendet werden, ohne den Volltext zu kopieren. Jedes Auftreten kann dennoch eine eigene Knoten-ID, Reihenfolge und Navigationssemantik besitzen.
Block Schema: kein rohes JSON
Fast jedes speicherbare JSON-Dokument benötigt zunächst ein erkennbares Grundobjekt, statt ein beliebiges Portable-Text-Array direkt in ein Feld zu legen. Das elementarste Portable-Text-Dokument hat diese Semantik:
{
_type: "portable-text",
_key: "Schlüssel aus 6 Byte bzw. 12 Hexadezimalzeichen",
content: PortableText,
}_type bestimmt das Parsing- und Renderingprotokoll; _key lässt Blöcke ihre Identität über Revisionen, Absatzkommentare und Strukturvorgänge hinweg behalten; die Dokumentversion setzt bei jeder Entwicklung der Strukturspezifikation eine explizite Migrationsgrenze. Auf die Formatvalidierung müssen weiterhin Validierungen von Referenzen, Berechtigungen und Sichtbarkeit folgen; allein das Format einer Kennung beweist nicht, dass ihr Ziel gelesen werden darf.
Umgesetzte Blockfamilien
Das gemeinsame Block Schema kann derzeit Portable Text, Einheitsreferenzen, vollständige Beitragsdarstellung, Einheitslisten, suchgesteuerte Inhaltsdynamik, Menüs und andere kontrollierte Inhaltsoberflächen ausdrücken. Jede Variante ist Teil einer geschlossenen Vereinigung; unbekannte Blöcke dürfen nicht stillschweigend durch den Renderer gelangen.
Community-Bereiche, Ablagebereiche, Wiki-Navigation und künftig wiederverwendbare Dokumente beruhen auf derselben Grundlage. Ob ein Blockdokument zu einer eigenständigen Einheit wird, muss durch echte Anforderungen wie Wiederverwendung über mehrere Besitzende hinweg, eigenständige Autorenschaft, Veröffentlichungsgeschichte oder Sichtbarkeit begründet sein.
Was die Inhaltsstruktur bereits kann
- Typisierte Strukturen für Bücher, Medien, Beiträge, Klassifikationsstrukturen in Themenräumen und Navigation erstellen.
- Große geordnete Bäume mit stabilen Knoten-IDs, Elternknoten und fraktionalen Positionswerten speichern.
- Knoten auf wiederverwendbare Inhaltseinheiten verweisen lassen und zwischen Inhalt, Einheitsziel und externer URL unterscheiden.
- Buch- und Medienstrukturen als vollständigen Entwurf bearbeiten und begrenzte Änderungen anschließend zu atomaren Anfragen kompilieren.
- Revisionen speichern, Unterschiede vergleichen und einen früheren Zustand über eine neue Revision wiederherstellen.
- Den Lesenden die Struktur als Inhaltsverzeichnis, vorheriges und nächstes Kapitel sowie Position des Lesefortschritts projizieren lassen.
Große Serien und Importe
Eine einzelne Strukturänderung kompiliert höchstens 10.000 logische Befehle. Das Limit betrifft eine atomare Änderung, nicht die Gesamtzahl der Knoten eines ganzen Buches. Große Webromane können den vollständigen Baum in mehrere wiederherstellbare Schreibvorgänge aufteilen: Jeder Vorgang übermittelt bereits festgeschriebene Knoten und eine begrenzte Gruppe neuer Knoten; nach Erfolg erhält er das Revisionstoken für den nächsten Vorgang.
Werke mit mehr als 10.000 Kapiteln müssen daher weder in eine unbegrenzte Transaktion geladen werden noch auf Konflikterkennung verzichten. Ein Import kann unterbrochen und später fortgesetzt werden; zum Schluss lässt sich der vollständige Snapshot validieren.
In Entwicklung und Planung
Weitere Blockvarianten, Blockeinheiten mit mehreren Besitzenden, starke Referenzindizes, Absatzkommentare, vollständige Arbeitsabläufe für große Importe und GameContentStructure befinden sich jeweils in Entwicklung oder Planung. Jeder neue Block muss Zustände für Speichern, Veröffentlichen, Lesen, Löschen, Cache und Fehler definieren.
Beziehungen und Grenzen
Block Schema ist kein Editor, und die Inhaltsstruktur ist nicht der Volltext. Der Editor erzeugt validierte Dokumente, Beiträge und Kapitel besitzen den Inhalt, die Inhaltsstruktur ordnet ihre Auftretensorte an, und die Geschichte bewahrt veröffentlichte Revisionen.