Revert "edits to docs to remove latin abbreviations (#6640)"

This reverts commit e2893a9.

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

@@ -173,7 +173,7 @@ If the requested product is not in the cache, the product is retrieved from the
 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.
 
-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 Catalog Framework attempts to detect any network problems during the product retrieval, e.g., 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.
 If the Catalog Framework is unable to retrieve the product, an error message is returned to the client.

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

@@ -21,10 +21,10 @@ Use this framework if:
 It is possible to have only remote Sources configured with no local `CatalogProvider` configured and be able to execute queries to specific remote sources by specifying the site name(s) in the query request.
 
 The Standard Catalog Framework also maintains a list of `ResourceReaders` for resource retrieval operations.
-A resource reader is matched to the scheme (the protocol, such as `file://`) in the URI of the resource specified in the request to be retrieved.
+A resource reader is matched to the scheme (i.e., protocol, such as `file://`) in the URI of the resource specified in the request to be retrieved.
 
 Site information about the catalog provider and/or any federated source(s) can be retrieved using the Standard Catalog Framework.
-Site information includes the source's name, version, availability, and the list of unique content types currently stored in the source (such as NITF).
+Site information includes the source's name, version, availability, and the list of unique content types currently stored in the source (e.g., NITF).
 If no local catalog provider is configured, the site information returned includes site info for the catalog framework with no content types included.
 
 == Installing the Standard Catalog Framework

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

@@ -83,7 +83,7 @@ Required attributes must be the base of all extensible metacard types.
 [WARNING]
 ====
 Not all <<{managing-prefix}catalog_providers,Catalog Providers>> support extensible metacards.
-Nevertheless, each Catalog Provider should at least have support for the default `MetacardType`. That is, it should be able to store and query on the attributes and attribute formats specified by the default metacard type.
+Nevertheless, each Catalog Provider should at least have support for the default `MetacardType`; i.e., it should be able to store and query on the attributes and attribute formats specified by the default metacard type.
 Catalog providers are neither expected nor required to store attributes that are not in a given metacard's type.
 
 Consult the documentation of the Catalog Provider in use for more information on its support of extensible metacards.

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

@@ -35,7 +35,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.
+Eventing allows ${branding}s to receive events on operations (e.g. 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.
 
 == Eventing Components

distribution/docs/src/main/resources/content/_architectures/_operations/operations-intro.adoc

@@ -35,7 +35,7 @@ The Catalog provides the capability to query, create, update, and delete metacar
 Each of these operations follow a request/response paradigm.
 The request is the input to the operation and contains all of the input parameters needed by the Catalog Framework's operation to communicate with the Sources.
 The response is the output from the execution of the operation that is returned to the client, which contains all of the data returned by the sources.
-For each operation there is an associated request/response pair. For example, the `QueryRequest` and `QueryResponse` pair for the Catalog Framework's query operation.
+For each operation there is an associated request/response pair, e.g., the `QueryRequest` and `QueryResponse` pair for the Catalog Framework's query operation.
 
 All of the request and response objects are extensible in that they can contain additional key/value properties on each request/response.
 This allows additional capability to be added without changing the Catalog API, helping to maintain backwards compatibility.

distribution/docs/src/main/resources/content/_architectures/_queries/filterbuilder-api.adoc

@@ -32,4 +32,4 @@ Filters use a number of boolean operators.
 
 Filters can be based on specific attributes.
 
-`FilterBuilder.attribute(String attributeName)`:: begins a fluent API for creating an Attribute-based Filter, which is a Filter that matches on Metacards with Attributes of a particular value.
+`FilterBuilder.attribute(String attributeName)`:: begins a fluent API for creating an Attribute-based Filter, i.e., a Filter that matches on Metacards with Attributes of a particular value.

distribution/docs/src/main/resources/content/_architectures/_resources/content-item.adoc

@@ -7,5 +7,5 @@
 :summary: Content Item.
 
 ((Content Item)) is the domain object populated by the Storage Provider that represents the information about the content to be stored or content that has been stored in the Storage Provider.
-A `ContentItem` encapsulates the content's globally unique ID, mime type, and input stream (that is, the actual content).
+A `ContentItem` encapsulates the content's globally unique ID, mime type, and input stream (i.e., the actual content).
 The unique ID of a `ContentItem` will always correspond to a Metacard ID.

distribution/docs/src/main/resources/content/_architectures/_securityFramework/external-ws-s-sts-support.adoc

@@ -15,6 +15,6 @@ Use these auth types when connecting to a non-${branding} STS or if ignoring rea
 === Security STS Address Provider
 (((Security STS Address Provider)))
 
-This allows one to select which STS address will be used (for example, in SOAP sources) for clients of this service.
+This allows one to select which STS address will be used (e.g. in SOAP sources) for clients of this service.
 Default is off (internal).
 

distribution/docs/src/main/resources/content/_architectures/_securityFramework/security-expansion-service.adoc

@@ -45,7 +45,7 @@ The result is returned to the caller.
 |===
 
 .Included Expansions
-Note that the rules listed for each key are processed in order, so they may build upon each other. That is, a new value from the new replacement string may be expanded by a subsequent rule.
+Note that the rules listed for each key are processed in order, so they may build upon each other, i.e., a new value from the new replacement string may be expanded by a subsequent rule.
 In the example `Location:Goodyear` would expand to `Goodyear AZ USA` and `Title:VP-Sales` would expand to `VP-Sales VP Sales`.
 
 To use the expansion service, modify the following two files within the `${home_directory}/etc/pdp` directory:

distribution/docs/src/main/resources/content/_architectures/_securityFramework/security-filtering.adoc

@@ -10,7 +10,7 @@
 
 ((Metacard filtering)) is performed by the <<{developing-prefix}filter_plugin,Filter Plugin>> after a query has been performed, but before the results are returned to the requestor.
 
-Each metacard result will contain security attributes that are populated by the CatalogFramework based on the PolicyPlugins that populates this attribute. (These plugins are NOT provided by default. You must create your own plugin for your specific metadata)
+Each metacard result will contain security attributes that are populated by the CatalogFramework based on the PolicyPlugins (Not provided! You must create your own plugin for your specific metadata!) that populates this attribute.
 The security attribute is a HashMap containing a set of keys that map to lists of values.
 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.

distribution/docs/src/main/resources/content/_architectures/_securityFramework/security-ldap-embedded-server.adoc

@@ -99,7 +99,7 @@ The Embedded LDAP application contains an LDAP server (OpenDJ version 2.6.2) tha
 
 |`testuser2`
 |`password2`
-|
+| 
 |General test user for authentication
 
 |`nromanova`
@@ -229,8 +229,8 @@ The default schemas loaded into the LDAP instance are the same defaults that com
 
 === Starting and Stopping the Embedded LDAP
 
-The embedded LDAP application installs a feature with the name `ldap-embedded`.
-Installing and uninstalling this feature will start and stop the embedded LDAP server.
+The embedded LDAP application installs a feature with the name `ldap-embedded`.
+Installing and uninstalling this feature will start and stop the embedded LDAP server.
 This will also install a fresh instance of the server each time.
 If changes need to persist, stop then start the `embedded-ldap-opendj` bundle (rather than installing/uninstalling the feature).
 
@@ -241,7 +241,7 @@ If ${branding} is stopped while the LDAP feature is installed and started, it wi
 
 Current limitations for the embedded LDAP instances include:
 
-* Inability to store the LDAP files/storage outside of the ${branding} installation directory. This results in any LDAP data (that is, LDAP user information) being lost when the `ldap-embedded` feature is uninstalled.
+* Inability to store the LDAP files/storage outside of the ${branding} installation directory. This results in any LDAP data (i.e., LDAP user information) being lost when the `ldap-embedded` feature is uninstalled.
 * Cannot be run standalone from ${branding}. In order to run `embedded-ldap`, the ${branding} must be started.
 
 === External Links for the Embedded LDAP
@@ -260,11 +260,11 @@ Download https://backstage.forgerock.com/downloads/OpenDJ/OpenDJ%20Enterprise/2.
 
 === Using the Admin Tools
 
-The admin tools are located in `<opendj-installation>/bat` for Windows and `<opendj-installation>/bin` for `*nix`.
+The admin tools are located in `<opendj-installation>/bat` for Windows and `<opendj-installation>/bin` for `*nix`. 
 These tools can be used to administer both local and remote LDAP servers by setting the *host* and *port* parameters appropriately.
 
 
-In this example, the user *Bruce Banner (uid=bbanner)* is disabled using the *manage-account* command on Windows.
+In this example, the user *Bruce Banner (uid=bbanner)* is disabled using the *manage-account* command on Windows.
 Run *manage-account --help* for usage instructions.
 
 .Example Commands for Disabling/Enabling a User's Account
@@ -329,7 +329,7 @@ Account Is Disabled:  false
 ----
 
 
-Notice `Account Is Disabled: false` in the listing.
+Notice `Account Is Disabled: false` in the listing.
 
 .Verifying an Account is Enabled
 ----

distribution/docs/src/main/resources/content/_architectures/_securityFramework/subject.adoc

@@ -12,7 +12,7 @@
 The ((Subject)) is the key object in the security framework.
 Most of the workflow and implementations revolve around creating and using a Subject.
 The Subject object in ${branding} is a class that encapsulates all information about the user performing the current operation.
-The Subject can also be used to perform permission checks to see if the calling user has acceptable permission to perform a certain action (for example, calling a service or returning a metacard).
+The Subject can also be used to perform permission checks to see if the calling user has acceptable permission to perform a certain action (e.g., calling a service or returning a metacard).
 This class was made ${branding}-specific because the Shiro interface cannot be added to the Query Request property map.
 
 .Implementations of Subject:

distribution/docs/src/main/resources/content/_architectures/_transformers/tika-input-xformer.adoc

@@ -7,7 +7,7 @@
 
 The ((Tika Input Transformer)) is the default input transformer responsible for translating Microsoft Word, Microsoft Excel, Microsoft PowerPoint, OpenOffice Writer, and PDF documents into Catalog records.
 This input transformer utilizes https://tika.apache.org[Apache Tika] to provide basic support for these mime types.
-The metadata common to all these document types, such as creation date, author, last modified date, etc., is extracted and used to create the catalog record.
+The metadata common to all these document types, e.g., creation date, author, last modified date, etc., is extracted and used to create the catalog record.
 The Tika Input Transformer's main purpose is to ingest these types of content into the Metadata Catalog.
 
 The Tika input transformer is most basic input transformer and the last to be invoked.

distribution/docs/src/main/resources/content/_developing/_devComponents/custom-action-components.adoc

@@ -44,7 +44,7 @@ The following is a sample taxonomy:
 |Naming Convention
 
 |`catalog.data.metacard.view`
-|Provides a valid URL to view a metacard. Format of data is not specified, so the representation can be in XML, JSON, or other.
+|Provides a valid URL to view a metacard. Format of data is not specified; i.e. the representation can be in XML, JSON, or other.
 |Export as ...
 
 |`catalog.data.metacard.thumbnail`

distribution/docs/src/main/resources/content/_developing/_devComponents/custom-applications.adoc

@@ -93,7 +93,7 @@ An example of this is a properties file for the JDBC connection properties of a
 It is recommended that:
 
 * Any `data/configuration` files be placed under the `src/main/resources` directory of the maven project.
-Sub-directories under `src/main/resources` can be used, for example, `etc/security`.
+Sub-directories under `src/main/resources` can be used, e.g., `etc/security`.
 * The Maven project's pom file should be updated to attach each `data/configuration` file as an artifact (using the `build-helper-maven-plugin`).
 * Add each `data/configuration` file to the KAR file using the `<configfile>` tag in the KAR's `features.xml` file.
 
@@ -168,6 +168,6 @@ An example of this would be a properties file for the JDBC connection properties
 It is recommended that:
 
 * Any data/configuration files be placed under the `src/main/resources` directory of the maven project.
-(Sub-directories under `src/main/resources` can also be used, for example, `etc/security`)
+(Sub-directories under `src/main/resources` can also be used, e.g., `etc/security`)
 * The maven project's pom file should be updated to attach each data/configuration file as an artifact (using the `build-helper-maven-plugin`)
 * Add each data/configuration file to the KAR file by using the `<configfile>` tag in the KAR's `features.xml` file

distribution/docs/src/main/resources/content/_developing/_devComponents/custom-resource-readers.adoc

@@ -60,7 +60,7 @@ The `Map<String, Serializable> arguments` parameter is passed in to support any
 
 === Implement `retrieveResource()`
 
-. Define supported schemes (such as file, http, etc.).
+. Define supported schemes (e.g., file, http, etc.).
 . Check if the incoming URI matches a supported scheme. If it does not, throw `ResourceNotSupportedException`.
 
 .Example:

distribution/docs/src/main/resources/content/_developing/_devComponents/default-attribute-values.adoc

@@ -38,16 +38,16 @@ The value corresponding to the `attribute` key is the name of the attribute to w
 
 [NOTE]
 ====
-The attribute's default value must be of the same type as the attribute, but it has to be written as a string (enclosed in quotation marks) in the JSON file.
+The attribute's default value must be of the same type as the attribute, but it has to be written as a string (i.e., enclosed in quotation marks) in the JSON file.
 
-Dates must be UTC datetimes in the ISO 8601 format, `yyyy-MM-ddTHH:mm:ssZ`
+Dates must be UTC datetimes in the ISO 8601 format, i.e., `yyyy-MM-ddTHH:mm:ssZ`
 ====
 
 The `metacardTypes` key is optional. If it is left out, then the default attribute value will be applied to every metacard that has that attribute. It can be thought of as a 'global' default value. If the `metacardTypes` key is included, then its value must be a list of strings where each string is the name of a metacard type. In this case, the default attribute value will be applied only to metacards that match one of the types given in the list.
 
 [NOTE]
 ====
-In the event that an attribute has a 'global' default value as well as a default value for a specific metacard type, the default value for the specific metacard type will be applied (the more specific default value wins).
+In the event that an attribute has a 'global' default value as well as a default value for a specific metacard type, the default value for the specific metacard type will be applied (i.e., the more specific default value wins).
 ====
 
 Example:

distribution/docs/src/main/resources/content/_developing/_devComponents/global-attribute-validators.adoc

@@ -46,7 +46,7 @@ Each object in the list of validators is the validator name and list of argument
 
 [WARNING]
 ====
-The value of the `arguments` key must always be an array of strings, even for numeric arguments, for example, `["1", "10"]`
+The value of the `arguments` key must always be an array of strings, even for numeric arguments, e.g. `["1", "10"]`
 
 ====
 

distribution/docs/src/main/resources/content/_integrating/_endpoints/opensearch-endpoint.adoc

@@ -163,7 +163,7 @@ default: `5000`
 |`polygon`
 |`polygon`
 |Comma-delimited list of lat/lon (`EPSG:4326 (WGS84)` decimal degrees) pairs, in clockwise order around the polygon, where the last point is the same as the first in order to close the polygon.
-(for example, `-80,-170,0,-170,80,-170,80,170,0,170,-80,170,-80,-170`)
+(e.g. `-80,-170,0,-170,80,-170,80,170,0,170,-80,170,-80,-170`)
 |According to the OpenSearch Geo Specification this is *deprecated*. Use the `geometry` parameter instead.
 
 |`box`
@@ -242,12 +242,12 @@ default: `300000` (5 minutes)
 
 |`type`
 |`type`
-|Any valid datatype (such as `Text`)
+|Any valid datatype (e.g. `Text`)
 |Specifies the type of data to search for.
 
 |`version`
 |`version`
-|Comma-delimited list of strings (such as 20,30)
+|Comma-delimited list of strings (e.g. 20,30)
 |Version values for which to search.
 
 |===

distribution/docs/src/main/resources/content/_integrating/_eventing/subscriptions.adoc

@@ -67,10 +67,10 @@ The Standard Event Processor is an implementation of the Event Processor and pro
 Events are generated by the ${ddf-catalog}Framework as metacards are created/updated/deleted and the Standard Event Processor is called since it is also a Post-Ingest Plugin.
 The Standard Event Processor checks each event against each subscription's criteria.
 
-When an event matches a subscription's criteria, the Standard Event Processor invokes:
+When an event matches a subscription's criteria the Standard Event Processor:
 
-* each pre-delivery plugin on the metacard in the event.
-* the `DeliveryMethod` operation corresponding to the type of event being processed, such as the `created()` operation for the creation of a metacard.
+* invokes each pre-delivery plugin on the metacard in the event.
+* invokes the `DeliveryMethod` operation corresponding to the type of event being processed, e.g., `created()` operation for the creation of a metacard.
 
 .Available Event Processor
 * <<{architecture-prefix}event_processor,Standard Event Processor>>

distribution/docs/src/main/resources/content/_introduction/_coreConcepts/resources-intro.adoc

@@ -7,13 +7,13 @@
 
 == {title}
 
-The Catalog Framework can interface with storage providers to provide storage of resources to specific types of storage, such as file system, relational database, XML database.
+The Catalog Framework can interface with storage providers to provide storage of resources to specific types of storage, e.g., file system, relational database, XML database.
 A default file system implementation is provided by default.
 
-Storage providers act as a proxy between the Catalog Framework and the mechanism storing the content.
-Storage providers expose the storage mechanism to the Catalog Framework.
+Storage providers act as a proxy between the Catalog Framework and the mechanism storing the content.
+Storage providers expose the storage mechanism to the Catalog Framework.
 Storage plugins provide pluggable functionality that can be executed either immediately before or immediately after content has been stored or updated.
 
-Storage providers provide the capability to the Catalog Framework to create, read, update, and delete resources in the content repository.
+Storage providers provide the capability to the Catalog Framework to create, read, update, and delete resources in the content repository.
 
 See <<{managing-prefix}data_management,Data Management>> for more information on specific file types supported by ${branding}.