Consolidate ConNeg requirements into the LWS Media Type Section

lws10-core/Operations/read-resource.md

@@ -45,7 +45,7 @@ When the target URI corresponds to a <a>container</a> (determined via metadata t
 ```
 GET /alice/notes/ HTTP/1.1
 Authorization: Bearer <token>
-Accept: application/ld+json
+Accept: application/lws+json
 ```
 Assuming the container exists and the client has access:
 ```

lws10-core/Operations/restbinding.md

@@ -1,3 +1,3 @@
 For each core operation (create, read, update, delete), we describe the HTTP method(s) to use, required headers or special considerations (including concurrency controls via ETags, content negotiation, and pagination for container listings), and what the server should do and return. Standard HTTP status codes are used to indicate outcomes with additional mappings for scenarios such as quota exceeded (507 Insufficient Storage) or precondition failures (412 Precondition Failed). The binding tries to adhere to HTTP/1.1 and relevant RFCs (such as [[!RFC7231]] for HTTP semantics, [[!RFC7233]] for range requests, [[!RFC5789]] for PATCH, [[!RFC8288]] for Web Linking, and [[!RFC9264]] for Link Sets) so that it integrates naturally with web standards. Discoverability is emphasized through mechanisms like Link headers and WWW-Authenticate headers on 401 responses, avoiding hardcoded URI locations. Metadata integration is required across operations, ensuring atomicity and use of Link Sets for server-managed and user-managed properties.
 
-**Note:** As all examples in this specifications, examples given in this section (HTTP request and response snippets) are **non-normative**, meant to illustrate typical usage. The actual requirements are stated in the descriptive text and tables. Also, while this binding covers HTTP (as the initial target protocol), the LWS operations could in principle be bound to other protocols in the future. Servers MUST support content negotiation for `application/lws+json`, `application/ld+json`, and `application/json` for <a>container</a> representations (see [](#lws-media-type)). Servers MAY additionally support formats like Turtle.
+**Note:** As all examples in this specifications, examples given in this section (HTTP request and response snippets) are **non-normative**, meant to illustrate typical usage. The actual requirements are stated in the descriptive text and tables. Also, while this binding covers HTTP (as the initial target protocol), the LWS operations could in principle be bound to other protocols in the future. Media type and content negotiation requirements for <a>container</a> representations are defined in [](#lws-media-type).

lws10-core/logicalresourceorganization.md

@@ -4,8 +4,7 @@ Linked Web Storage organizes resources into <a>containers</a>. A <a>container</a
 as organizational units, analogous to directories or collections, enabling clients to group, discover, and navigate resources. A container maintains references to its member resources,
 which may comprise both non-container resources and additional container resources, thereby enabling hierarchical formations. Typically, a container holds minimal intrinsic content
 beyond metadata or enumerations of its members; its principal role is to aggregate and structure subordinate resources. The <a>storage</a> system's root is designated as a <a>container</a>, serving
-as the apex organizational unit devoid of a superior parent. Containers MUST support pagination for membership listings using 'ContainerPage' types, with properties such as 'first',
-'next', 'prev', and 'last'. Representations MUST use JSON-LD with a specific frame and normative context, optionally advertising content negotiation via 'Vary: Accept' headers.
+as the apex organizational unit devoid of a superior parent. The structure of <a>container representations</a> is defined in [](#container-representation); their media type, content negotiation, and pagination requirements are defined in [](#lws-media-type).
 Storage MAY function as a root container, enabling direct writes.
 
 Every LWS <a>storage</a> has a **<a>storage root</a>** that serves as the top-level organizational unit. The <a>storage root</a> has no parent and acts as the entry point for the <a>storage</a> hierarchy.

lws10-core/lws-media-type.md

@@ -12,7 +12,9 @@ Servers MUST support content negotiation for container representations. The resp
 - If a client requests `application/ld+json`, the server MUST respond with `Content-Type: application/ld+json`.
 - If a client requests `application/json`, the server MUST respond with `Content-Type: application/json`.
 
-In all three cases, the response body is the same JSON-LD document conforming to the LWS container vocabulary. Servers are free to support additional media types (e.g., `text/turtle`) through content negotiation.
+In all three cases, the response body is the same JSON-LD document conforming to the <a>container representation</a> structure defined in [](#container-representation). Servers MAY support additional media types through content negotiation.
+
+Because the `Content-Type` of these responses varies with the request's `Accept` header, responses subject to content negotiation SHOULD include a `Vary: Accept` header [[!RFC9110]].
 
 
 #### Pagination