rename TypeIndexService to TypeCatalogService

Author: ebremer

lws10-core/Discovery.html

@@ -142,10 +142,10 @@ <h4>Storage Description Representation</h4>
 
 </section>
 
-<section id="type-index-service">
-  <h3>Type Index and Type Search Services</h3>
+<section id="type-catalog-service">
+  <h3>Type Catalog and Type Search Services</h3>
   <p>
-    The <code>TypeIndexService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource or container URIs matching those types.
+    The <code>TypeCatalogService</code> provides a server-managed discovery mechanism to query the distinct resource types available within a storage, while the <code>TypeSearchService</code> allows clients to retrieve the specific resource or container URIs matching those types.
   </p>
 <p>
     To prevent inadvertent or malicious corruption by clients, these services are strictly populated and managed by the server. To mitigate security and performance risks associated with deep-parsing arbitrary resource bodies, servers MUST NOT be required to parse resource content to discover types. Instead, servers SHOULD derive resource types from HTTP <code>Link</code> headers provided by the client during resource creation or modification, combined with the server's intrinsic knowledge of the resource's state (such as native LWS classes like <code>https://www.w3.org/ns/lws#Container</code>).
@@ -154,25 +154,25 @@ <h4>Storage Description Representation</h4>
     Because servers are not required to parse the resource body, the Type Search Service relies heavily on the types explicitly declared via HTTP headers or managed by the server. If a client includes a type exclusively within a resource's internal graph but fails to provide the corresponding <code>Link</code> header, that type may not be discoverable via these services.
   </p>
   <p>
-    A server that implements these services MUST advertise the endpoints in the storage description resource using the <code>typeIndexService</code> and <code>typeSearchService</code> properties.
+    A server that implements these services MUST advertise the endpoints in the storage description resource using the <code>typeCatalogService</code> and <code>typeSearchService</code> properties.
   </p>
   <pre class="example" title="Services advertised in storage description">
 {
   "@context": "https://www.w3.org/ns/lws/v1",
   "id": "https://example.org/storage/alice/",
   "type": "StorageDescription",
-  "typeIndexService": "https://example.org/types/index",
+  "typeCatalogService": "https://example.org/types/catalog",
   "typeSearchService": "https://example.org/types/search"
 }
   </pre>
 
   <section>
-    <h4>GET [typeIndexService]</h4>
+    <h4>GET [typeCatalogService]</h4>
     <p>Returns <code>application/lws+json</code>:</p>
     <pre class="example">
 {
   "@context": "https://www.w3.org/ns/lws/v1",
-  "type": "TypeIndex",
+  "type": "TypeCatalog",
   "totalItems": 142,
   "items": [
     { "type": "https://schema.org/Person" },
@@ -182,7 +182,7 @@ <h4>Storage Description Representation</h4>
   "next": "..."
 }
     </pre>
-    <p>Returns a paginated <code>TypeIndex</code> following standard LWS pagination. It lists the unique types of resources that currently exist within the storage and that the authenticated user is authorized to see. This endpoint accepts no query parameters.</p>
+    <p>Returns a paginated <code>TypeCatalog</code> following standard LWS pagination. It lists the unique types of resources that currently exist within the storage and that the authenticated user is authorized to see. This endpoint accepts no query parameters.</p>
   </section>
 
   <section>
@@ -212,29 +212,29 @@ <h4>Storage Description Representation</h4>
   <section>
     <h4>Security and Authorization</h4>
     <p>
-      Servers MUST enforce authorization per access grants. Responses to GET/POST on <code>typeIndexService</code> or <code>typeSearchService</code> include only types and resource URIs that the authenticated client is explicitly authorized to read. 
+      Servers MUST enforce authorization per access grants. Responses to GET/POST on <code>typeCatalogService</code> or <code>typeSearchService</code> include only types and resource URIs that the authenticated client is explicitly authorized to read. 
     </p>
     <p>
-      Unauthorized entries MUST be omitted entirely. A client must not be able to discover the existence of a specific resource instance, or that a specific type exists in the storage at all, if they do not have the required access grants. This implicit filtering yields a dynamically generated, client-specific type index and search result.
+      Unauthorized entries MUST be omitted entirely. A client must not be able to discover the existence of a specific resource instance, or that a specific type exists in the storage at all, if they do not have the required access grants. This implicit filtering yields a dynamically generated, client-specific type catalog and search result.
     </p>
   </section>
 
   <section>
     <h4>Non-Normative Examples</h4>
-    <pre class="example" title="Example 1: GET TypeIndex (Discovering available types)">
+    <pre class="example" title="Example 1: GET TypeCatalog (Discovering available types)">
 Request
-GET /types/index
+GET /types/catalog
 
 Response
 {
   "@context": "https://www.w3.org/ns/lws/v1",
-  "type": "TypeIndex",
+  "type": "TypeCatalog",
   "totalItems": 142,
   "items": [
     { "type": "https://schema.org/Person" },
     { "type": "https://schema.org/Event" }
   ],
-  "next": "https://example.org/types/index?page=2"
+  "next": "https://example.org/types/catalog?page=2"
 }
     </pre>