microprofile-health-35 Provide different types of health check

Typos and rewording

Signed-off-by: Antoine Sabot-Durand <antoine@sabot-durand.net>

Author: antoinesd

spec/src/main/asciidoc/java-api.adoc

@@ -34,7 +34,7 @@ public interface HealthCheck {
 
 Applications provide health check procedures (implementation of a `HealthCheck`), which will be used by the runtime hosting the application to verify the healthiness of the computing node.
 
-== Different kind of Health Checks
+== Different kinds of Health Checks
 
 This specification provides different kind of health check procedures.
 Difference between them is only semantic.
@@ -45,24 +45,25 @@ The nature of the procedure is defined by annotating the `HealthCheck` procedure
 * Custom checks defined with `@Health` annotation
 
 
-An `HealthCheck` procedures with none of the above annotations is not an active procedure and should be ignored.
+A `HealthCheck` procedures with none of the above annotations is not an active procedure and should be ignored.
 
 === Readiness check
 
 A Health Check for readiness allows third party services to know if the application is ready to process request or not.
 
-The `@Readiness` annotation must be applied on an `HealthCheck` implementation to define a readiness check procedure.
+The `@Readiness` annotation must be applied on a `HealthCheck` implementation to define a readiness check procedure.
 
 === Liveness check
 
-A Health Check for liveness allows third party services to know if the application is alive and able to process request or not.
+A Health Check for liveness allows third party services to determine if the application is running.
+This means that if this procedure fails the application can be discarded (terminated, shutdown).
 
-The `@Liveness` annotation must be applied on an `HealthCheck` implementation to define a Liveness check procedure.
+The `@Liveness` annotation must be applied on a `HealthCheck` implementation to define a Liveness check procedure.
 
 
 === Custom check
 
-To provide backward compatibility with previous specification version, an `HealthCheck` implementation with `@Health` annotation is still supported.
+To provide backward compatibility with previous specification version, a `HealthCheck` implementation with `@Health` annotation is still supported.
 
 Semantic of such a health check procedure is let to the implementor and therefor is defined as "custom".
 
@@ -92,9 +93,9 @@ public abstract class HealthCheckResponse {
 The status of all `HealthCheck` 's determines the overall status for the given Health check kind.
 
 
-== Combining multiple kind of checks
+== Combining multiple kinds of checks
 
-An `HealthCheck` implementation may be annotated with multiple kind of check.
+A `HealthCheck` implementation may be annotated with multiple kinds of checks.
 The procedure will be used to resolve every kind of health check for which it is annotated.
 
 For instance this procedure will be used to resolve liveness and readiness health check.
@@ -161,7 +162,7 @@ public class MyCheck implements HealthCheck {
 }
 ```
 
-Health check procedures are CDI bean, therefore, they can also be defined with CDI producers:
+Health check procedures are CDI beans, therefore, they can also be defined with CDI producers:
 
 
 ```

spec/src/main/asciidoc/overview.adoc

@@ -27,18 +27,18 @@ https://kubernetes.io/docs/tasks/configure-pod-container/configure-liveness-read
 
 In this scenario health checks are used to determine if a computing node needs to be discarded (terminated, shutdown) and eventually replaced by another (healthy) instance.
 
-The MP-HC architecture consists of two `/health/ready` and `/health/live` endpoints in a MicroProfile runtime that respectively represents the readiness and the liveness of the entire runtime.
+The MP-HC architecture consists of two `/health/ready` and `/health/live` endpoints in a MicroProfile runtime that respectively represent the readiness and the liveness of the entire runtime.
 For backward compatibility, a 3rd endpoint `/health` can also be used to provide a custom Health Check.
 These endpoints are expected to be associated with a configurable context, such as a web application deployment, that can be configured with settings such as port, virtual-host, security, etc.
 Further, the MP-HC defines the notion of a procedure that represents the health of a particular
 subcomponent of an application.
 
 In an application, there can be zero or more procedures bound to a given health endpoint.
-The overall application health for a given endpoint is the logical AND of all of the procedure bound to it.
+The overall application health for a given endpoint is the logical AND of all of the procedures bound to it.
 
 The current version of the MP-HC specification does not define how the `/health/live` endpoint may be partitioned in the event
 that the MicroProfile runtime supports deployment of multiple applications. If an implementation wishes to
-support multiple applications within a MicroProfile runtime, the semantics of the `/health/live` and `/health/ready` endpoints are
+support multiple applications within a MicroProfile runtime, the semantics of individual endpoints are
 expected to be the logical AND of all the application in the runtime. The exact details of this are deferred to
 a future version of the MP-HC specification.