Fix typo

Signed-off-by: Aaron Ai <yangkun.ayk@gmail.com>

cesql/README.md

@@ -1,3 +1,3 @@
 # CloudEvents SQL Expression Language - Version 0.1-wip
 
-See the [CESQL specfication](spec.md).
+See the [CESQL specification](spec.md).

cloudevents/README.md

@@ -1,3 +1,3 @@
 # CloudEvents - Version 1.0.3-wip
 
-See the [CloudEvents specfication](spec.md).
+See the [CloudEvents specification](spec.md).

cloudevents/formats/protobuf-format.md

@@ -163,7 +163,7 @@ A compliant protobuf batch representation is identifed using the following media
 
 ## 6. Examples
 
-The following code-snippets show how proto representations might be constucted
+The following code-snippets show how proto representations might be constructed
 assuming the availability of some convenience methods.
 
 ### 6.1 Plain Text event data

cloudevents/primer.md

@@ -498,7 +498,7 @@ There might exist special cases in which it is necessary to create a CloudEvent
 that contains another CloudEvent. Although the specification does not define
 nesting explicitly, it is possible. When doing so, the inner event will always
 use [structured mode](spec.md#event-format), this is because if the inner event
-was in binary mode then its metadata could be misinterpretted as metadata for
+was in binary mode then its metadata could be misinterpreted as metadata for
 the outer event. The outer event can use either binary or structured mode,
 however, its `datacontenttype` attribute must not be set to
 `application/cloudevents+json` or any other media type that is used to denote
@@ -526,7 +526,7 @@ ce-source: example.com
 
 Note that by doing so the receiver can no longer know the inner event is
 a CloudEvent by examination of the `Content-Type` HTTP header. If this is a
-concern then using structured mode for the outer event might be preferrable.
+concern then using structured mode for the outer event might be preferable.
 
 ## Qualifying Protocols and Encodings
 

cloudevents/working-drafts/xml-format.md

@@ -339,7 +339,7 @@ non-normative example.
                 <PmtMtd>TRF</PmtMtd>
                 <BtchBookg>false</BtchBookg>
 
-            <!-- Content ommited for brevity -->
+            <!-- Content omitted for brevity -->
 
             </PmtInf>
         </Document>

discovery/README.md

@@ -1,3 +1,3 @@
 # Discovery Service - Version 0.3-wip
 
-See the [Discovery specfication](spec.md).
+See the [Discovery specification](spec.md).

discovery/primer.md

@@ -32,7 +32,7 @@ need to understand the business logic of the event itself. Often, this
 is needed to help properly route the message to the next hop in the event's
 journey to its final recipient.
 
-With that specification reaching verson 1.0 status, the project members then
+With that specification reaching version 1.0 status, the project members then
 considered what additional pain-points might need to be addressed in this
 space. And, it seemed only natural that once there was some standardization
 around the format of the events, that the group's attention should be to help
@@ -77,7 +77,7 @@ insight into the team's focus during the development cycle.
   allow for the consumer to subscribe only to those producers since those are
   the only events that the consumer is interested in, or can support.
 
-- Consumer wants to know which event delivery mechansims a producer can support.
+- Consumer wants to know which event delivery mechanisms a producer can support.
   This will allow them to pick a transport that best suits their needs. For
   example, a push vs pull delivery model.
 
@@ -119,7 +119,7 @@ insight into the team's focus during the development cycle.
 Per the Discovery API specification, the Service's `id` is a globally
 unique identifier for the Service. By ensuring that this value is immutable,
 clients will be able to know when a Service is returned from the
-Discovery Enpoints whether it is the same underlying Service as was returned
+Discovery Endpoints whether it is the same underlying Service as was returned
 in a previous query despite any changes to its metadata - even if all of the
 metadata has changed (except, of course, for the `id`). This includes the
 cases where the same Service is returned from multiple Discovery Endpoints.

discovery/spec.md

@@ -202,7 +202,7 @@ properties defined:
 An Endpoint is a network accessible location that is capable of receiving or
 sending messages.
 
-The following pseudo JSON shows the defintion of an Endpoint:
+The following pseudo JSON shows the definition of an Endpoint:
 ```
 {
     "id": "URI-reference",
@@ -245,7 +245,7 @@ See [Common Resource Properties](#common-resource-properties).
   - effective<br>
     An OPTIONAL property indicating the time when the Endpoint entered, or will
     enter, a deprecated state. The date MAY be in the past or future. If this
-    propety is not present the Endpoint is already in a deprecated state.
+    property is not present the Endpoint is already in a deprecated state.
     If present, this MUST be an [RFC3339][rfc3339] timestamp.
 
   - removal<br>
@@ -408,7 +408,7 @@ See [Common Resource Properties](#common-resource-properties).
 
 ### Definition Resource
 
-A Definition is describes the format a message that can be transfered to or
+A Definition is describes the format a message that can be transferred to or
 from an Endpoint. Each message is assumed to be made up of two parts:
 - Metadata - OPTIONAL information used to annotate or provide additional
   information about the purpose or content of the message
@@ -423,7 +423,7 @@ A Definition allows for the inclusion of metadata to aid with the discovery of:
 - the type, value, description and requirements of those properties
 - where those properties will appear in the message
 
-The following pseudo JSON shows the defintion of a Definition:
+The following pseudo JSON shows the definition of a Definition:
 ```
 {
     "id": "URI-reference",
@@ -642,7 +642,7 @@ MUST be used. The format for the `filter` query parameter MUST be:
 Nested attribute names MUST be specified by using a dot (`.`) as the nesting
 operator. For example: `config.protocol` references the `protocol` attribute
 under the top-level `config` attribute. If a property is a collection then
-specifiying that property implies that all items in the collection will be
+specifying that property implies that all items in the collection will be
 searched and only the ones that match the remaining part of the filter
 criteria will be returned.
 
@@ -668,7 +668,7 @@ The following rules constrain the filter processing:
   part of its value.
 - Matching of attribute names MUST be case sensitive.
 - Matching of attribute values MUST be case insensitive.
-- If there are mulitple filter expressions, they MUST be specified as separate
+- If there are multiple filter expressions, they MUST be specified as separate
   `filter` query parameters. When there are multiple filters, the resulting
   set of resources MUST only include ones that match all of the filters
   specified. When multiple nested attribute names are used, each nested

docs/SDK-GOVERNANCE.md

@@ -6,7 +6,7 @@ The community is organized as follows:
 
 - Every SDK has its own
   [Github Team](https://github.com/orgs/cloudevents/teams), for example
-  `sdk-go-maintainers` is the group of mantainers for
+  `sdk-go-maintainers` is the group of maintainers for
   [cloudevents/sdk-go project](https://github.com/cloudevents/sdk-go)
 - The union of all the `sdk-*-maintainers` assembles the _sdk maintainers_ group
 
@@ -94,8 +94,8 @@ We define an SDK project _healthy_ if:
 
 We define a project `cloudevents/sdk-x` _not actively maintained_ if:
 
-6. Issues and/or PRs are not being triaged from `sdk-x-mantainers` for 2 months
-7. Security patches are not being **released** from `sdk-x-mantainers` for 1
+6. Issues and/or PRs are not being triaged from `sdk-x-maintainers` for 2 months
+7. Security patches are not being **released** from `sdk-x-maintainers` for 1
    months from CVE disclosures
 
 It may happen that there has been no necessary activity within the SDK for at

pagination/README.md

@@ -1,3 +1,3 @@
 # Pagination - Version 0.1-wip
 
-See the [Pagination specfication](spec.md).
+See the [Pagination specification](spec.md).

registry/README.md

@@ -1,3 +1,3 @@
 # Registry Service - Version 0.3-wip
 
-See the [Registry Service specfication](spec.md).
+See the [Registry Service specification](spec.md).

registry/spec.md

@@ -665,7 +665,7 @@ Registry-epoch: STRING
 Registry-self: STRING            # URL to the specific version
 Registry-RESOURCEURI: URI ?      # If present body MUST be empty
 Content-Location: URL            # Same as Registry-self value
-Location: URL                    # If 307. Same a Regsitry-RESOURCEURI
+Location: URL                    # If 307. Same a Registry-RESOURCEURI
 
 { ...Resource entity... } ?
 ```
@@ -715,8 +715,8 @@ TODO
 #### Updating a Resource
 
 This will update the latest version of a Resource. Missing Registry HTTP
-headers MUST NOT be interpretted as deleting the property. However, a Regsitry
-HTTP headers with an empty string for its value MUST be interpretted as a
+headers MUST NOT be interpreted as deleting the property. However, a Registry
+HTTP headers with an empty string for its value MUST be interpreted as a
 request to delete the property.
 
 The request MUST be of the form:
@@ -999,7 +999,7 @@ Registry-epoch: STRING
 Registry-self: STRING            # URL to the specific version
 Registry-RESOURCEURI: URI ?      # If present body MUST be empty
 Content-Location: URL            # Same as Registry-self value
-Location: URL                    # If 307. Same a Regsitry-RESOURCEURI
+Location: URL                    # If 307. Same a Registry-RESOURCEURI
 
 { ...Resource entity... } ?
 ```
@@ -1047,8 +1047,8 @@ TODO
 #### Updating a version of a Resource
 
 This will update a particular version of a Resource. Missing Registry HTTP
-headers MUST NOT be interpretted as deleting the property. However, a Regsitry
-HTTP headers with an empty string for its value MUST be interpretted as a
+headers MUST NOT be interpreted as deleting the property. However, a Registry
+HTTP headers with an empty string for its value MUST be interpreted as a
 request to delete the property.
 
 The request MUST be of the form:

schemaregistry/README.md

@@ -1,3 +1,3 @@
 # CloudEvents Schema Registry API Version 0.2-wip
 
-See the [Schema Registry specfication](spec.md).
+See the [Schema Registry specification](spec.md).

subscriptions/README.md

@@ -1,3 +1,3 @@
 # CloudEvents Subscriptions API - Version 0.1-wip
 
-See the [Subscriptions specfication](spec.md).
+See the [Subscriptions specification](spec.md).