Removed future tense from docs content (#6646)

* removed future tense from docs content

* removed future tense from developing docs

* removed future tense from integrating docs

* removed future tense from introduction docs

* removed future tense from managing docs

* removed future tense from metadata reference docs

* removed future tense from quick start docs

* removed future tense from reference docs

* removed future tense from using docs

* Copy edits docs content

distribution/docs/src/main/resources/content/_architectures/_asyncFramework/processing-framework-intro.adoc

@@ -19,7 +19,7 @@ has been ingested into the Catalog. This feature is uninstalled by default.
 [WARNING]
 ====
 The *Processing Framework* does not support partial updates to the Catalog. This means that if any changes are made to a metacard in the Catalog between the time
-asynchronous processing starts and ends, those changes will be overwritten by the *ProcessingFramework* updates sent back to the Catalog. This feature should be used with caution.
+asynchronous processing starts and ends, those changes are overwritten by the *ProcessingFramework* updates sent back to the Catalog. This feature should be used with caution.
 ====
 
 .Processing Framework Architecture
@@ -141,7 +141,7 @@ A `ProcessRequest` contains a list of ``ProcessItem``s for the `ProcessingFramew
 should mark the `ProcessRequest` as already been processed, so that it does not process it again.
 
 .PostProcessPlugin
-The `PostProcessPlugin` is a plugin that will be run by the `ProcessingFramework`. It is capable of processing ``ProcessCreateItem``s, ``ProcessUpdateItem``s, and ``ProcessDeleteItem``s.
+The `PostProcessPlugin` is a plugin that is run by the `ProcessingFramework`. It is capable of processing ``ProcessCreateItem``s, ``ProcessUpdateItem``s, and ``ProcessDeleteItem``s.
 
 .ProcessItem
 [WARNING]

distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-api.adoc

@@ -36,8 +36,8 @@ Searching the catalog involves three basic steps:
 .. For contextual search, optionally set the `fuzzy` flag to `true` or `false` (the default value for the `Metadata Catalog` `fuzzy` flag is `true`, while the `portal` default value is `false`).
 .. For contextual search, optionally set the `caseSensitive` flag to true (the default is that `caseSensitive` flag is NOT set and queries are not case sensitive).
 Doing so enables case sensitive matching on the search criteria.
-For example, if `caseSensitive` is set to true and the phrase is “Baghdad” then only metadata containing “Baghdad” with the same matching case will be returned.
-Words such as “baghdad”, “BAGHDAD”,  and “baghDad” will not be returned because they do not match the exact case of the search term.
+For example, if `caseSensitive` is set to true and the phrase is “Baghdad” then only metadata containing “Baghdad” with the same matching case is returned.
+Words such as “baghdad”, “BAGHDAD”,  and “baghDad” are not returned because they do not match the exact case of the search term.
 . Issue a search.
 . Examine the results.
 
@@ -76,7 +76,7 @@ There are three policies available.
 
 |===
 
-If no sort policy is defined for a particular search, the temporal policy will automatically be applied.
+If no sort policy is defined for a particular search, the temporal policy is automatically applied.
 
 
 ===== Product Retrieval

distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-camel-component.adoc

@@ -31,9 +31,9 @@ For the CREATE and UPDATE operation, the message body can contain a list of meta
 
 For the DELETE operation, the message body can contain a list of strings or a single string object.
 The string objects represent the IDs of metacards to be deleted.
-The exchange's "in" message will be set with the affected metacards.
-In the case of a CREATE, it will be updated with the created metacards.
-In the case of the UPDATE, it will be updated with the updated metacards and with the DELETE it will contain the deleted metacards.
+The exchange's "in" message is set with the affected metacards.
+In the case of a CREATE, it is updated with the created metacards.
+In the case of the UPDATE, it is updated with the updated metacards and with the DELETE it contains the deleted metacards.
 
 .Catalog Framework Camel Component Operations
 [cols="2,2,3" options="header"]
@@ -60,7 +60,7 @@ In the case of the UPDATE, it will be updated with the updated metacards and wit
 [NOTE]
 ====
 If there is an exception thrown while the route is being executed, a
-FrameworkProducerException will be thrown causing the route to fail
+`FrameworkProducerException` is thrown causing the route to fail
 with a CamelExecutionException.
 ====
 

distribution/docs/src/main/resources/content/_architectures/_catalogFrameworks/catalog-framework-intro.adoc

@@ -56,7 +56,7 @@ As such, new capabilities can be developed independently, in a modular fashion,
 
 === Ensuring Compatibility
 
-The Catalog API will evolve, but great care is taken to retain backwards compatibility with developed components.
+The Catalog API evolves, but great care is taken to retain backwards compatibility with developed components.
 Compatibility is reflected in version numbers.
 
 === Catalog Framework Sequence Diagrams
@@ -108,8 +108,8 @@ Similarly, for deletion of catalog entries, the delete requests call the `delete
 
 ==== Error Handling
 
-Any ingest attempts that fail inside the Catalog Framework (whether the failure comes from the Catalog Framework itself, pre-ingest plugin failures, or issues with the Catalog Provider) will be logged to a separate log file for ease of error handling.
-The file is located at `${home_directory}/data/log/ingest_error.log` and will log the Metacards that fail, their ID and Title name, and the stack trace associated with their failure.
+Any ingest attempts that fail inside the Catalog Framework (whether the failure comes from the Catalog Framework itself, pre-ingest plugin failures, or issues with the Catalog Provider) are logged to a separate log file for ease of error handling.
+The file is located at `${home_directory}/data/log/ingest_error.log` and it logs the Metacards that fail, their ID and Title name, and the stack trace associated with their failure.
 By default, successful ingest attempts are not logged.
 However, that functionality can be achieved by setting the log level of the `ingestLogger` to DEBUG (note that enabling DEBUG can cause a non-trivial performance hit).
 
@@ -161,25 +161,24 @@ The Endpoint bundle contains a Web service that exposes the interface to query f
 The Endpoint calls the `CatalogFramework` to execute the operations of its specification.
 The `CatalogFramework` relies on the `CatalogProvider` to execute the actual query.
 Optional PreQuery and PostQuery Catalog Plugins may be invoked by the `CatalogFramework` to modify the query request/response prior to the Catalog Provider processing the query request and providing the query response.
-If a `CatalogProvider` is not configured and no other remote Sources are configured, a fault will be returned.
+If a `CatalogProvider` is not configured, and no other remote Sources are configured, a fault is returned.
 It is possible to have only remote Sources configured and no local `CatalogProvider` configured and be able to execute queries to specific remote Sources by specifying the site names in the query request.
 
-
 ==== Product Caching
 
-The Catalog Framework optionally provides caching of products, so future requests to retrieve the same product will be serviced much quicker.
-If caching is enabled, each time a retrieve product request is received, the Catalog Framework will look in its cache (default location `${home_directory}/data/product-cache`) to see if the product has been cached locally.
+The Catalog Framework optionally provides caching of products, so future requests to retrieve the same product are serviced much quicker.
+If caching is enabled, each time a retrieve product request is received, the Catalog Framework looks in its cache (default location `${home_directory}/data/product-cache`) to see if the product has been cached locally.
 If it has, the product is retrieved from the local site and returned to the client, providing a much quicker turnaround because remote product retrieval and network traffic was avoided.
 If the requested product is not in the cache, the product is retrieved from the Source (local or remote) and cached locally while returning the product to the client.
 The caching to a local file of the product and the streaming of the product to the client are done simultaneously so that the client does not have to wait for the caching to complete before receiving the product.
-If errors are detected during the caching, caching of the product will be abandoned, and the product will be returned to the client.
+If errors are detected during the caching, caching of the product is abandoned, and the product is returned to the client.
 
 The Catalog Framework attempts to detect any network problems during the product retrieval, for example, long pauses where no bytes are read implying a network connection was dropped.
 (The amount of time defined as a "long pause" is configurable, with the default value being five seconds.)
-The Catalog Framework will attempt to retrieve the product up to a configurable number of times (default = three), waiting for a configurable amount of time (default = 10 seconds) between each attempt, trying to successfully retrieve the product.
+The Catalog Framework attempts to retrieve the product up to a configurable number of times (default = three), waiting for a configurable amount of time (default = 10 seconds) between each attempt, trying to successfully retrieve the product.
 If the Catalog Framework is unable to retrieve the product, an error message is returned to the client.
 
-If the admin has enabled the *Always Cache When Canceled* option, caching of the product will occur even if the client cancels the product retrieval so that future requests will be serviced quickly.
+If the admin has enabled the *Always Cache When Canceled* option, caching of the product occurs even if the client cancels the product retrieval so that future requests are serviced quickly.
 Otherwise, caching is canceled if the user cancels the product download.
 
 ==== Product Download Status

distribution/docs/src/main/resources/content/_architectures/_data/data-intro.adoc

@@ -90,7 +90,7 @@ Consult the documentation of the Catalog Provider in use for more information on
 ====
 
 Often, the `BASIC_METACARD` `MetacardType` does not provide all the functionality or attributes necessary for a specific task.
-For performance or convenience purposes, it may be necessary to create custom attributes even if others will not be aware of those attributes.
+For performance or convenience purposes, it may be necessary to create custom attributes even if others are be aware of those attributes.
 One example could be if a user wanted to optimize a search for a date field that did not fit the definition of `CREATED`, `MODIFIED`, `EXPIRATION`, or `EFFECTIVE`.
 The user could create an additional `java.util.Date` attribute in order to query the attribute separately.
 
@@ -113,7 +113,7 @@ It maintains a list of all supported `MetacardTypes` in the `CatalogFramework`,
 The `MetacardType` is essential for a component in the `CatalogFramework` to understand how it should interpret a metacard by knowing what attributes are available in that metacard.
 
 For example, an endpoint receiving incoming metadata can perform a lookup in the `MetacardTypeRegistry` to find a corresponding `MetacardType`.
-The discovered `MetacardType` will then be used to help the endpoint populate a metacard based on the specified attributes in the `MetacardType`.
+The discovered `MetacardType` is then used to help the endpoint populate a metacard based on the specified attributes in the `MetacardType`.
 By doing this, all the incoming metadata elements can then be available for processing, cataloging, and searching by the rest of the `CatalogFramework`.
 
 `MetacardTypes` should be registered with the `MetacardTypeRegistry`.  The `MetacardTypeRegistry` makes those `MetacardTypes` available to other ${branding} `CatalogFramework` components.
@@ -138,7 +138,7 @@ The reference to this service can then be used to register new `MetacardTypes` o
 
 New `MetacardTypes` are typically registered by `CatalogProviders` or sources indicating they know how to persist, index, and query attributes from that type.
 Endpoints or `InputTransformers` typically use the lookup functionality to access a `MetacardType` based on a parameter in the incoming metadata.
-Once the appropriate `MetacardType` is discovered and obtained from the registry, the component will know how to translate incoming raw metadata into a ${branding} Metacard.
+Once the appropriate `MetacardType` is discovered and obtained from the registry, the component knows how to translate incoming raw metadata into a ${branding} Metacard.
 
 === Attributes
 

distribution/docs/src/main/resources/content/_architectures/_eventing/eventing-intro.adoc

@@ -36,7 +36,7 @@ The ((Eventing)) capability of the Catalog allows endpoints (and thus external u
 Notably, the Catalog allows event evaluation on both the previous value (if available) and new value of a Metacard when an update occurs.
 
 Eventing allows ${branding}s to receive events on operations (such as create, update, delete) based on particular queries or actions.
-Once subscribed, users will receive notifications of events such as update or create on any source.
+Once subscribed, users receive notifications of events such as update or create on any source.
 
 == Eventing Components
 

distribution/docs/src/main/resources/content/_architectures/_plugins/filter-plugin.adoc

@@ -12,10 +12,10 @@ The security attribute is a Map containing a set of keys that map to lists of va
 The metacard is then processed by a filter plugin that creates a `KeyValueCollectionPermission` from the metacard's security attribute.
 This permission is then checked against the user subject to determine if the subject has the correct claims to view that metacard.
 The decision to filter the metacard eventually relies on the installed <<_security_pdp,Policy Decision Point>> (PDP).
-The PDP that is being used returns a decision, and the metacard will either be filtered or allowed to pass through.
+The PDP that is being used returns a decision, and the metacard is either filtered or allowed to pass through.
 
 How a metacard gets filtered is left up to any number of FilterStrategy implementations that might be installed.
-Each FilterStrategy will return a result to the filter plugin that says whether or not it was able to process the metacard, along with the metacard or response itself.
+Each `FilterStrategy` returns a result to the filter plugin that says whether or not it was able to process the metacard, along with the metacard or response itself.
 This allows a metacard or entire response to be partially filtered to allow some data to pass back to the requester.
 This could also include filtering any resources sent back to a requester.
 
@@ -58,8 +58,8 @@ Each type of metacard must have its own `PolicyPlugin` that reads the metadata b
 ----
 
 In the above example, the user's claims are represented very simply and are similar to how they would actually appear in a SAML 2 assertion.
-Each of these user (or subject) claims will be converted to a `KeyValuePermission` object.
-These permission objects will be implied against the permission object generated from the metacard record.
+Each of these user (or subject) claims is converted to a `KeyValuePermission` object.
+These permission objects is implied against the permission object generated from the metacard record.
 In this particular case, the metacard might be allowed if the policy is configured appropriately because all of the permissions line up correctly.
 
 == Installing the Filter Plugin

distribution/docs/src/main/resources/content/_architectures/_plugins/geocoder-plugin.adoc

@@ -6,8 +6,8 @@
 :summary: Populates the `Location.COUNTRY_CODE` attribute if the Metacard has an associated location.
 
 The ((GeoCoder plugin)) is a pre-ingest plugin that is responsible for populating the Metacard's `Location.COUNTRY_CODE` attribute if the Metacard has an associated location.
-If there is a valid country code for the Metacard, it will be in ISO 3166-1 alpha-3 format.
-If the metacard's country code is already populated, the plugin will *not* override it.
+If there is a valid country code for the Metacard, it is in ISO 3166-1 alpha-3 format.
+If the metacard's country code is already populated, the plugin does *not* override it.
 The GeoCoder relies on either the WebService or <<{reference-prefix}offline_gazetteer_service,Offline Gazetteer>> to retrieve country code information.
 
 [WARNING]

distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-attribute-plugin.adoc

@@ -25,7 +25,7 @@ For example, if the source attributes `sourceattribute1` and `sourceattribute2`
 `destinationattribute1 = MASK, VESSEL, WIRE, SACK`
 
 The other way to combine attributes is use the values common to all of the attributes.
-This is called the intersection. Using our previous example, the **intersection** of
+This is called the intersection. Using the previous example, the **intersection** of
 `sourceattribute1` and `sourceattribute2` would create the new attribute `destinationattribute1`
 
 `destinationattribute1 = MASK`

distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-filestorage.adoc

@@ -5,7 +5,7 @@
 :plugintypes: postingest
 :summary: Stores backed-up metacards.
 
-The ((Metacard Backup File Storage Provider)) is a storage provider that will store backed-up metacards in a specified file system location.
+The ((Metacard Backup File Storage Provider)) is a storage provider that stores backed-up metacards in a specified file system location.
 
 == Installing the Metacard Backup File Storage Provider
 

distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-backup-s3-storage.adoc

@@ -5,7 +5,7 @@
 :plugintypes: postingest
 :summary: Stores backed-up metacards in a specified S3 bucket and key.
 
-The ((Metacard Backup S3 Storage Provider)) is a storage provider that will store backed up metacards in the specified ((S3)) bucket and key.
+The ((Metacard Backup S3 Storage Provider)) is a storage provider that stores backed up metacards in the specified ((S3)) bucket and key.
 
 == Installing the Metacard S3 File Storage Provider
 

distribution/docs/src/main/resources/content/_architectures/_plugins/metacard-groomer.adoc

@@ -7,7 +7,7 @@
 
 The ((Metacard Groomer Pre-Ingest plugin)) makes modifications to `CreateRequest` and `UpdateRequest` metacards.
 
-Use this pre-ingest plugin as a convenience to apply basic rules for your metacards. 
+Use this pre-ingest plugin as a convenience to apply basic rules for your metacards.
 
 This plugin makes the following modifications when metacards are in a `CreateRequest`:
 
@@ -19,7 +19,7 @@ This plugin makes the following modifications when metacards are in a `CreateReq
 
 In an `UpdateRequest`, the same operations are performed as a `CreateRequest`, except:
 
-* If no value is provided for `Metacard.ID` in the new metacard, it will be set using the `UpdateRequest` ID if applicable.
+* If no value is provided for `Metacard.ID` in the new metacard, it is set using the `UpdateRequest` ID if applicable.
 
 == Installing the Metacard Groomer