docs: refine operation interfaces and batching

2.1-object-tree-schema.md

@@ -20,16 +20,24 @@ ObjectがTree上に配置されることでエントリとなり、pathはその
 
 ## 2.1.3 公開情報
 
-Object / エントリが公開する情報は、Worldspaceを探索し、対象に対して何ができるかを理解するための**interface metadata**である。
+Object / エントリが公開する情報は、Worldspaceを探索し、対象に対して何ができるかを理解するための最小限のmetadataである。
 
 現時点では、少なくとも次の情報を想定する。
 
 - `name` — Objectの短い名前。Tree上ではエントリ名としても用いられる。
 - `description` — Objectが何を表すかを説明する短い自然言語。長文documentationではなく、探索・判断に必要な最小限のsemantic metadataとする。
-- `operations` — Objectが公開するOperation。詳細は [2.2. Operation](2.2-operation.md) で定義する。
+- `interface` — Objectが実装するInterfaceへの参照。
 - `children` — Tree上でindexableとして公開される子Object / エントリ。
 - `ref` — 必要に応じて公開される、同一Objectを再参照するための外部Handle。
 
+Interfaceの実体は[WIP IDL](draft/wip-idl.md) documentである。IDL内に宣言された関数の集合が、そのInterfaceのOperation集合となる。ObjectはOperation定義を個別に埋め込まず、一つのInterface参照だけを持つ。
+
+複数のObjectが同じInterfaceを参照できる。これにより、Collectionから多数の同種エントリを取得する場合でも、Operation名、documentation、parameter、return typeを各エントリへ重複して送る必要がない。
+
+Interface参照は、HostがそのClientへ投影したInterfaceを識別する。同じObjectでも主体のroleや権限により異なるInterfaceを参照し得るが、頻繁に変化する実行可否を表すためには使用しない。
+
+ClientはInterface参照をcacheと比較し、未知のInterfaceだけを`fetch_interface`で取得する。HostはClientのcache状態を推測せず、ObjectのresponseへInterface定義を先行同梱しない。複数のInterface取得はTransport Bindingでbatchできる。
+
 WIPではドメインデータそのものをpropertiesとして直接公開することを前提としない。本文、metadata、状態などを読む行為もOperationとして表現する。
 
 ## 2.1.4 Tree