Block Schema とコンテンツ構造

連携する二つの基盤

REZICS は「コンテンツが何であるか」と「コンテンツがどこに現れるか」を別々にモデル化します。

Block Schema は、レンダリング可能な文書がどの型付きブロックで構成され、各ブロックが安定したアイデンティティ、バージョン、検証規則をどう保つかを定義します。
コンテンツ構造 は、コンテンツユニットの出現位置、親子関係、順序、行き先、公開済み改訂を定義します。

この分離により、同じ章／投稿を複数の位置で本文の複製なしに再利用でき、それぞれの出現には独自のノード ID、順序、ナビゲーション上の意味を持たせられます。

Block Schema：素の JSON ではない

保存可能な JSON 文書のほとんどには、任意の Portable Text 配列をそのままフィールドへ入れるのではなく、まず識別できる基礎オブジェクトが必要です。最も基本的な Portable Text 文書は、次の意味を持ちます。

{
  _type: "portable-text",
  _key: "6 バイト／12 桁の 16 進数キー",
  content: PortableText,
}

_type は解析とレンダリングのプロトコルを決めます。_key により、ブロックは改訂、段落コメント、構造操作をまたいでアイデンティティを保ちます。文書バージョンは、構造仕様が進化するたびに明示的な移行境界を提供します。形式の検証後も、参照、権限、公開範囲を検証しなければなりません。識別子の形式だけでは、対象を読めることの証明にはなりません。

実装済みのブロックファミリー

現在、共通の Block Schema で Portable Text、ユニット参照、完全な投稿表示、ユニット一覧、検索駆動のコンテンツフィード、メニュー、その他の制御されたコンテンツ画面を表現できます。各バリアントは閉じたユニオンの一部であり、未知のブロックがレンダラーを黙って通過することは許されません。

ゾーン、配置枠、ウィキのナビゲーション、将来の再利用可能な文書は、すべてこの共通基盤の上にあります。ブロック文書を独立したユニットへ昇格させるかどうかは、所有者をまたぐ再利用、独立した作者、公開履歴、公開範囲といった実際の必要性によって裏付けられなければなりません。

コンテンツ構造で現在できること

書籍、メディア、投稿、領域の分類構造、ナビゲーションのために型付き構造を作成する。
安定したノード ID、親ノード、フラクショナルインデックスによる位置で、大規模な順序付きツリーを保存する。
ノードから再利用可能なコンテンツユニットを参照し、コンテンツ、ユニットへの行き先、外部 URL を区別する。
完全な下書きで書籍／メディア構造を編集し、上限のある変更を原子的リクエストへコンパイルする。
改訂を保存し、差分を比較し、新しい改訂を通じて古い状態を復元する。
リーダーが構造を目次、前の章／次の章、読書進捗の位置として投影できるようにする。

大規模連載とインポート

1 回の構造変更でコンパイルできる論理コマンドは最大 10,000 件です。この制限は一つの原子的変更に対するものであり、書籍全体の総ノード数に対するものではありません。大規模なウェブ小説では、完全なツリーを複数の復旧可能な書き込みに分けられます。各回でコミット済みノードと上限のある新規ノード群を持ち込み、成功後に次回必要な改訂トークンを取得します。

したがって、10,000 章を超える作品でも無制限のトランザクションを読み込む必要はなく、競合検出を犠牲にする必要もありません。インポートは中断後に再開でき、最後に完全なスナップショットを検証できます。

開発中と計画中

さらに多くのブロックバリアント、所有者をまたぐブロックユニット、強い参照のインデックス、段落単位のコメント、完全な大規模インポートフロー、GameContentStructure は、それぞれ開発中または計画中です。新しいブロックの種類ごとに、保存、公開、読み取り、削除、キャッシュ、失敗の状態を定義しなければなりません。

関係と境界

Block Schema はエディターではなく、コンテンツ構造も本文ではありません。エディターは検証済みの文書を生成し、投稿／章がコンテンツを所有し、コンテンツ構造がその出現位置を配置し、履歴が公開済みの改訂を保存します。