docs: define operation IDL and entry discovery

2.1-object-tree-schema.md

@@ -38,9 +38,9 @@ Worldspaceは、Objectが親子関係によって配置されたTreeとして観
 
 Tree上のObjectをエントリとして呼び、その位置をpathで表す。
 
-子エントリは所有・内包関係を表す。非内包の意味的関係はLinkとして扱う。
+子エントリは所有・内包関係を表す。非内包の意味的関係は、それを表すOperationから関連エントリのpathを返す。
 
-例えばRepository配下の`issues`は子エントリとして自然だが、Issueから関連Pull Requestへの参照はLinkとして表現する。
+例えばRepository配下の`issues`は子エントリとして自然だが、Issueから関連Pull Requestを得る場合は`get_related_pull_requests`のようなOperationで表現する。
 
 Treeはmaterializedな全世界ではなく、HostがそのClientに対して公開する**lazy / virtual tree**である。Hostは全Objectを事前保持する必要はなく、`fetch`や`fetch_tree`に応じて動的に解決してよい。
 
@@ -54,15 +54,9 @@ indexableな子エントリは、Worldspaceの構造理解に必要で、通常
 
 一方、大量のIssue、検索結果、一時的なObject群などはindexable childとして露出しない。必要なエントリはCollection Objectの`query` / `list`等のOperation結果として返す。
 
-## 2.1.6 Link
+Operation結果として返されることは、実行対象との親子関係を意味しない。Collectionの要素を返す場合だけでなく、親、兄弟、関連Objectなど、Worldspace内の別の位置にあるエントリを発見するためにもOperationを利用できる。
 
-LinkはTree上の所有・内包ではない意味的関係を表す。
-
-Linkによって未知のエントリが発見された場合、ClientはそのエントリをKnown Spaceへ追加できる。ただし、それだけではDiscoverable Spaceには追加しない。
-
-そのエントリを起点に`fetch_tree`を行い、indexableなTreeを取得した場合にのみ、その範囲をdiscover対象として扱える。
-
-## 2.1.7 Core Protocolとの対応
+## 2.1.6 Core Protocolとの対応
 
 `fetch(entry)`は、指定されたTree上の位置にあるObjectの公開情報を取得する。
 
@@ -70,4 +64,4 @@ Linkによって未知のエントリが発見された場合、Clientはその
 
 探索が`depth`または`limit`により打ち切られた場合は、レスポンスで`truncated`を必ず明示する。
 
-Operationを実行した結果として、新しいエントリ、エントリツリー、Linkが返る場合がある。Clientはそれらを構造化された発見結果としてKnown Spaceへ統合する。
+Operationを実行した結果には、WIP IDLの`entry`型として新しいエントリのpathが含まれる場合がある。Clientはそれらを一時的な発見結果として扱い、後続の参照に必要なものだけを取得してKnown Spaceへ統合できる。