codice · ricklarsen · Oct 14, 2021 · Sep 14, 2021
@@ -5,7 +5,7 @@
 :order: 05
 :summary: Introduction to the Action Framework.
 
-The Action Framework was designed as a way to limit dependencies between applications (apps) in a system.
+The ((Action Framework)) was designed as a way to limit dependencies between applications (apps) in a system.
 For instance, a feature in an app, such as an Atom feed generator, might want to include an external link as part of its feed's entries.
 That feature does not have to be coupled to a REST endpoint to work, nor does it have to depend on a specific implementation to get a link.
 In reality, the feature does not identify how the link is generated, but it does identify whether the link works or does not work when retrieving the intended entry's metadata.
@@ -17,6 +17,6 @@ The Action Framework consists of two major Java interfaces in its API:
 . `ddf.action.Action`
 . `ddf.action.ActionProvider`
 
-Actions:: Specific tasks that can be performed as services.
+((Actions)):: Specific tasks that can be performed as services.
 
-Action Providers:: Lists of related actions that a service is capable of performing.
+((Action Providers)):: Lists of related actions that a service is capable of performing.
@@ -7,10 +7,10 @@
 :summary: Action Providers.
 
 .[[_included_action_providers]]Included Action Providers
-Download Resource ActionProvider:: Downloads a resource to the local product cache.
-IdP Logout Action Provider:: Identity Provider Logout.
-Karaf Logout Action:: Local Logout.
-LDAP Logout Action:: Ldap Logout.
-Overlay ActionProvider:: Provides a metacard URL that transforms the metacard into a geographically aligned image (suitable for overlaying on a map).
-View Metacard ActionProvider:: Provides a URL to a metacard.
-Metacard Transformer ActionProvider:: Provides a URL to a metacard that has been transformed into a specified format.
+((Download Resource ActionProvider)):: Downloads a resource to the local product cache.
+((IdP Logout Action Provider)):: Identity Provider Logout.
+((Karaf Logout Action)):: Local Logout.
+((LDAP Logout Action)):: Ldap Logout.
+((Overlay ActionProvider)):: Provides a metacard URL that transforms the metacard into a geographically aligned image (suitable for overlaying on a map).
+((View Metacard ActionProvider)):: Provides a URL to a metacard.
+((Metacard Transformer ActionProvider)):: Provides a URL to a metacard that has been transformed into a specified format.
@@ -10,7 +10,7 @@
 This code is experimental. While this interface is functional and tested, it may change or be removed in a future version of the library.
 ====
 
-The *Asynchronous Processing Framework* is a way to run plugins asynchronously. Generally, plugins that take a significant amount of processing time and whose
+The ((Asynchronous Processing Framework)) is a way to run plugins asynchronously. Generally, plugins that take a significant amount of processing time and whose
 results are not immediately required are good candidates for being asynchronously processed. A *Processing Framework* can either be run on the local or
 remote system. Once the *Processing Framework* finishes processing incoming requests, it may submit ``(Create|Update|Delete)Request``s to the Catalog. The type of plugins that a *Processing Framework*
 runs are the *Post-Process Plugins*. The *Post-Process Plugins* are triggered by the *Processing Post Ingest Plugin*, which is a *Post-Ingest Plugin*. *Post-Ingest Plugins* are run after the metacard

@@ -6,15 +6,15 @@
 
 ==== Catalog API
 
-The Catalog API is an OSGi bundle (`catalog-core-api`) that contains the Java interfaces for the Catalog components and implementation classes for the Catalog Framework, Operations, and Data components.
+The ((Catalog API)) is an OSGi bundle (`catalog-core-api`) that contains the Java interfaces for the Catalog components and implementation classes for the Catalog Framework, Operations, and Data components.
 
 ===== Catalog API Search Interfaces
 
 The Catalog API includes two different search interfaces.
 
 ${ddf-ui} Application Search Interface:: The ${branding} Search UI application provides a graphic interface to return results and locate them on an interactive globe or map.
 
-SSH Search Interface:: Additionally, it is possible to use a client script to remotely access ${branding} via SSH and send console commands to search and ingest data.
+((SSH Search Interface)):: Additionally, it is possible to use a client script to remotely access ${branding} via SSH and send console commands to search and ingest data.
 
 ===== Catalog Search Result Objects
 

@@ -1,11 +1,11 @@
 :title: Catalog Framework Camel Component
 :type: catalogFramework
 :status: published
-:summary: Supports creating, updating, and deleting metacards using the Catalog Framework from a Camel route.
+:summary: Supports creating, updating, and deleting metacards using the Catalog Framework from a Camel route.
 :link: _catalog_framework_camel_component
 :order: 01
 
-The Catalog Framework Camel Component supports creating, updating, and deleting metacards using the Catalog Framework from a Camel route.
+The ((Catalog Framework Camel Component)) supports creating, updating, and deleting metacards using the Catalog Framework from a Camel route.
 
 .URI Format
 ----
@@ -25,12 +25,12 @@ catalog:framework
 == Sending Messages to Catalog Framework Endpoint
 
 .Catalog Framework Producer
-In Producer mode, the component provides the ability to supply different inputs and have the Catalog Framework perform different operations based upon the header values.  
+In Producer mode, the component provides the ability to supply different inputs and have the Catalog Framework perform different operations based upon the header values.
 
-For the CREATE and UPDATE operation, the message body can contain a list of metacards or a single metacard object. 
+For the CREATE and UPDATE operation, the message body can contain a list of metacards or a single metacard object.
 
 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 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.

@@ -30,6 +30,7 @@
 +------------------------------------------------------------+
 ....
 
+(((Catalog Framework)))
 The `CatalogFramework` is the routing mechanism between catalog components that provides integration points for the Catalog Plugins.
 An <<{integrating-prefix}endpoints, endpoint>> invokes the active Catalog Framework, which calls any configured <<{architecture-prefix}pre_query_plugins, Pre-query>> or <<{architecture-prefix}pre_ingest_plugins, Pre-ingest plug-ins>>.
 The selected <<{managing-prefix}federation_strategy, federation strategy>> calls the active <<{managing-prefix}catalog_providers, Catalog Provider>> and any connected or federated sources.
@@ -48,7 +49,7 @@ The Catalog Framework decouples clients from service implementations and provi
 == Catalog API Design
 
 The Catalog is composed of several components and an API that connects them together.
-The Catalog API is central to ${branding}'s architectural qualities of extensibility and flexibility. 
+The ((Catalog API)) is central to ${branding}'s architectural qualities of extensibility and flexibility. 
 The Catalog API consists of Java interfaces that define Catalog functionality and specify interactions between components. 
 These interfaces provide the ability for components to interact without a dependency on a particular underlying implementation, thus allowing the possibility of alternate implementations that can maintain interoperability and share developed components.
 As such, new capabilities can be developed independently, in a modular fashion, using the Catalog API interfaces and reused by other ${branding} installations.

@@ -1,35 +1,35 @@
 :title: Standard Catalog Framework
 :type: catalogFramework
 :status: published
-:summary: Reference implementation of a Catalog Framework that implements all requirements of the ${ddf-catalog} API.
+:summary: Reference implementation of a Catalog Framework that implements all requirements of the ${ddf-catalog} API.
 :link: _standard_catalog_framework
 :order: 00
 
-The Standard Catalog Framework provides the reference implementation of a Catalog Framework that implements all requirements of the ${ddf-catalog} API. 
-`CatalogFrameworkImpl` is the implementation of the ${branding} Standard Catalog Framework.
+The ((Standard Catalog Framework)) provides the reference implementation of a Catalog Framework that implements all requirements of the ${ddf-catalog} API.
+`CatalogFrameworkImpl` is the implementation of the ${branding} Standard Catalog Framework.
 
-The Standard Catalog Framework is the core class of ${branding}.
-It provides the methods for create, update, delete, and resource retrieval (CRUD) operations on the `Sources`.
-By contrast, the Fanout Catalog Framework only allows for query and resource retrieval operations, no catalog modifications, and all queries are enterprise-wide.
+The Standard Catalog Framework is the core class of ${branding}.
+It provides the methods for create, update, delete, and resource retrieval (CRUD) operations on the `Sources`.
+By contrast, the Fanout Catalog Framework only allows for query and resource retrieval operations, no catalog modifications, and all queries are enterprise-wide.
 
 Use this framework if:
 
 * access to a catalog provider is required to create, update, and delete catalog entries.
 * queries to specific sites are required.
 * queries to only the local provider are required.
 
-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.
+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 (i.e., protocol, such as `file://`) in the URI of the resource specified in the request to be retrieved.
+The Standard Catalog Framework also maintains a list of `ResourceReaders` for resource retrieval operations.
+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 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 (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
 
-The Standard Catalog Framework is bundled as the `catalog-core-standardframework` feature and can be installed and uninstalled using the normal processes described in Configuration.
+The Standard Catalog Framework is bundled as the `catalog-core-standardframework` feature and can be installed and uninstalled using the normal processes described in Configuration.
 
 == Configuring the Standard Catalog Framework
 
@@ -141,11 +141,11 @@ See <<{reference-prefix}ddf.catalog.CatalogFrameworkImpl, Catalog Standard Frame
 |true
 
 |ddf.cache.CacheManager
-| 
+|
 |false
 
 |org.osgi.service.event.EventAdmin
-| 
+|
 |false
 
 |===