Ref Guide: typos, headline case, abbreviations, etc., for 8.9

solr/solr-ref-guide/src/basic-authentication-plugin.adoc

@@ -213,7 +213,7 @@ QueryResponse rsp = req.process(solrClient);
 
 While this is method is simple, it can often be inconvenient to ensure the credentials are provided everywhere they're needed.  It also doesn't work with the many `SolrClient` methods which don't consume `SolrRequest` objects.
 
-=== Per-Client credentials
+=== Per-Client Credentials
 Http2SolrClient supports setting the credentials at the client level when building it. This will ensure all requests issued with this particular client get the Basic Authentication headers set.
 
 [source,java]

solr/solr-ref-guide/src/cluster-node-management.adoc

@@ -42,7 +42,7 @@ the percentage of active replicas (`active`):
 `RED`::
 No active replicas *OR* there's no shard leader.
 
-The collection health state is reported as the worst state of any shard, e.g. for a
+The collection health state is reported as the worst state of any shard, e.g., for a
 collection with all shards GREEN except for one YELLOW the collection health will be
 reported as YELLOW.
 

solr/solr-ref-guide/src/collapse-and-expand-results.adoc

@@ -138,19 +138,19 @@ fq={!collapse cost=1000 field=group_field}
 
 === Block Collapsing
 
-When collapsing on the `\_root_` field, using `nullPolicy=expand` or `nullPolicy=ignore`, the Collapsing Query Parser can take advantage of the fact that all docs with identical field values are adjacent to eachother in the index in a single <<indexing-nested-documents.adoc#,"block" of nested documents>>.  This allows the collapsing logic to be much faster and more memory efficient.
+When collapsing on the `\_root_` field, using `nullPolicy=expand` or `nullPolicy=ignore`, the Collapsing Query Parser can take advantage of the fact that all docs with identical field values are adjacent to each other in the index in a single <<indexing-nested-documents.adoc#,"block" of nested documents>>. This allows the collapsing logic to be much faster and more memory efficient.
 
 The default collapsing logic must keep track of all group head documents -- for all groups encountered so far -- until it has evaluated all documents, because each document it considers may become the new group head of any group.
 
 When collapsing on the `\_root_` field however, the logic knows that as it scans over the index, it will never encounter any new documents in a group that it has previously processed.
 
-This more efficient logic can also be used with other `collapseField` values, via the `hint=block` local param.  This can be useful when you have deeply nested documents and you'd like to collapse on a field that does not contain identical values for all documents with a common `\_root_` but is a unique & identical value for sets of contiguious documents under a common `\_root_`.  For example: searching for "grand child" documents and collapsing on a field that is unique per "child document"
+This more efficient logic can also be used with other `collapseField` values, via the `hint=block` local param.  This can be useful when you have deeply nested documents and you'd like to collapse on a field that does not contain identical values for all documents with a common `\_root_` but is a unique and identical value for sets of contiguous documents under a common `\_root_`.  For example: searching for "grand child" documents and collapsing on a field that is unique per "child document"
 
 [CAUTION]
 ====
-Specifing `hint=block` when collapsing on a field that is not unique per contiguious block of documents is not supported and may fail in unexpected ways; including the possibility of silently returning incorrect results.
+Specifing `hint=block` when collapsing on a field that is not unique per contiguous block of documents is not supported and may fail in unexpected ways; including the possibility of silently returning incorrect results.
 
-The implementation does not offer any safeguards against missuse on an unsupported field, since doing so would require the the same group level tracking as the non-Block collapsing implementation -- defeating the purpose of this optimization.
+The implementation does not offer any safeguards against misuse on an unsupported field, since doing so would require the the same group level tracking as the non-Block collapsing implementation -- defeating the purpose of this optimization.
 ====
 
 == Expand Component
@@ -210,4 +210,7 @@ Overrides the main query (`q`), determines which documents to include in the mai
 Overrides main filter queries (`fq`), determines which documents to include in the main group. The default is to use the main filter queries.
 
 `expand.nullGroup`::
-Indicates if an expanded group can be returned containing documents with no value in the expanded field.  This option only _enables_ support for returning a "null" expanded group: As with all expanded groups, it will only exist if the main group includes corresponding documents for it to expand (Via `collapse` using either `nullPolicy=collapse` or `nullPolicy=expand`; Or via `expand.q`) _and_ documents are found that belong in this expanded group.  The default value is `false`
+Indicates if an expanded group can be returned containing documents with no value in the expanded field.
+This option only _enables_ support for returning a "null" expanded group.
+As with all expanded groups, it will only exist if the main group includes corresponding documents for it to expand (via `collapse` using either `nullPolicy=collapse` or `nullPolicy=expand`; or via `expand.q`) _and_ documents are found that belong in this expanded group.
+The default value is `false`.

solr/solr-ref-guide/src/collection-management.adoc

@@ -95,7 +95,7 @@ If this parameter is specified, the router will look at the value of the field i
 Please note that <<realtime-get.adoc#,RealTime Get>> or retrieval by document ID would also require the parameter `\_route_` (or `shard.keys`) to avoid a distributed search.
 
 `perReplicaState`::
-If `true` the states of individual replicas will be maintained as individual child of the `state.json`. default is `false`
+If `true` the states of individual replicas will be maintained as individual child of the `state.json`. The default is `false`.
 
 `property._name_=_value_`::
 Set core property _name_ to _value_. See the section <<defining-core-properties.adoc#,Defining core.properties>> for details on supported properties and values.

solr/solr-ref-guide/src/config-api.adoc

@@ -60,7 +60,7 @@ http://localhost:8983/api/collections/techproducts/config
 The response will be the Solr configuration resulting from merging settings in `configoverlay.json` with those in `solrconfig.xml`.
 
 
-It's possible to restrict the returned config to a top-level section, such as, `query`, `requestHandler` or `updateHandler`. To do this, append the name of the section to the `config` endpoint. For example, to retrieve configuration for all request handlers:
+It's possible to restrict the returned configuration to a top-level section, such as, `query`, `requestHandler` or `updateHandler`. To do this, append the name of the section to the `config` endpoint. For example, to retrieve configuration for all request handlers:
 
 [.dynamic-tabs]
 --
@@ -902,4 +902,4 @@ Any component can register a listener using:
 
 `SolrCore#addConfListener(Runnable listener)`
 
-to get notified for config changes. This is not very useful if the files modified result in core reloads (i.e., `configoverlay.xml` or the schema). Components can use this to reload the files they are interested in.
+to get notified for configuration changes. This is not very useful if the files modified result in core reloads (i.e., `configoverlay.xml` or the schema). Components can use this to reload the files they are interested in.

solr/solr-ref-guide/src/configsets-api.adoc

@@ -101,19 +101,19 @@ The configset to be created when the upload is complete. This parameter is requi
 
 `overwrite`::
 If set to `true`, Solr will overwrite an existing configset with the same name (if false, the request will fail).
-If `filePath` is provided, then this option specifies whether the specified file within the configSet should be overwritten if it already exists.
+If `filePath` is provided, then this option specifies whether the specified file within the configset should be overwritten if it already exists.
 Default is `false` when using the v1 API, but `true` when using the v2 API.
 
 `cleanup`::
 When overwriting an existing configset (`overwrite=true`), this parameter tells Solr to delete the files in ZooKeeper that existed in the old configset but not in the one being uploaded. Default is `false`.
 This parameter cannot be set to true when `filePath` is used.
 
 `filePath`::
-This parameter allows the uploading of a single, non-zipped file to the given path under the configSet in ZooKeeper.
-This functionality respects the `overwrite` parameter, so a request will fail if the given file path already exists in the configSet and overwrite is set to `false`.
+This parameter allows the uploading of a single, non-zipped file to the given path under the configset in ZooKeeper.
+This functionality respects the `overwrite` parameter, so a request will fail if the given file path already exists in the configset and overwrite is set to `false`.
 The `cleanup` parameter cannot be set to true when `filePath` is used.
 
-If uploading an entire configSet, the body of the request should be a zip file that contains the configset. The zip file must be created from within the `conf` directory (i.e., `solrconfig.xml` must be the top level entry in the zip file).
+If uploading an entire configset, the body of the request should be a zip file that contains the configset. The zip file must be created from within the `conf` directory (i.e., `solrconfig.xml` must be the top level entry in the zip file).
 
 Here is an example on how to create the zip file named "myconfig.zip" and upload it as a configset named "myConfigSet":
 
@@ -154,8 +154,8 @@ $ curl -X PUT --header "Content-Type:application/octet-stream" --data-binary @my
     "http://localhost:8983/api/cluster/configs/myConfigSet"
 ----
 
-With this REST API, the default behavior is to overwrite the configSet if it already exists.
-This behavior can be disabled by providing the URL param `overwrite=false`, in which case the request will fail if the configSet already exists.
+With this  API, the default behavior is to overwrite the configset if it already exists.
+This behavior can be disabled with the parameter `overwrite=false`, in which case the request will fail if the configset already exists.
 ====
 --
 
@@ -168,7 +168,7 @@ Here is an example on how to upload a single file to a configset named "myConfig
 [.tab-label]*V1 API*
 
 With the v1 API, the `upload` command must be capitalized as `UPLOAD`.
-The filename to upload is provided via the `filePath` URL param:
+The filename to upload is provided via the `filePath` parameter:
 
 [source,bash]
 ----
@@ -183,7 +183,7 @@ curl -X POST --header "Content-Type:application/octet-stream"
 [.tab-label]*V2 API*
 
 With the v2 API, the name of the configset and file are both provided in the URL.
-They can be substituted in `/cluster/configs/{config_name}/{file_name}`.
+They can be substituted in `/cluster/configs/__config_name__/__file_name__`.
 The filename may be nested and include `/` characters.
 
 [source,bash]
@@ -193,8 +193,8 @@ curl -X PUT --header "Content-Type:application/octet-stream"
     "http://localhost:8983/api/cluster/configs/myConfigSet/solrconfig.xml"
 ----
 
-With this REST API, the default behavior is to overwrite the file if it already exists within the configSet.
-This behavior can be disabled by providing the URL param `overwrite=false`, in which case the request will fail if the file already exists within the configSet.
+With this API, the default behavior is to overwrite the file if it already exists within the configset.
+This behavior can be disabled with the parameter `overwrite=false`, in which case the request will fail if the file already exists within the configset.
 ====
 --
 
@@ -248,7 +248,7 @@ curl -X POST -H 'Content-type: application/json' -d '{
     http://localhost:8983/api/cluster/configs?omitHeader=true
 ----
 
-With the v2 API, ConfigSet properties can also be provided via the `properties` map:
+With the v2 API, configset properties can also be provided via the `properties` map:
 
 [source,bash]
 ----

solr/solr-ref-guide/src/de-duplication.adoc

@@ -56,7 +56,7 @@ The `SignatureUpdateProcessorFactory` has to be registered in `solrconfig.xml` a
 
 The `SignatureUpdateProcessorFactory` takes several properties:
 
-signatureClass::
+`signatureClass`::
 A Signature implementation for generating a signature hash. The default is `org.apache.solr.update.processor.Lookup3Signature`.
 +
 The full classpath of the implementation must be specified. The available options are described above, the associated classpaths to use are:
@@ -65,16 +65,16 @@ The full classpath of the implementation must be specified. The available option
 * `org.apache.solr.update.processor.MD5Signature`
 * `org.apache.solr.update.process.TextProfileSignature`
 
-fields::
+`fields`::
 The fields to use to generate the signature hash in a comma separated list. By default, all fields on the document will be used.
 
-signatureField::
+`signatureField`::
 The name of the field used to hold the fingerprint/signature. The field should be defined in `schema.xml`. The default is `signatureField`.
 
-enabled::
+`enabled`::
 Set to *false* to disable de-duplication processing. The default is *true*.
 
-overwriteDupes::
+`overwriteDupes`::
 If *true*, the default, when a document exists that already matches this signature, it will be overwritten.  If you are using `overwriteDupes=true` the `signatureField` must be `indexed="true"` in your Schema.
 
 .Using `SignatureUpdateProcessorFactory` in SolrCloud

solr/solr-ref-guide/src/distributed-requests.adoc

@@ -195,7 +195,7 @@ Query will be routed to nodes with same defined system properties as the current
 
 Examples:
 
-* Prefer stable routing (keyed to client "sessionId" param) among otherwise equivalent replicas:
+* Prefer stable routing (keyed to client "sessionId" parameter) among otherwise equivalent replicas:
    `shards.preference=replica.base:stable:hash:sessionId&sessionId=abc123`
 
 * Prefer PULL replicas:

solr/solr-ref-guide/src/docvalues.adoc

@@ -79,7 +79,7 @@ If `docValues="true"` for a field, then DocValues will automatically be used any
 
 Field values retrieved during search queries are typically returned from stored values. However, non-stored docValues fields will be also returned along with other stored fields when all fields (or pattern matching globs) are specified to be returned (e.g., "`fl=*`") for search queries depending on the effective value of the `useDocValuesAsStored` parameter for each field. For schema versions >= 1.6, the implicit default is `useDocValuesAsStored="true"`. See <<field-type-definitions-and-properties.adoc#,Field Type Definitions and Properties>> & <<defining-fields.adoc#,Defining Fields>> for more details.
 
-When `useDocValuesAsStored="false"`, non-stored DocValues fields can still be explicitly requested by name in the <<common-query-parameters.adoc#fl-field-list-parameter,fl param>>, but will not match glob patterns (`"*"`). Note that returning DocValues along with "regular" stored fields at query time has performance implications that stored fields may not because DocValues are column-oriented and may therefore incur additional cost to retrieve for each returned document. Also note that while returning non-stored fields from DocValues, the values of a multi-valued field are returned in sorted order rather than insertion order and may have duplicates removed, see above. If you require the multi-valued fields to be returned in the original insertion order, then make your multi-valued field as stored (such a change requires reindexing).
+When `useDocValuesAsStored="false"`, non-stored DocValues fields can still be explicitly requested by name in the <<common-query-parameters.adoc#fl-field-list-parameter,`fl` parameter>>, but will not match glob patterns (`"*"`). Note that returning DocValues along with "regular" stored fields at query time has performance implications that stored fields may not because DocValues are column-oriented and may therefore incur additional cost to retrieve for each returned document. Also note that while returning non-stored fields from DocValues, the values of a multi-valued field are returned in sorted order rather than insertion order and may have duplicates removed, see above. If you require the multi-valued fields to be returned in the original insertion order, then make your multi-valued field as stored (such a change requires reindexing).
 
 In cases where the query is returning _only_ docValues fields performance may improve since returning stored fields requires disk reads and decompression whereas returning docValues fields in the fl list only requires memory access.
 

solr/solr-ref-guide/src/graph.adoc

@@ -289,7 +289,7 @@ one product. A basket with just butter and one other item more strongly recommen
 
 The `maxDocFreq` parameter can be used to limit the graph "walk" to only include baskets that appear in
 the index a certain number of times. Since each occurrence of a basket ID in the index is a link to a product,
-limiting the document frequency of the basket ID will limit the out-degree of the basket. The `maxDocFreq` param is
+limiting the document frequency of the basket ID will limit the out-degree of the basket. The `maxDocFreq` parameter is
 applied per shard. If there is a single shard or documents are co-located by basket ID then the `maxDocFreq` will
 be an exact count. Otherwise, it will return baskets with a max size of numShards * maxDocFreq.
 
@@ -739,4 +739,3 @@ This score give us a good indication of where to begin our *root cause analysis*
   }
 }
 ----
-

solr/solr-ref-guide/src/indexing-nested-documents.adoc

@@ -38,8 +38,8 @@ Nested documents may be indexed via either the XML or JSON data syntax, and is a
 
 [CAUTION]
 ====
-.Re-Indexing Considerations
-With the exception of in-place updates, Solr must internally re-index an entire nested document tree
+.Reindexing Considerations
+With the exception of in-place updates, Solr must internally reindex an entire nested document tree
 if there are updates to it.  For some applications this may
 result in a lot of extra indexing overhead that may not be worth the performance gains at query
 time versus other modeling approaches.

solr/solr-ref-guide/src/json-request-api.adoc

@@ -19,7 +19,9 @@
 // specific language governing permissions and limitations
 // under the License.
 
-Solr supports an alternate request API which accepts requests composed in part or entirely of JSON objects. This alternate API can be preferable in some situations, where its increased readability and flexibility make it easier to use than the entirely query-param driven alternative.  There is also some functionality which can only be accessed through this JSON request API, such as much of the analytics capabilities of <<json-facet-api.adoc#facet-analytics-module,JSON Faceting>>
+Solr supports an alternate request API which accepts requests composed in part or entirely of JSON objects.
+This alternate API can be preferable in some situations, where its increased readability and flexibility make it easier to use than the entirely query-parameter driven alternative.
+There is also some functionality which can only be accessed through this JSON request API, such as much of the analytics capabilities of <<json-facet-api.adoc#facet-analytics-module,JSON Faceting>>
 
 == Building JSON Requests
 The core of the JSON Request API is its ability to specify request parameters as JSON in the request body, as shown by the example below:

solr/solr-ref-guide/src/jwt-authentication-plugin.adoc

@@ -162,10 +162,10 @@ Let's comment on this config:
 <12> Configure the audience claim. A token's 'aud' claim must match 'aud' for one of the configured issuers.
 <13> This issuer is auto configured through discovery, so 'iss' and JWK settings are not required
 
-=== Using non SSL URLs
+=== Using non-SSL URLs
 In production environments you should always use SSL protected HTTPS connections, otherwise you open yourself up to attacks.
-However, in development, it may be useful to use regular http urls, and bypass the
-security check that Solr performs. To support this you can set the environment variable `solr.auth.jwt.allowOutboundHttp=true`.
+However, in development, it may be useful to use regular HTTP URLs, and bypass the security check that Solr performs.
+To support this you can set the environment variable `-Dsolr.auth.jwt.allowOutboundHttp=true` at startup.
 
 == Editing JWT Authentication Plugin Configuration