docs: fix spelling and format table in Markdown files

docs/actions-new.md

@@ -110,7 +110,7 @@ is an example starting point to fork and modify for your new runtime.
 
 The standard test action is shown below in JavaScript. It should be adapted for the
 new language and added to the [test artifacts directory](../tests/dat/actions/unicode.tests)
-with the name `<runtime-kind>.txt` for plain text file or `<runtime-kind>.bin` for a
+with the name `<runtime-kind>.txt` for plain text file or `<runtime-kind>.bin` for
 a binary file. The `<runtime-kind>` must match the value used for `kind` in the corresponding
 runtime manifest entry, replacing `:` in the kind with a `-`.
 For example, a plain text function for `nodejs:20` becomes `nodejs-20.txt`.
@@ -289,4 +289,4 @@ There are now several runtimes that support execution environments in addition t
 
 #### Action Proxy Single Entrypoint Interface
 
-Single entrypoint proxies are proxies that have only onde addressable http endpoint. They do not use `/init` and `/run` enpoints utilized by standard OpenWhisk runtime environments; instead both the initialization and activation are handled through one endpoint. The first example of such a proxy was implemented for Knative Serving, but the same interface can be used for any single entrypoint execution environment. In an effort to standardize how the various action proxy implementation containers are able to handle single entrypoint execution environments (such as Knative Serving), there is a description of the contract and example cases outlining how a container should respond with a given input. The descriptions and example cases are documented in [Single Entrypoint Proxy Contract](single_entrypoint_proxy_contract.md).
+Single entrypoint proxies are proxies that have only one addressable HTTP endpoint. They do not use `/init` and `/run` endpoints utilized by standard OpenWhisk runtime environments; instead both the initialization and activation are handled through one endpoint. The first example of such a proxy was implemented for Knative Serving, but the same interface can be used for any single entrypoint execution environment. In an effort to standardize how the various action proxy implementation containers are able to handle single entrypoint execution environments (such as Knative Serving), there is a description of the contract and example cases outlining how a container should respond with a given input. The descriptions and example cases are documented in [Single Entrypoint Proxy Contract](single_entrypoint_proxy_contract.md).

docs/actions.md

@@ -353,15 +353,15 @@ Datetime            Activation ID                    Kind      Start Duration
 
 The meaning of the different columns in the list are:
 
-| Column | Description |
-| :--- | :--- |
-| `Datetime` | The date and time when the invocation occurred. |
-| `Activation ID` | An activation ID that can be used to retrive the result using the `wsk activation get`, `wsk activation result` and `wsk activation logs` commands. |
-| `Kind` | The runtime or action type |
-| `Start` | An indication of the latency, i.e. if the runtime container was cold or warm started. |
-| `Duration` | Time taken to execute the invocation. |
-| `Status` | The outcome of the invocation. For an explanation of the various statuses, see the description of the `statusCode` below. |
-| `Entity` | The fully qualified name of entity that was invoked. |
+| Column          | Description                                                                                                                                          |
+|:----------------|:-----------------------------------------------------------------------------------------------------------------------------------------------------|
+| `Datetime`      | The date and time when the invocation occurred.                                                                                                      |
+| `Activation ID` | An activation ID that can be used to retrieve the result using the `wsk activation get`, `wsk activation result` and `wsk activation logs` commands. |
+| `Kind`          | The runtime or action type                                                                                                                           |
+| `Start`         | An indication of the latency, i.e. if the runtime container was cold or warm started.                                                                |
+| `Duration`      | Time taken to execute the invocation.                                                                                                                |
+| `Status`        | The outcome of the invocation. For an explanation of the various statuses, see the description of the `statusCode` below.                            |
+| `Entity`        | The fully qualified name of entity that was invoked.                                                                                                 |
 
 #### Understanding the activation record
 

docs/single_entrypoint_proxy_contract.md

@@ -18,7 +18,7 @@
 -->
 # Action Proxy Single Entrypoint Interface
 
-The typical endpoints used by the OpenWhisk control plane are not used in single entrypoint execution environments such as Knative. Initialization and running are still essential to how OpenWhisk runtimes function, but they are done in a different methodology than `/init` and `/run` endpoints. The proxy that shapes how the calls are preprocessed and postprocessed to emulate some of the functionality provided by the OpenWhisk control plane. In single entrypoint supported runtime proxy implementations, both initailization and running are done via the `/` root endpoint. The sections below explain the interface the runtime proxy must adhere to initialize and run via a single entrypoint execution environment.
+The typical endpoints used by the OpenWhisk control plane are not used in single entrypoint execution environments such as Knative. Initialization and running are still essential to how OpenWhisk runtimes function, but they are done in a different methodology than `/init` and `/run` endpoints. The proxy that shapes how the calls are preprocessed and postprocessed to emulate some of the functionality provided by the OpenWhisk control plane. In single entrypoint supported runtime proxy implementations, both initialization and running are done via the `/` root endpoint. The sections below explain the interface the runtime proxy must adhere to initialize and run via a single entrypoint execution environment.
 
 ## Init
 

docs/use_cases.md

@@ -67,4 +67,4 @@ With the amount of data now available, application development requires the abil
 
 Cognitive technologies can be effectively combined with OpenWhisk to create powerful applications. For example, IBM Alchemy API and Watson Visual Recognition can be used with OpenWhisk to automatically extract useful information from videos without having to actually watch them.
 
-Here is a sample application [Dark vision](https://github.com/IBM-Cloud/openwhisk-darkvisionapp) that does just that. In this application the user uploads a video or image using the Dark Vision web application, which stores it in a Cloudant DB. Once the video is uploaded, OpenWhisk detects the new video by listening to Cloudant changes (trigger). OpenWhisk then triggers the video extractor action. During its execution, the extractor produces frames (images) and stores them in Cloudant. The frames are then processed using Watson Visual Recognition and the results are stored in the same Cloudant DB. The results can be viewed using Dark Vision web application OR an iOS application. Object Storage can be used in addition to Cloudant. When doing so, video and image medadata are stored in Cloudant and the media files are stored in Object Storage.
+Here is a sample application [Dark vision](https://github.com/IBM-Cloud/openwhisk-darkvisionapp) that does just that. In this application the user uploads a video or image using the Dark Vision web application, which stores it in a Cloudant DB. Once the video is uploaded, OpenWhisk detects the new video by listening to Cloudant changes (trigger). OpenWhisk then triggers the video extractor action. During its execution, the extractor produces frames (images) and stores them in Cloudant. The frames are then processed using Watson Visual Recognition and the results are stored in the same Cloudant DB. The results can be viewed using Dark Vision web application OR an iOS application. Object Storage can be used in addition to Cloudant. When doing so, video and image metadata are stored in Cloudant and the media files are stored in Object Storage.