docs: remove retrieval batch binding

2-core-model.md

@@ -68,7 +68,7 @@ Clientは、次の3操作によってWorldspaceを観測および操作する。
 
 この節は各操作の意味だけを定める。Parameterとreturn valueの具体的なstructはProtocolで定義する。
 
-複数の`observe`や`fetch_interface`は、それぞれ独立したCore interactionである。Transport Bindingは、個別に実行した場合と同じ意味を保ったまま複数のinteractionを一つのrequestへbatchしてよい。Batchingによって新しいCore interaction、subrequest間のdata dependency、または暗黙の先読みを導入しない。
+複数の`observe`や`fetch_interface`は、それぞれ独立したCore interactionである。Clientは必要なinteractionを個別に並行実行でき、Transport実装は複数のexchangeを一つのconnection上でmultiplexできる。並行実行やmultiplexingによって新しいCore interaction、request間のdata dependency、共通snapshot、または暗黙の先読みを導入しない。
 
 ## `ref`
 
@@ -132,6 +132,6 @@ Clientが保持するKnown SpaceとDiscoverable Spaceは、過去の観測から
 
 Core ModelとProtocol structは、HTTP、TCP、WebSocket等の特定transportを要求しない。
 
-通信方式、concrete encoding、endpoint、batch packagingへの対応付けはTransport Bindingとして定義する。共通要件は[5. Transport Bindings](5-transports.md)、標準bindingは[5.1. WIP over HTTP](5.1-wip-over-http.md)で扱う。
+通信方式、concrete encoding、endpointへの対応付けはTransport Bindingとして定義する。共通要件は[5. Transport Bindings](5-transports.md)、標準bindingは[5.1. WIP over HTTP](5.1-wip-over-http.md)で扱う。
 
 この分離により、Worldspaceの意味論、Client / Host間のlogical contract、通信方式を独立して進化させる。

2.1-object-tree-schema.md

@@ -181,10 +181,8 @@ Tree上のchildrenとして自然に列挙できるのは、**indexableなObject
 IssueQueryResult.items: [entry]
 ```
 
-## Batch
+## 複数の取得
 
-複数のObjectやInterface Descriptorをまとめて取得する機能は、Core Model上の新しいinteractionではない。
+複数のObjectやInterface Descriptorが必要な場合も、各`observe`と`fetch_interface`は独立したCore interactionである。Clientは必要なrequestを個別に並行実行でき、Transport実装はconnection reuseやmultiplexingを利用できる。
 
-Transport Bindingは、個別に実行した場合と同じ意味を保つ形で、複数の`observe`と`fetch_interface`を一つのrequestへまとめてよい。
+WIPは複数のinteractionを包む共通request envelope、自動的な全量取得、暗黙の再帰展開、Clientが要求していない先読みを定義しない。
-
-WIPは自動的な全量取得、暗黙の再帰展開、Clientが要求していない先読みを要求しない。

2.2-operation.md

@@ -70,7 +70,7 @@ ObjectはInterface参照のordered setだけを持ち、Descriptorを先行同
 
 同じInterface参照とvalidatorの組は同じDescriptorを表す。Validatorを返さないInterface参照は、その参照の有効期間中immutableでなければならない。
 
-HostはClientのcache状態を推測して、要求されていないDescriptorをObject responseへ追加しない。複数のDescriptor取得はTransport Bindingでbatchできる。
+HostはClientのcache状態を推測して、要求されていないDescriptorをObject responseへ追加しない。複数のDescriptorが必要なClientは、それぞれの`fetch_interface`を個別に並行実行できる。
 
 ## Operationの可視性
 

3-protocol.md

@@ -4,7 +4,7 @@ WIP Protocolは、ClientとHostの間で交換するlogical data modelと、Core
 
 この章のstructはRust風の記法を使用するが、Rust固有のmemory layoutやserialization libraryを要求しない。TypeScriptを含む他言語でも同じ型、必須性、validation semanticsを実装できなければならない。
 
-HTTP endpoint、JSON fieldへのencoding、status code、batch packagingはTransport Bindingの責務とし、共通要件を[5. Transport Bindings](5-transports.md)、標準bindingを[5.1. WIP over HTTP](5.1-wip-over-http.md)で扱う。
+HTTP endpoint、JSON fieldへのencoding、status codeはTransport Bindingの責務とし、共通要件を[5. Transport Bindings](5-transports.md)、標準bindingを[5.1. WIP over HTTP](5.1-wip-over-http.md)で扱う。
 
 ## Protocol dataの分類
 
@@ -416,7 +416,7 @@ type ObserveResponse = ObjectObservation;
 
 Success responseはrequested depthまで完全である。Node数によるpartial success、`limit`、`truncated`は定義しない。Hostが完全なresponseをresource budget内で構築できない場合は`ResourceLimitExceeded`を返す。
 
-各nodeのObjectがvalidatorを持つ場合、Clientはrequest pathとchildrenの`name`から導出したpathに対応付けてcacheし、条件付きOperationの`target`を構築できる。Batch Transport Bindingも各itemのrequestとresponseを一意に対応付けなければならない。
+各nodeのObjectがvalidatorを持つ場合、Clientはrequest pathとchildrenの`name`から導出したpathに対応付けてcacheし、条件付きOperationの`target`を構築できる。
 
 ## `fetch_interface`
 
@@ -637,14 +637,6 @@ HostとClientは、untrusted inputによるresource exhaustionを避けるため
 
 `call_operation`では、dispatch後にresultのlogical size、validation、backend budget等の問題を検出しても、effectがcommitされていないと保証できる場合だけ`ResourceLimitExceeded`または`Internal`を返す。未実行またはrollbackを保証できない場合は`OperationOutcomeUnknown`とする。Transport implementationまたはdeploymentのmessage-size上限、response不達等はProtocol failureへ変換せず、Transport failureとして扱う。
 
-## Batch
-
-BatchはCore interactionではなくTransport Bindingのoptimizationである。
-
-Transport Bindingは、複数の`ObserveRequest`と`FetchInterfaceRequest`を一つのphysical requestへまとめてよい。それぞれのlogical requestは独立して成功または失敗し、個別に実行した場合と同じ意味を持たなければならない。Subrequest間で先行resultを後続requestのfieldとして参照してはならない。
-
-`call_operation`はOperation executionのordering、partial completion、replayを定義する新しいinteractionになるため、Coreの標準batch対象にしない。OperationをObject stateへのeffectで分類してbatch対象を推測しない。
-
 ## Transport Bindingの要件
 
 Transport Bindingは、この章のlogical structについて次を定義する。
@@ -655,8 +647,7 @@ Transport Bindingは、この章のlogical structについて次を定義する
 - Optional fieldの省略。
 - Protocol failureのmapping。
 - Object validator、Interface validator、Operation preconditionのmapping。
-- Batch packagingを提供する場合はitemの対応付けと部分的failure。
 
-Transport固有のmessage size、timeout、concurrency、security、connection policyはTransport実装とdeploymentの責務であり、BindingがWIP Protocolとして値またはnegotiationを定義する必要はない。
+Transport固有のmessage size、timeout、concurrency、security、connection policyはTransport実装とdeploymentの責務であり、BindingがWIP Protocolとして値またはnegotiationを定義する必要はない。複数のinteractionを並行実行またはmultiplexする場合も、それぞれは独立したrequestとresponseを持つ。
 
 Transport Bindingは、logical typeの区別またはvalidation semanticsを失ってはならない。

4-client.md

@@ -51,7 +51,7 @@ Clientはvalidatorが存在する観測を`(interface, validator)`の組で識
 
 一つのInterface Descriptorに宣言されたOperationの集合が、そのInterfaceのOperation一覧である。Objectは複数のInterfaceを組み合わせられ、複数のObjectも同じInterfaceを共有できる。
 
-ClientはDescriptorが必要なInterface参照とcacheを比較し、未知のInterfaceだけを取得する。Objectの`interfaces`からDescriptor interestを先行して導出しても、Operationを選択した時点で必要な参照だけを取得してもよい。Interface validator mismatch等で更新が必要になった参照は再取得する。複数の`fetch_interface`は、Transport Bindingが提供するbatchを利用してまとめてよい。
+ClientはDescriptorが必要なInterface参照とcacheを比較し、未知のInterfaceだけを取得する。Objectの`interfaces`からDescriptor interestを先行して導出しても、Operationを選択した時点で必要な参照だけを取得してもよい。Interface validator mismatch等で更新が必要になった参照は再取得する。複数の`fetch_interface`が必要な場合、それぞれを個別のrequestとして並行実行できる。
 
 異なるInterfaceで同じOperation名が存在しても、ClientはInterface参照とOperation名の組で識別する。UIやAI Toolでは必要に応じて`<interface-reference>.<operation-name>`と表示する。Operation callでは表示文字列をparseせず、Interface参照とOperation名を別fieldとして送る。
 
@@ -69,7 +69,7 @@ Operationを通して発見されたpathは、それだけではDiscoverable Spa
 
 ## 一時的な発見とpin
 
-Clientは、Operation Resultの`entry`型として発見したpathを現在の結果として一時的に扱える。標準的なClientはOperationのreturn typeからentry pathを抽出して重複を除去し、Known Spaceと比較して必要なpathだけを`depth = 0`で観測する。複数の`observe`はTransport Bindingが提供するbatchを利用してまとめてよい。
+Clientは、Operation Resultの`entry`型として発見したpathを現在の結果として一時的に扱える。標準的なClientはOperationのreturn typeからentry pathを抽出して重複を除去し、Known Spaceと比較して必要なpathだけを`depth = 0`で観測する。複数の`observe`が必要な場合、それぞれを個別のrequestとして並行実行できる。
 
 一時的に取得したエントリは、結果の利用が終わった時点で破棄してよい。
 
@@ -93,7 +93,7 @@ Clientはinterestを、現在有効なObject observation、children coverage、I
 
 Clientは、interestを満たすためのidempotentな調整と、既存の観測を置き換える明示的な再観測を区別できる。明示的な再観測は、現在有効な観測または同じ対象の進行中requestがあっても新しいrequestを発行し、それ以前のrequestをsupersedeしてよい。
 
-Clientは、保持する観測、進行中request、並列度、request rateへboundedな上限を設ける。上限によって新しい取得を開始できない場合、interest自体をProtocol failureとして扱わず、別のrequestの完了、容量の解放、またはinterestの変更後に再評価できる。具体的な優先順位、batching、prefetch範囲、fairness、cache容量、eviction algorithmはClient実装に委ねる。
+Clientは、保持する観測、進行中request、並列度、request rateへboundedな上限を設ける。上限によって新しい取得を開始できない場合、interest自体をProtocol failureとして扱わず、別のrequestの完了、容量の解放、またはinterestの変更後に再評価できる。具体的な優先順位、並行実行、prefetch範囲、fairness、cache容量、eviction algorithmはClient実装に委ねる。
 
 Clientは、上位層から直接示されたinterestに加えて、観測したObjectのInterface参照やindexable child edgeから次のinterestを先行して導出してよい。WIPは全量取得、暗黙の再帰展開、または特定のprefetch範囲を要求しない。取得計画とevictionは、interestの変更や明示的な再観測がないまま同じ観測を繰り返し破棄して再取得する、自己維持的なloopを作ってはならない。
 

5-transports.md

@@ -15,7 +15,6 @@ Transport Bindingは、少なくとも次を定義する。
 - SuccessとProtocol failureのwire representation。
 - Transport failureとProtocol failureの区別。
 - ValidatorおよびOperation preconditionのmapping。
-- Batchを提供する場合のitem correlation、独立性、部分的failure。
 
 BindingはProtocolのlogical type、validation、error、visibility、Operation executionの意味を変更してはならない。Binding固有のstatus、header、stream event等を根拠として、新しいProtocol failureまたは回復actionを暗黙に追加してはならない。
 
@@ -23,7 +22,7 @@ BindingはProtocolのlogical type、validation、error、visibility、Operation
 
 一つのCore interactionは、一つ以上のphysical messageを使用して実装できる。ただし、ClientとHostは各successまたはProtocol failureを、元のlogical requestおよびそのeffective Worldspace viewへ一意に対応付けられなければならない。
 
-Transport Bindingは複数の取得interactionを一つのphysical requestへbatchしてよい。その場合も各logical interactionは、個別に実行した場合と同じrequest、response、failure semanticsを持つ。Batchは新しいCore interaction、transaction、共通snapshot、subrequest間のdata dependencyを導入しない。
+複数のCore interactionは、それぞれ独立したrequestとresponseを持つ。Clientはそれらを並行実行でき、Transport実装は複数のexchangeを一つのconnection上でmultiplexできる。WIPは複数のinteractionを包む共通request / response envelope、transaction、共通snapshot、request間のdata dependencyを定義しない。
 
 ## Effective Worldspace view
 

5.1-wip-over-http.md

@@ -10,9 +10,7 @@ WIP over HTTPは、[3. Protocol](3-protocol.md)のlogical data modelをHTTP requ
 - `fetch_interface`
 - `call_operation`
 
-さらに、独立した複数の`observe`と`fetch_interface`を一つのHTTP exchangeへまとめるretrieval batchを定義する。
+HTTP version、communication scheme、TLS、authentication方式、connection reuse、multiplexing、proxy、gateway、cache、Host内部のframework、backend接続方式は規定しない。HTTP実装とdeploymentは、それらをWIPとは独立して選択する。複数のCore interactionが必要な場合も、それぞれを独立したHTTP request / responseとして交換する。
-
-HTTP version、communication scheme、TLS、authentication方式、connection reuse、multiplexing、proxy、gateway、cache、Host内部のframework、backend接続方式は規定しない。HTTP実装とdeploymentは、それらをWIPとは独立して選択する。
 
 OperationがWebSocket等のendpointをApplication dataとして返すことは妨げない。そのendpoint上のprotocol、状態、lifecycleはWIPの規定対象外である。
 
@@ -36,7 +34,6 @@ Endpoint URLは次を満たす。
 | `observe` | `POST` | `v1/observe` |
 | `fetch_interface` | `POST` | `v1/fetch_interface` |
 | `call_operation` | `POST` | `v1/call_operation` |
-| retrieval batch | `POST` | `v1/batch` |
 
 `v1`はWIP over HTTP Bindingのmajor versionである。Interactionごとに独立したrouteを設定したり、固定suffixを別名へ置き換えたりしない。
 
@@ -93,7 +90,7 @@ HTTP server、proxy、gateway、またはClientの運用設定によってmessag
 
 ## HTTP response
 
-単独interactionが成功した場合、Hostは`200 OK`を返し、response bodyへ対応するProtocol responseを直接encodeする。Success bodyを`result`等の共通envelopeで包まない。
+各interactionが成功した場合、Hostは`200 OK`を返し、response bodyへ対応するProtocol responseを直接encodeする。Success bodyを`result`等の共通envelopeで包まない。
 
 Protocol failureの場合、Hostは非2xx statusを返し、bodyへ本章のProtocol error envelopeをencodeする。
 
@@ -573,13 +570,11 @@ Object validatorとInterface validatorは対応するJSON body fieldへcanonical
 - `InterfaceTarget.validator`
 - `CallOperationResponse.validator`
 
-単独request / responseとbatch itemは同じ表現を使用する。
-
 WIP validatorを`ETag`、`If-Match`、その他のHTTP headerだけへ移してbody fieldを省略してはならない。Host、gateway、HTTP cacheは通常のHTTP representation metadataとして`ETag`等を追加してよいが、その値はWIP validatorと独立している。ClientはHTTP metadataをObject identity、Interface observation、Operation preconditionとして解釈しない。
 
 ## Protocol error envelope
 
-単独interactionのProtocol failureとbatch全体のProtocol failureは、次のexactなJSON objectとしてencodeする。
+各interactionのProtocol failureは、次のexactなJSON objectとしてencodeする。
 
 ```json
 {
@@ -656,113 +651,6 @@ RequestがHostへ送信されていないとTransport実装が証明できるfai
 
 HTTP implementationとdeploymentは、失敗した`POST v1/call_operation`を透過的にreplayしない。
 
-## Retrieval batch
-
-Retrieval batchは、複数の独立した`observe`と`fetch_interface`を一つのHTTP requestへまとめるpackagingである。新しいCore interaction、transaction、共通snapshot、実行順序を導入しない。
-
-### Request envelope
-
-`POST v1/batch`のbodyは次のexactなJSON objectである。
-
-```json
-{
-  "requests": [
-    {
-      "id": "entry-123",
-      "method": "observe",
-      "arguments": {
-        "path": "/items/123",
-        "depth": 0
-      }
-    },
-    {
-      "id": "item-interface",
-      "method": "fetch_interface",
-      "arguments": {
-        "interface": "item-interface-v1"
-      }
-    }
-  ]
-}
-```
-
-Top-level objectはrequiredな`requests` arrayだけを持つ。各itemは次のfieldだけを持つ。
-
-| Field | JSON type | Presence |
-| --- | --- | --- |
-| `id` | string | required |
-| `method` | `observe`または`fetch_interface` | required |
-| `arguments` | 対応interactionのrequest object | required |
-
-`id`は一つのbatch request内で一意であり、そのphysical exchange内のcorrelationにだけ使用する。永続的identity、ordering key、idempotency key、WIP validatorとして解釈しない。空の`requests` arrayはvalidであり、Hostは空の`responses` arrayを返す。
-
-`call_operation`はこのretrieval batchへ含めない。`v1/batch`のmethod集合は`observe`と`fetch_interface`だけであり、Operation executionを分類または推測して拡張しない。
-
-### Request validation
-
-次はbatch全体の`invalid_request`である。
-
-- Top-level envelopeを解釈できない。
-- `requests`がない、arrayでない、または未知top-level fieldがある。
-- Itemに`id`、`method`、`arguments`がない、または未知item fieldがある。
-- `id`がstringでない、または重複する。
-- `method`が未知である。
-
-既知の`method`を持つitemの`arguments`が、そのlogical requestとして不正な場合はbatch全体を拒否しない。その`id`のsubresponseへ`invalid_request`を返す。他itemは独立して処理する。
-
-Batch requestを交換可能な件数やsizeはHTTP implementationとdeploymentの運用事項であり、本bindingは規定しない。それらの都合でbatch requestを交換できない場合はTransport failureであり、`resource_limit_exceeded`へ変換しない。各valid subrequestについてProtocol上のlogical limitを超えた場合は、そのitemへ`resource_limit_exceeded`を返せる。
-
-### Response envelope
-
-Validなbatch envelopeへは、一部または全部のitemがProtocol failureでも`200 OK`を返す。
-
-```json
-{
-  "responses": [
-    {
-      "id": "entry-123",
-      "result": {
-        "object": {
-          "name": "123",
-          "interfaces": ["item-interface-v1"]
-        }
-      }
-    },
-    {
-      "id": "item-interface",
-      "error": {
-        "code": "interface_not_found",
-        "message": "Interface is not currently published"
-      }
-    }
-  ]
-}
-```
-
-Top-level objectはrequiredな`responses` arrayだけを持つ。各subresponseはstring `id`と、`result`または`error`のちょうど一方を持つ。その他のmemberを持たない。
-
-- `result`は対応するinteractionを単独で呼んだ場合のsuccess bodyと同じJSON valueである。
-- `error`はenvelopeで包まない直接の`{"code": ..., "message": ...}` objectである。
-- ItemごとのHTTP statusを含めない。
-- Item error codeは対応interactionで許可されたものに限る。
-
-Response array順に意味を持たせず、`id`でcorrelateする。Hostはrequestに含まれた各`id`についてちょうど一つのsubresponseを返す。Response IDは重複せず、要求されていないIDを追加せず、要求されたIDを欠落させない。Clientはexact correlationに違反するresponse全体を`InvalidResponse`として拒否する。
-
-Hostはsubrequestを直列または並列に実行してよい。各subrequestは個別に実行した場合と同じ意味を持つ。Batchはatomicではなく、共通snapshot、実行順序、read-your-previous-resultを保証しない。先行resultを後続argumentsから参照する構文はない。
-
-### Top-level batch failure
-
-Batch envelopeをitem列として解釈できない場合、またはitem処理を開始する前後にbatch response全体を構築できないHost failureが起きた場合は、通常のtop-level Protocol error envelopeを返す。
-
-Top-level batch failureで許可するcodeは次だけである。
-
-| Code | Status |
-| --- | --- |
-| `invalid_request` | `400 Bad Request` |
-| `internal` | `500 Internal Server Error` |
-
-Batchは取得interactionだけを含むため、physical exchangeが失敗した場合、Clientは必要なitemをboundedなpolicyで再取得できる。どのitemがHostで完了したかを推測してKnown Spaceへ反映しない。
-
 ## HTTP facilitiesとの境界
 
 HTTP cache、proxy、gateway、compression、connection管理、TLS、message size、timeout、concurrency、rate limit等の設定と運用は、本bindingの規定対象外である。
@@ -782,5 +670,5 @@ HTTP implementationまたはdeploymentの都合でrequestまたはresponseを交
 - Operation idempotency keyまたはexactly-once execution。
 - Operation cancellation protocol。
 - Streaming、subscription、server push、WebSocket binding。
-- `call_operation`のbatching。
+- 複数のCore interactionを一つのWIP requestへまとめる共通envelope。
 - Domain failureの共通HTTP mapping。