Fix formatting and typos in release notes

Signed-off-by: Mandy Chessell <mandy.e.chessell@gmail.com>
odpi · Jan 24, 2024 · 7380521 · 7380521
1 parent b8cc1ce
commit 7380521
Show file tree

Hide file tree

Showing 15 changed files with 65 additions and 52 deletions.
diff --git a/site/docs/concepts/governance-action-process-intro.md b/site/docs/concepts/governance-action-process-intro.md
@@ -2,7 +2,7 @@
 <!-- Copyright Contributors to the ODPi Egeria project. -->
 
 
-A *governance action process* is a predefined sequence of [engine actions](/concepts/engine-action that are coordinated by the [Governance Engine OMAS](/services/omas/governance-engine/overview).
+A *governance action process* is a predefined sequence of [engine actions](/concepts/engine-action) that are coordinated by the [Governance Engine OMAS](/services/omas/governance-engine/overview).
 
 The steps in a governance action process are defined by linked [governance action process steps](/concepts/governance-action-process-step) stored in the open metadata ecosystem.  Each governance action process step provides the specification of the governance action to run.  The links between them show which [guards](/concepts/guard) cause the next step to be chosen and hence, the governance action to run.
 
@@ -31,20 +31,20 @@ Example 2 shows an [open discovery service](/concepts/open-discovery-service) am
 
 ## Capturing lineage for a governance action process
 
-The [engine actions](/concepts/engine-action generated when a governance action process runs provide a complete audit trace of the governance services that ran and their results.  The [Governance Action Open Lineage Integration Connector](/connectors/integration/governance-action-open-lineage-integration-connector) is able to monitor the operation of the governance actions and produce [OpenLineage events](/features/lineage-management/overview/#the-openlineage-standard) to provide operational lineage for governance action processes.  Egeria is also able to [capture these events](/connectors/#capturing-and-publishing-lineage) (along with OpenLineage events from other technologies) for later analysis.
+The [engine actions](/concepts/engine-action) generated when a governance action process runs provide a complete audit trace of the governance services that ran and their results.  The [Governance Action Open Lineage Integration Connector](/connectors/integration/governance-action-open-lineage-integration-connector) is able to monitor the operation of the governance actions and produce [OpenLineage events](/features/lineage-management/overview/#the-openlineage-standard) to provide operational lineage for governance action processes.  Egeria is also able to [capture these events](/connectors/#capturing-and-publishing-lineage) (along with OpenLineage events from other technologies) for later analysis.
 
 ## Governance Action Process Lifecycle
 
 The diagram below shows a governance action process assembly tool taking in information from a [governance engine pack](/concepts/governance-engine-pack) to build a governance action process flow.  This is shared with the open metadata ecosystem either through direct called to the [Governance Engine OMAS](/services/omas/governance-engone/overview) or via a [open metadata archive](/concepts/open-metadata-archive) (possibly the archive that holds the governance engine definition.
 
-Once the definition of the governance action process is available, an instance of the process can be started, either by a [watchdog governance action service](/concepts/governance-action-service) or through a direct call to the Governance Engine OMAS.  Whichever mechanism is used, it results in the Governance Engine OMAS using the definition to choreograph the creation of [engine action](/concepts/engine-action entities that drive the execution of the governance services in the [Engine Host](/concepts/engine-host).
+Once the definition of the governance action process is available, an instance of the process can be started, either by a [watchdog governance action service](/concepts/governance-action-service) or through a direct call to the Governance Engine OMAS.  Whichever mechanism is used, it results in the Governance Engine OMAS using the definition to choreograph the creation of [engine action](/concepts/engine-action) entities that drive the execution of the governance services in the [Engine Host](/concepts/engine-host).
 
 ![Lifecycle](/concepts/governance-action-process-lifecycle.svg)
 
 
 !!! education "Further information"
     - The [0462 Governance Action Processes](/types/4/0462-Governance-Action-Processes) model shows how the governance action process flow is built out of [governance action process steps](/concepts/governance-action-process-step).
     - Governance action processes may be created using the [Governance Engine OMAS](/services/omas/governance-engine/overview) API.
-    - The [Open Metadata Engine Services (OMES)](/services/omes) provide the mechanisms that support the different types of [governance engines](/concepts/governance-engine). These engines run the [governance services](/concepts/governance-service) that execute the [engine actions](/concepts/engine-action defined by the governance action process.
+    - The [Open Metadata Engine Services (OMES)](/services/omes) provide the mechanisms that support the different types of [governance engines](/concepts/governance-engine). These engines run the [governance services](/concepts/governance-service) that execute the [engine actions](/concepts/engine-action) defined by the governance action process.
 
 
diff --git a/site/docs/concepts/governance-action-type.md b/site/docs/concepts/governance-action-type.md
@@ -4,6 +4,9 @@
 
 # Governance Action Type
 
-Governance Action Type has been renamed to [Governance Action Process Step](/concepts/governance-action-process-step)
+A *Governance Action Type* is a template that describes a call to a [governance engine](/concepts/governance-engine).  Through the [open governance service](/services/gaf-metadata-management), it is possible to use the governance action type to initiate the specified call to the governance engine.  The result is the creation of an [engine action](/concepts/engine-action) that controls the execution of the call.  
+
+!!! education "Properties of a governance action type"
+    The open metadata type definition for the governance action type is in model [0462 Governance Action Processes](/types/4/0462-Governance-Action-Processes).
 
 --8<-- "snippets/abbr.md"
diff --git a/site/docs/concepts/guard.md b/site/docs/concepts/guard.md
@@ -6,7 +6,7 @@
 
 Guards are labels that are created by [governance services](/concepts/governance-service)
 and are used by the [Governance Engine OMAS](/services/omas/governance-engine/overview) to
-determine which [engine action](/concepts/engine-action to run next.
+determine which [engine action](/concepts/engine-action) to run next.
 
 
 --8<-- "snippets/abbr.md"
diff --git a/site/docs/concepts/index.md b/site/docs/concepts/index.md
@@ -156,7 +156,7 @@
 - [Glossary](/practices/common-data-definitions/anatomy-of-a-glossary)
 - [Glossary Category](/practices/common-data-definitions/anatomy-of-a-glossary/#glossary-categories)
 - [Glossary Term](/practices/common-data-definitions/anatomy-of-a-glossary/#inside-a-glossary-term)
-- [Governance Action](/concepts/engine-action)
+- [Governance Action](/concepts/governance-action)
 - [Governance Action Engine](/concepts/governance-action-engine)
 - [Governance Action OMES](/service/omes/governance-action/overview)
 - [Governance Action Framework (GAF)](/frameworks/gaf/overview)

diff --git a/site/docs/features/discovery-and-stewardship/overview.md b/site/docs/features/discovery-and-stewardship/overview.md
@@ -55,7 +55,7 @@ Schema extraction uses the [schema analysis annotation](/types/6/0615-Schema-Ext
 
 ![Open discovery schema extraction](/guides/developer/open-discovery-services/open-discovery-schema-extraction.svg)
 
-The schema of the data in the digital resource is defined in a *SchemaType* linked from the digital resource's asset using the *AssetSchemaType* relationship.  This may be established before the open discovery service runs, or may be derived by an [engine action](/concepts/engine-action once the open discovery service has run.
+The schema of the data in the digital resource is defined in a *SchemaType* linked from the digital resource's asset using the *AssetSchemaType* relationship.  This may be established before the open discovery service runs, or may be derived by an [engine action](/concepts/engine-action) once the open discovery service has run.
 
 If the schema is defined, the open discovery service that creates the data fields may maintain relationships between the schema and the data fields:
 

diff --git a/site/docs/features/lineage-management/overview.md b/site/docs/features/lineage-management/overview.md
@@ -257,7 +257,7 @@ The numbers on the diagram refer to the notes below.
 
 3. The [OpenLineage Event Receiver](/connectors/integration/open-lineage-event-receiver-integration-connector) integration connector is receiving OpenLineage events from the Kafka topic.  It passes them to the Lineage Integrator OMIS's context manager via its own context.
 
-4. The [Governance Action OpenLineage](/connectors/integration/governance-action-open-lineage-integration-connector) integration connector has registered a listener to receive events about the [engine actions](/concepts/engine-action that are being processed in the open metadata ecosystem.  
+4. The [Governance Action OpenLineage](/connectors/integration/governance-action-open-lineage-integration-connector) integration connector has registered a listener to receive events about the [engine actions](/concepts/engine-action) that are being processed in the open metadata ecosystem.  
 
 5. The Governance Action OpenLineage integration connector creates OpenLineage events to represent the processing by the governance actions and passes them to the Lineage Integrator OMIS's context manager via its own context.
 

diff --git a/site/docs/features/synchronized-access-control/overview.md b/site/docs/features/synchronized-access-control/overview.md
@@ -16,7 +16,7 @@ There are many factors that influence who should have access to a digital servic
 
 Egeria enables all of this information to be assembled and linked together at multiple levels - for example a database column may be linked to a glossary term called employee-salary that is in turn classified as sensitive personal information (SPI).
 
-Security managers, such as Apache Ranger, however just needs to know that the column is SPI. So [engine actions](/concepts/engine-action convert this complex model into something much more operationally-focused in the form of *security tags*.  The security tags attached to the schemas are all that needs to be distributed to the security managers.
+Security managers, such as Apache Ranger, however just needs to know that the column is SPI. So [engine actions](/concepts/engine-action) convert this complex model into something much more operationally-focused in the form of *security tags*.  The security tags attached to the schemas are all that needs to be distributed to the security managers.
 
 ## Representing security tags
 

diff --git a/site/docs/guides/admin/servers/configuring-omag-server-basic-properties.md b/site/docs/guides/admin/servers/configuring-omag-server-basic-properties.md
@@ -31,33 +31,35 @@ The server type name should be set to something that describes the OMAG Server's
 
 If you have no specific value to set the server type name to, we recommend that you set the server type name to null.  This will cause the server start up process will derive a standard server type name based on the rest of the configuration for the server.
 
-!!! post "POST - setBasicServerProperties"
-```
-{{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-properties"
-```
-The request body contains the properties to set.
-
-| Property                 | Description                                                                                                                                                                                                                                                                     |
-|--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
-| *localServerDescription* | Description for the server. This is useful information for the administrator to understand the role of the server. The default value is `null`.                                                                                                                                 |
-| *organizationName*       | Descriptive name for the organization that owns the local server/repository. This is useful when the open metadata repository cluster consists of metadata servers from different organizations, or different departments of an enterprise. The default value is `null`.        |
-| *localServerURL*         | The *platformURLRoot* for the platform where this server is to run. For example `https://localhost:9443`.  It is used if the server connects to a [cohort](/concepts/cohort-member).                                                                                            |
-| *localServerUserId*      | UserId to use for server-initiated REST calls. The default is `OMAGServer`.                                                                                                                                                                                                     |
-| *localServerPassword*    | Password to use for server-initiated REST calls. The default is `null`. This means that only the userId is sent in the HTTP header.                                                                                                                                             |
-| *maxPageSize*            | The maximum page size that can be set on requests to the server. The default value is `1000`. A value of zero means unlimited page size. Although supported, the zero value is not recommended because it provides no protection from a large request denial of service attack. |
-
-For example:
-
-```json
-{
-  "localServerDescription" : "This server supports the governance teams",
-  "organizationName" : "Coco Pharmaceuticals",
-  "localServerURL" : "https://localhost:9443",
-  "localServerUserId" : "cocomds2npa",
-  "localServerPassword" : "secret",
-  "maxPageSize" : 600
-}
-```
+???+ post "POST - setBasicServerProperties"
+    ```
+    {{platformURLRoot}}/open-metadata/admin-services/users/{{adminUserId}}/servers/{{serverName}}/server-properties"
+    ```
+    The request body contains the properties to set.
+
+    | Property                 | Description                                                                                                                                                                                                                                                                     |
+    |--------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
+    | *localServerDescription* | Description for the server. This is useful information for the administrator to understand the role of the server. The default value is `null`.                                                                                                                                 |
+    | *organizationName*       | Descriptive name for the organization that owns the local server/repository. This is useful when the open metadata repository cluster consists of metadata servers from different organizations, or different departments of an enterprise. The default value is `null`.        |
+    | *localServerURL*         | The *platformURLRoot* for the platform where this server is to run. For example `https://localhost:9443`.  It is used if the server connects to a [cohort](/concepts/cohort-member).                                                                                            |
+    | *localServerUserId*      | UserId to use for server-initiated REST calls. The default is `OMAGServer`.                                                                                                                                                                                                     |
+    | *localServerPassword*    | Password to use for server-initiated REST calls. The default is `null`. This means that only the userId is sent in the HTTP header.                                                                                                                                             |
+    | *maxPageSize*            | The maximum page size that can be set on requests to the server. The default value is `1000`. A value of zero means unlimited page size. Although supported, the zero value is not recommended because it provides no protection from a large request denial of service attack. |
+
+    For example:
+
+    ```json
+    {
+      "localServerDescription" : "This server supports the governance teams",
+      "organizationName" : "Coco Pharmaceuticals",
+      "localServerURL" : "https://localhost:9443",
+      "localServerUserId" : "cocomds2npa",
+      "localServerPassword" : "secret",
+      "maxPageSize" : 600
+    }
+    ```
+
+Alternatively, you can set these properties one at a time.
 
 ### Set server description
 

diff --git a/site/docs/guides/developer/governance-action-services/overview.md b/site/docs/guides/developer/governance-action-services/overview.md
@@ -106,7 +106,7 @@ The connector provider for your governance action service provides the factory m
 
 Below is the implementation of the connector provider for the [Move Copy File Provisioning Governance Action Service](/connectors/governance-action/move-copy-file-provisioning-governance-action-service).  This is a highly configurable governance action service that can be instructed to move, copy or delete a file, and has different styles of lineage it can create.  The action it performs is supplied in the governance request type.  The source file and destination folder can be supplied either through the request parameters or as action targets.  There are two guards: "provisioning-complete" for success and "provisioning-failed" if something went wrong.
 
-The methods of the connector provider enables a tool that is configuring [engine actions](/concepts/engine-action or [governance action processes](/concepts/governance-action-process) to query the capabilities of the corresponding governance action service.
+The methods of the connector provider enables a tool that is configuring [engine actions](/concepts/engine-action) or [governance action processes](/concepts/governance-action-process) to query the capabilities of the corresponding governance action service.
 
 ```java
 public class MoveCopyFileGovernanceActionProvider extends GovernanceActionServiceProviderBase