Revert "Clean up of documentation build (#6620)"

This reverts commit eff790d.

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

@@ -22,7 +22,7 @@ catalog:framework
 |the operation to perform using the Catalog Framework (possible values are CREATE \| UPDATE \| DELETE)
 |===
 
-== Sending Messages to Catalog Framework Endpoint
+===== 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.  

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

@@ -45,20 +45,20 @@ The Catalog Framework then invokes <<{architecture-prefix}catalog_plugins,Catal
 
 The Catalog Framework decouples clients from service implementations and provides integration points for Catalog Plugins and convenience methods for Endpoint developers.
 
-== Catalog API Design
+=== 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 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.
 
-=== Ensuring Compatibility
+==== Ensuring Compatibility
 
 The Catalog API will evolve, but great care is taken to retain backwards compatibility with developed components.
 Compatibility is reflected in version numbers.
 
-=== Catalog Framework Sequence Diagrams
+==== Catalog Framework Sequence Diagrams
 
 Because the Catalog Framework plays a central role to Catalog functionality, it interacts with many different Catalog components.
 To illustrate these relationships, high-level sequence diagrams with notional class names are provided below.
@@ -105,7 +105,7 @@ Note that a `CatalogProvider` must be present for any ingest requests to be succ
 This process is similar for updating catalog entries, with update requests calling the `update(UpdateRequest)` methods on the Endpoint, `CatalogFramework`, and Catalog Provider.
 Similarly, for deletion of catalog entries, the delete requests call the `delete(DeleteRequest)` methods on the `Endpoint`, `CatalogFramework`, and `CatalogProvider`.
 
-==== Error Handling
+===== 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.
@@ -122,7 +122,7 @@ log:set
 ----
 ====
 
-==== Query
+===== Query
 
 .Query Request Data Flow
 [ditaa,query_request,png]
@@ -163,7 +163,7 @@ Optional PreQuery and PostQuery Catalog Plugins may be invoked by the `CatalogFr
 If a `CatalogProvider` is not configured and no other remote Sources are configured, a fault will be 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 name(s) in the query request.
 
-==== Product Caching
+===== 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.
@@ -180,6 +180,6 @@ If the Catalog Framework is unable to retrieve the product, an error message is
 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.
 Otherwise, caching is canceled if the user cancels the product download.
 
-==== Product Download Status
+===== Product Download Status
 
 As part of the caching of products, the Catalog Framework also posts events to the OSGi notification framework. Information includes when the product download started, whether the download is retrying or failed (after the number of retrieval attempts configured for product caching has been exhausted), and when the download completes. These events are retrieved by the Search UI and presented to the user who initiated the download.

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

@@ -27,11 +27,11 @@ Site information about the catalog provider and/or any federated source(s) c
 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
+===== 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.
 
-== Configuring the Standard Catalog Framework
+===== Configuring the Standard Catalog Framework
 
 These are the configurable properties on the Standard Catalog Framework.
 
@@ -150,6 +150,6 @@ See <<{reference-prefix}ddf.catalog.CatalogFrameworkImpl, Catalog Standard Frame
 
 |===
 
-== Known Issues with Standard Catalog Framework
+===== Known Issues with Standard Catalog Framework
 
 None.

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

@@ -35,20 +35,20 @@ The primary form of this metadata is the metacard. 
 A `Metacard` is a container for metadata. 
 `CatalogProviders` accept `Metacards` as input for ingest, and `Sources` search for metadata and return matching `Results` that include `Metacards`.
 
-== Metacards
+=== Metacards
 
 A metacard is a single instance of metadata in the Catalog (an instance of a metacard type) which
 generally contains general information about the resource, such as the title of the resource, the resource's geo-location, the date the resource was created and/or modified, the owner or producer, and/or the security classification. 
 
-=== Metacard Type
+==== Metacard Type
 
 A metacard type indicates the attributes available for a particular metacard.
 It is a model used to define the attributes of a metacard, much like a schema.
 
 A metacard type indicates the attributes available for a particular type of data.
 For example, an image may have different attributes than a PDF document, so each could be defined to have their own metacard type.
 
-==== Default Metacard Type and Attributes
+===== Default Metacard Type and Attributes
 
 Most metacards within the system are created using the default metacard type or a metacard type based on the default type.
 The default metacard type of the system can be programmatically retrieved by calling `ddf.catalog.data.impl.MetacardImpl.BASIC_METACARD`.
@@ -72,7 +72,7 @@ Every <<{introduction-prefix}introduction_to_federation_and_sources,Source>> sho
 Other fields may or may not be applicable, but a unique ID must be returned by a source.
 ====
 
-==== Extensible Metacards
+===== Extensible Metacards
 
 Metacard extensibility is achieved by creating a new `MetacardType` that supports attributes in addition to the required attributes listed above.
 
@@ -98,7 +98,7 @@ All `Metacards` must return a `MetacardType` object that includes an `Attri
 
 New `MetacardType` implementations can be made by implementing the `MetacardType` interface.
 
-=== Metacard Type Registry
+==== Metacard Type Registry
 
 [WARNING]
 ====
@@ -138,17 +138,17 @@ Typically, new `MetacardTypes` will be registered by `CatalogProviders` or sourc
 Typically, Endpoints or `InputTransformers` will 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.
 
-=== Attributes
+==== Attributes
 
 An attribute is a single field of a metacard, an instance of an attribute type.
 Attributes are typically indexed for searching by a source or catalog provider.
 
-==== Attribute Types
+===== Attribute Types
 
 An attribute type indicates the attribute format of the value stored as an attribute. 
 It is a model for an attribute.
 
-===== Attribute Format
+====== Attribute Format
 
 An enumeration of attribute formats are available in the catalog.
 Only these attribute formats may be used.
@@ -197,13 +197,13 @@ Only these attribute formats may be used.
 
 |===
 
-===== Attribute Naming Conventions
+====== Attribute Naming Conventions
 
 Catalog taxonomy elements follow the naming convention of `group-or-namespace.specific-term`, except for extension fields outside of the core taxonomy.
 These follow the naming convention of `ext.group-or-namespace.specific-term` and must be namespaced.
 Nesting is not permitted.
 
-==== Result
+===== Result
 
 A single "hit" included in a query response.
 
@@ -213,13 +213,13 @@ A result object consists of the following:
 * a relevance score if included.
 * distance in meters if included.
 
-=== Creating Metacards
+==== Creating Metacards
 
 The quickest way to create a `Metacard` is to extend or construct the `MetacardImpl` object. 
 `MetacardImpl` is the most commonly used and extended `Metacard` implementation in the system because it provides a convenient way for developers to retrieve and set `Attributes` without having to create a new `MetacardType` (see below).
 `MetacardImpl` uses `BASIC_METACARD` as its `MetacardType`.  
 
-==== Limitations
+===== Limitations
 
 A given developer does not have all the information necessary to programmatically interact with any arbitrary source. 
 Developers hoping to query custom fields from extensible `Metacards` of other sources cannot easily accomplish that task with the current API.
@@ -230,11 +230,11 @@ The only exception to this limitation is the `Metacard.ID` field, which is req
 A developer can always request `Metacards` from a source for which that developer has the `Metacard.ID` value. 
 The developer could also perform a wildcard search on the `Metacard.ID` field if the source allows.
 
-==== Processing Metacards
+===== Processing Metacards
 
 As `Metacard` objects are created, updated, and read throughout the Catalog, care should be taken by all catalog components to interrogate the `MetacardType` to ensure that additional `Attributes` are processed accordingly.
 
-==== Basic Types
+===== Basic Types
 
 The Catalog includes definitions of several basic types all found in the `ddf.catalog.data.BasicTypes` class.
 

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

@@ -38,7 +38,7 @@ Notably, the Catalog allows event evaluation on both the previous value (if avai
 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
+=== Eventing Components
 
 The key components of ${branding} Eventing include:
 

distribution/docs/src/main/resources/content/_architectures/_plugins/_plugin-template.adoc

@@ -7,11 +7,11 @@
 
 {description}
 
-== Related Components to {plugin-name}
+===== Related Components to {plugin-name}
 
 Replace this sentence with links to any related components, required or optional, that affect the operation of this plugin.
 
-== Installing the {plugin-name}
+===== Installing the {plugin-name}
 
 The {plugin-name} {is || is not} installed by default with a standard installation in the ${app-name} application.
 
@@ -25,11 +25,11 @@ To install the {plugin-name} from the ${admin-console}:
 . Select the *Configuration* tab.
 . Select the *{plugin-name}*.
 
-== Configuring the {plugin-name}
+===== Configuring the {plugin-name}
 
 {configuration}
 
-== Usage Limitations of the {plugin-name}
+===== Usage Limitations of the {plugin-name}
 
 Delete header if none.
 

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

@@ -13,11 +13,11 @@ The Catalog Backup Plugin is used to enable data backup of the catalog and the m
 Using this plugin may impact performance negatively.
 ====
 
-== Installing the Catalog Backup Plugin
+===== Installing the Catalog Backup Plugin
 
 The Catalog Backup Plugin is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Catalog Backup Plugin
+===== Configuring the Catalog Backup Plugin
 
 To configure the Catalog Backup Plugin:
 
@@ -28,7 +28,7 @@ To configure the Catalog Backup Plugin:
 
 See <<{reference-prefix}ddf.catalog.backup.CatalogBackupPlugin,Catalog Backup Plugin configurations>> for all possible configurations.
 
-== Usage Limitations of the Catalog Backup Plugin
+===== Usage Limitations of the Catalog Backup Plugin
 
 * May affect performance.
 * Must be installed prior to ingesting any content.

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

@@ -7,11 +7,11 @@
 
 The Catalog Policy Plugin configures the attributes required for users to perform Create, Read, Update, and Delete operations on the catalog.
 
-== Installing the Catalog Policy Plugin
+===== Installing the Catalog Policy Plugin
 
 The Catalog Policy Plugin is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Catalog Policy Plugin
+===== Configuring the Catalog Policy Plugin
 
 To configure the Catalog Policy Plugin:
 

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

@@ -7,10 +7,10 @@
 
 The Checksum plugin creates a unique checksum for resources input into the system to identify updated content.
 
-== Installing the Checksum Plugin
+===== Installing the Checksum Plugin
 
 The Checksum is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Checksum Plugin
+===== Configuring the Checksum Plugin
 
 The Checksum Plugin has no configurable properties.

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

@@ -7,15 +7,15 @@
 
 The client info plugin injects request-specific network information into request properties, such as Remote IP Address, Remote Host Name, Servlet Scheme, and Servlet Context.
 
-== Related Components to the Client Info Plugin
+===== Related Components to the Client Info Plugin
 
 * Client info filter
 * <<{architecture-prefix}metacard_ingest_network_plugin,Metacard Ingest Network Plugin>>
 
-== Installing the Client Info Plugin
+===== Installing the Client Info Plugin
 
 The Client Info Plugin is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Client Info Plugin
+===== Configuring the Client Info Plugin
 
 The Client Info Plugin has no configurable properties.

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

@@ -7,10 +7,10 @@
 
 The Content URI Access Plugin prevents a Metacard's resource URI from being overridden by an incoming UpdateRequest.
 
-== Installing the Content URI Access Plugin
+===== Installing the Content URI Access Plugin
 
 The Content URI Access Plugin is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Content URI Access Plugin
+===== Configuring the Content URI Access Plugin
 
 The Content URI Access Plugin has no configurable properties.

distribution/docs/src/main/resources/content/_architectures/_plugins/event-processor.adoc

@@ -13,15 +13,15 @@ The Event Processor applies the filter criteria for each registered subscription
 
 For more information on creating subscriptions, see <<{integrating-prefix}creating_a_subscription,Creating a Subscription>>.
 
-== Installing the Event Processor
+===== Installing the Event Processor
 
 The Event Processor is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Event Processor
+===== Configuring the Event Processor
 
 The Event Processor has no configurable properties.
 
-== Usage Limitations of the Event Processor
+===== Usage Limitations of the Event Processor
 
 The Standard Event processor currently broadcasts federated events and should not.
 It should only broadcast events that were generated locally, all other events should be dropped.

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

@@ -7,7 +7,7 @@
 
 The Expiration Date plugin adds or updates expiration dates which can be used later for archiving old data.
 
-== Installing the Expiration Date Pre-Ingest Plugin
+===== Installing the Expiration Date Pre-Ingest Plugin
 
 The Expiration Date Pre-Ingest Plugin is not installed by default with a standard installation.
 To install:
@@ -17,7 +17,7 @@ To install:
 . Select the *Configuration* tab.
 . Select the *Expiration Data Pre-Ingest Plugin*.
 
-== Configuring the Expiration Date Pre-Ingest Plugin
+===== Configuring the Expiration Date Pre-Ingest Plugin
 
 To configure the Expiration Date Pre-Ingest Plugin:
 

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

@@ -62,10 +62,10 @@ Each of these user (or subject) claims will be converted to a `KeyValuePermissio
 These permission objects will be 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
+===== Installing the Filter Plugin
 
 The Filter Plugin is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Filter Plugin
+===== Configuring the Filter Plugin
 
 The Filter Plugin has no configurable properties.

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

@@ -15,11 +15,11 @@ The GeoCoder relies on either the WebService or <<{reference-prefix}offline_gaze
 For a polygon or polygons, this plugin takes the center point of the bounding box to assign the country code.
 ====
 
-== Installing the GeoCoder Plugin
+===== Installing the GeoCoder Plugin
 
 The GeoCoder Plugin is installed by default with the ${ddf-spatial} application, when the WebService or Offline Gazetteer is started.
 
-== Configuring the GeoCoder Plugin
+===== Configuring the GeoCoder Plugin
 
 To configure the GeoCoder Plugin:
 

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

@@ -7,10 +7,10 @@
 
 The Historian Policy Plugin protects metacard history from being edited or deleted by users without the history role (a `http://schemas.xmlsoap.org/ws/2005/05/identity/claims/role` of `system-history`).
 
-== Installing the Historian Policy Plugin
+===== Installing the Historian Policy Plugin
 
 The Historian is installed by default with a standard installation in the ${ddf-catalog} application.
 
-== Configuring the Historian Policy Plugin
+===== Configuring the Historian Policy Plugin
 
 The Historian Policy Plugin has no configurable properties.