remove non-normative text

Author: ebremer

lws10-core/logicalresourceorganization.md

@@ -1,18 +1,18 @@
 ### Logical Resource Organization
 
-This section delineates the abstract data model governing the organization of resources within the Linked Web Storage (LWS) system. It encompasses the structuring of containers and resources, their hierarchical interrelations, the functional semantics of containers as organizational units, rules pertaining to containment, and mechanisms for clients to organize and navigate resource collections. This model establishes the logical namespace of the storage, delineating inter-resource relationships therein, without presupposing any specific identifier structure or semantic implications derived from identifier composition. Logical organization MUST prioritize discoverability and self-descriptive APIs, avoiding hardcoded locations. Containment is represented as metadata to enable multiple containers per resource without URL changes, supporting sharing use cases. All entities MUST have associated metadata resources using Link Sets (RFC 9264), distinguishing server-managed (e.g., containment references) and user-managed data.
+This section delineates the abstract data model governing the organization of resources within the Linked Web Storage (LWS) system. It encompasses the structuring of containers and resources, their hierarchical interrelations, the functional semantics of containers as organizational units, rules pertaining to containment, and mechanisms for clients to organize and navigate resource collections. This model establishes the logical namespace of the storage, delineating inter-resource relationships therein, without presupposing any specific identifier structure or semantic implications derived from identifier composition. Logical organization MUST prioritize discoverability and self-descriptive APIs, avoiding hardcoded locations. Containment is represented as metadata to enable multiple containers per resource without URL changes, supporting sharing use cases. All entities MUST have associated metadata resources using Link Sets (RFC 9264), distinguishing server-managed and user-managed data.
 
 ### Resource
 
-In LWS, a resource constitutes the fundamental unit of storage and access. Each resource possesses a unique identifier within the system. A resource may encompass data, such as content or structured information, alongside associated metadata, including attributes like type or modification timestamps. Resources MUST be classified as 'DataResource' or 'Container' via metadata types (e.g., rel="type" linking to https://www.w3.org/ns/lws#DataResource or https://www.w3.org/ns/lws#Container). Resources MAY have multiple representations; servers MUST track original media types and support reification in metadata.
+In LWS, a resource constitutes the fundamental unit of storage and access. Each resource possesses a unique identifier within the system. A resource may encompass data, such as content or structured information, alongside associated metadata, including attributes like type or modification timestamps. Resources MUST be classified as 'DataResource' or 'Container' via metadata types. Resources MAY have multiple representations; servers MUST track original media types and support reification in metadata.
 
 ### Container
 
 A container represents a specialized resource type capable of encompassing other resources as members. Containers function as organizational constructs, facilitating the grouping of resources in a manner akin to collections or directories. 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 storage system's root is designated as a container, serving as the apex organizational unit devoid of a superior parent. Containers MUST support pagination for membership listings. Representations MUST use JSON-LD with a specific frame and normative context, optionally advertising content negotiation via 'Vary: Accept' headers. Storage MAY function as a root container, enabling direct writes.
 
 ### Containment and Hierarchy
 
-With the exception of the root container, every resource is affiliated with precisely one parent container. This affiliation engenders a strict hierarchical structure, manifesting as a tree with a singular root container at its pinnacle. Upon creation within a designated container, a resource becomes a member of that container, appearing within its membership enumeration. Cycles or multiple parent affiliations are prohibited within this model; a resource cannot concurrently belong to multiple containers without duplication or alternative referencing mechanisms external to the core containment framework. This constraint enhances model simplicity and aligns with conventional organizational paradigms. Containment MUST be modeled as metadata links (e.g., 'containedBy' or 'parent'), allowing transitive queries and multiple hierarchies without slash semantics. Servers MAY support hierarchy arrays for ancestors.
+With the exception of the root container, every resource is affiliated with precisely one parent container. This affiliation engenders a strict hierarchical structure, manifesting as a tree with a singular root container at its pinnacle. Upon creation within a designated container, a resource becomes a member of that container, appearing within its membership enumeration. Cycles or multiple parent affiliations are prohibited within this model; a resource cannot concurrently belong to multiple containers without duplication or alternative referencing mechanisms external to the core containment framework. This constraint enhances model simplicity and aligns with conventional organizational paradigms. Containment MUST be modeled as metadata links, allowing transitive queries and multiple hierarchies without slash semantics. Servers MAY support hierarchy arrays for ancestors.
 
 ### Container Membership Management
 

lws10-core/operations.md

@@ -1,3 +1,3 @@
-This section defines the four core operations that a Linked Web Storage (LWS) server **MUST** support. These operations manipulate resources and containers in a transport-independent manner, focusing on semantics rather than implementation details. Each operation specifies inputs, expected behaviors, and possible responses (outcomes). Responses include success indicators, resource representations (where applicable), and error conditions. Implementations **MUST** handle these operations atomically and consistently, meaning each operation either succeeds completely or fails without partial side effects. In case of errors, responses **SHOULD** provide enough detail for agents to understand the issue (e.g., an error code and message) without leaking sensitive information. All normative requirements (e.g., MUST, SHOULD, MAY) are to be interpreted as in \[[RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119)\].
+This section defines the four core operations that a Linked Web Storage (LWS) server **MUST** support. These operations manipulate resources and containers in a transport-independent manner, focusing on semantics rather than implementation details. Each operation specifies inputs, expected behaviors, and possible responses (outcomes). Responses include success indicators, resource representations (where applicable), and error conditions. Implementations **MUST** handle these operations atomically and consistently, meaning each operation either succeeds completely or fails without partial side effects. In case of errors, responses **SHOULD** provide enough detail for agents to understand the issue without leaking sensitive information. All normative requirements are to be interpreted as in \[[RFC 2119](https://datatracker.ietf.org/doc/html/rfc2119)\].
 
-All operations MUST interact with associated metadata resources as defined in Section 9.1. Servers MUST distinguish between server-managed metadata (e.g., storage descriptions, ACL references, container references) and user-managed metadata (e.g., custom types, indexes), ensuring that operations do not alter server-managed metadata without explicit authorization. Metadata updates MUST be atomic with the operation and use Link Sets (RFC 9264) for description. Servers MUST support discoverability through self-descriptive mechanisms, avoiding hardcoded URIs. For read operations on containers, servers MUST support pagination to handle large memberships. Servers MUST support optional concurrency controls (e.g., via expected version tags or ETags), failing with Conflict if the resource has changed since the client's last read. Partial updates (PATCH) are optional; if supported, they MUST use standards like JSON Patch or SPARQL Update for RDF resources. PUT for creation is not supported in this version to ensure server authority over naming; use POST for server-assigned identifiers.
+All operations MUST interact with associated metadata resources as defined in Section 9.1. Servers MUST distinguish between server-managed metadata and user-managed metadata, ensuring that operations do not alter server-managed metadata without explicit authorization. Metadata updates MUST be atomic with the operation and use Link Sets (RFC 9264) for description. Servers MUST support discoverability through self-descriptive mechanisms, avoiding hardcoded URIs. For read operations on containers, servers MUST support pagination to handle large memberships. Servers MUST support optional concurrency controls, failing with Conflict if the resource has changed since the client's last read. Partial updates (PATCH) are optional; if supported, they MUST use standards like JSON Patch or SPARQL Update for RDF resources. PUT for creation is not supported in this version to ensure server authority over naming; use POST for server-assigned identifiers.