case fixes.

tighten text.
fix storage description

Author: ebremer

lws10-core/Discovery.html

@@ -130,6 +130,10 @@ <h4>Storage Description Representation</h4>
     "type": "TypeIndexService",
     "serviceEndpoint": "https://storage.example/types/api"
   }, {
+    "type": "TypeSearchService",
+    "serviceEndpoint": "https://storage.example/types/search"
+    },
+  {
     "type": "DataSharingService",
     "serviceEndpoint": "https://storage.example/sharing/api"
   }, {
@@ -142,14 +146,14 @@ <h4>Storage Description Representation</h4>
 
 </section>
 
-<section id="type-index-service">
+<section id="type-index-services">
   <h3>Search and Type Index 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.
+  <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 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 are not required to parse resource content to discover types. Instead, servers SHOULD derive resource types from HTTP Link 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>).
   </p><p>
-Servers MAY additionally derive types from the resource representation itself when they are able to parse it. Implementations are encouraged to do so where feasible, as richer type discovery improves the utility of the Type Index and Type Search services for Linked Data clients. When a server enriches the type index from resource content, the types it surfaces MUST be treated identically to those derived from Link headers for the purposes of indexing, search, and authorization filtering.
+Servers MAY additionally derive types from the resource representation itself when they are able to parse it. Implementations are encouraged to do so where feasible, as richer type discovery improves the utility of the Type Index and Type Search services. When a server enriches the type index from resource content, the types it surfaces MUST be treated identically to those derived from Link headers for the purposes of indexing, search, and authorization filtering.
 </p>
   <p class="note">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>