more link/punctuation/title fixes

Signed-off-by: Andrew Jandacek <[email protected]>

docs/extend/extend-apiml/custom-metadata.md

@@ -7,7 +7,7 @@ Additional metadata can be added to the instance information that is registered
     When this parameter is set to `true`, the Gateway allows encoded characters to be part of URL requests redirected through the Gateway. The default setting of `false` is the recommended setting. Change this setting to `true` only if you expect certain encoded characters in your application's requests.
 
     :::info Important
-    When the expected encoded character is an encoded slash or backslash (`%2F`, `%5C`), make sure the Gateway is also configured to allow encoded slashes. For  more information, see [Installing the Zowe runtime on z/OS](../../user-guide/install-zos.md).
+    When the expected encoded character is an encoded slash or backslash (`%2F`, `%5C`), make sure the Gateway is also configured to allow encoded slashes. For  more information, see [Zowe runtime](../../user-guide/install-zos.md#zowe-runtime) in Zowe server-side installation overview.
     :::
 
     :::note
@@ -53,7 +53,7 @@ Additional metadata can be added to the instance information that is registered
 * **customMetadata.apiml.corsEnabled**
 
     When this parameter is set to `true`, CORS handling by the Gateway is enabled on the service level for all service routes. 
-    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Cors configuration](../../user-guide/api-mediation/configuration-cors.md).
+    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md).
     Additional information can be found in this article about [Cross-Origin Resource Sharing (CORS)](https://developer.mozilla.org/en-US/docs/Web/HTTP/CORS).
 
     :::note
@@ -63,7 +63,7 @@ Additional metadata can be added to the instance information that is registered
 
 * **customMetadata.apiml.gatewayAuthEndpoint**
 
-  Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md)
+  Specifies the Gateway authentication endpoint used by the ZAAS Client configuration. The default value is `/api/v1/gateway/auth`. For more information about ZAAS Client, see [ZAAS Client](zaas-client.md).
 
   :::note
   If you use the Spring enabler, use the following parameter name:
@@ -88,7 +88,7 @@ Additional metadata can be added to the instance information that is registered
   `apiml.service.customMetadata.apiml.corsAllowedOrigins`
   :::
 
-    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [CORS configuration](../../user-guide/api-mediation/configuration-cors.md).
+    For more information, refer to enabling CORS with Custom Metadata on the Gateway: [Customizing Cross-Origin Resource Sharing (CORS)](../../user-guide/api-mediation/configuration-cors.md).
 
  * **customMetadata.apiml.lb.type**
 
@@ -111,7 +111,7 @@ Additional metadata can be added to the instance information that is registered
 
       This value applies the Authentication load balancing schema. This is a sticky session functionality based on the ID of the user. The user ID is understood from the Zowe SSO token on the client's request. Requests without the token are routed in a round robin fashion. The user is first routed in a round robin fashion, and then the routed instance Id is cached. The instance information is used for subsequent requests to route the client to the cached target service instance. This session's default expiration time is 8 hours. After the session expires, the process initiates again.
 
-      In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributed load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache).
+      In default configuration, this cache is stored on each Gateway instance. You can choose to distribute this cache between the Gateway's instances. To do so, follow the steps described in [Distributing the load balancer cache](../../user-guide/api-mediation/configuration-distributed-load-balancer-cache).
 * **customMetadata.apiml.lb.cacheRecordExpirationTimeInHours**  
 
    When the property `customMetadata.apiml.lb.type` is set to `authentication`, the user can also define the expiration time for the selected instance information that is cached. This property aims to prevent any discrepancy which might occur if the required target server is no longer available. The default value is 8 hours.   

docs/extend/extend-apiml/onboard-micronaut-enabler.md

@@ -287,4 +287,4 @@ Create a `logback.xml` file in the `resources` folder and include the `applicati
 
 ## Validate successful registration
 
-After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by teh Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers.
+After you complete the configuration, ensure that your application is visible within Zowe API ML. For more information, see the article [validating the discoverability of your API service by the Discovery Service](onboard-spring-boot-enabler.md#validating-the-discoverability-of-your-api-service-by-the-discovery-service), which describes the validation procedure common for all enablers.

docs/extend/extend-apiml/onboard-plain-java-enabler.md

@@ -818,7 +818,7 @@ public class ApiDiscoveryListener implements ServletContextListener {
 Once you are able to build and start your service successfully, you can use the option of validating that your service is registered correctly with the API ML Discovery Service.
 
 **Follow these steps:**
-  1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml)
+  1. [Validate successful onboarding](./onboard-overview.md#verify-successful-onboarding-to-the-api-ml).
  
   2. Check that you can access your API service endpoints through the Gateway.
 

docs/extend/extend-apiml/onboard-spring-boot-enabler.md

@@ -314,7 +314,7 @@ A property notation provided in the format `-Dproperty.key=PROPERTY_VALUE` can b
 in any of the YAML configuration files.
 
 ### Authentication properties
-These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md/#authentication-parameters) for more details.
+These parameters are not required. If a parameter is not specified, a default value is used. See [Authentication Parameters for Onboarding REST API Services](./authentication-for-apiml-services.md#authentication-parameters) for more details.
 
 ### API ML Onboarding Configuration Sample
 
@@ -440,7 +440,7 @@ logging:
 ### SAF Keyring configuration
 
 You can choose to use a SAF keyring instead of keystore and truststore for storing certificates.
-For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md/#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
+For information about required certificates, see [Zowe API ML TLS requirements](./zowe-api-mediation-layer-security-overview.md#zowe-api-ml-tls-requirements). For information about running Java on z/OS with a keyring, see [SAF Keyring](./certificate-management-in-zowe-apiml.md). Make sure that the enabler can access and read the keyring. Please refer to documentation of your security system for details.
 
 The following example shows enabler configuration with keyrings: 
 ```

docs/extend/extend-apiml/onboard-static-definition.md

@@ -350,13 +350,13 @@ additionalServiceMetadata:
             This value specifies that a service accepts PassTickets in the Authorization header of the HTTP requests using the basic authentication scheme.
             It is necessary to provide a service APPLID in the `apiml.authentication.applid` parameter.
 
-            **Tip:** For more information, see [Enabling PassTicket creation for API Services that accept PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets).
+            **Tip:** For more information, see [Authentication with PassTickets](authentication-for-apiml-services.md#authentication-with-passtickets).
 
         * **safIdt**
 
             This value specifies that the application recognizes the SAF IDT scheme and fills the `X-SAF-Token` header with the token produced by the Saf IDT provider implementation.
 
-            For more information, see [SAF IDT provider](implement-new-saf-provider.md)
+            For more information, see [Implementing a new SAF IDT provider](implement-new-saf-provider.md).
 
         * **x509**
 

docs/extend/extend-apiml/zowe-api-mediation-layer-security-overview.md

@@ -44,7 +44,7 @@ API ML uses the following authentication methods:
   - The client application passes the access JWT token to the API ML Gateway with subsequent requests for mainframe resources.
   - API ML federates the user identities and calls the requested resource with appropriate mainframe user credentials.
 
-For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md)
+For more information, see the detailed explanation of the [OIDC authentication and Identity Federation](api-mediation-oidc-authentication.md).
 
 ### Zowe API ML services