Merge pull request #86 from ericherman/typo-fixups-20240613T144857Z

Typo fix-ups

.github/workflows/pages.yml

@@ -32,7 +32,7 @@ jobs:
         uses: actions/checkout@v3
       - name: Setup Pages
         uses: actions/configure-pages@v2
-      - name: Install Biksehed
+      - name: Install Bikeshed
         run: pip3 install bikeshed && bikeshed update
       - name: Build specs
         run: make -C spec publish && make -C spec/v2 publish && make -C spec/faq publish

DECISION-MAKING-PROCESS.md

@@ -37,10 +37,10 @@ Architecture decisions and changes to the technical specification are submitted
 
 ## Propagating Accepted ADR changes to Technical Specification
 - Content from Accepted ADRs will be incorporated in the applicable Technical Specification as below -
-    - If the PR for the ADR **did not already include** proposed changes to the Technical Spectification ([see above](#on-providing-feedback-and-participating-in-the-development-of-the technical-specifications) and was merged into `main` branch -  then a new PR needs to be submitted with the respective changes. Otherwise if the PR was not merged into the `main` branch, please Commit the respective changes in the same PR. <br/><br/>
-    > **_NOTE:_** The PR for Technical Specificaiton related changes only, will be reviewed and merged (if accepted) into `main` branch by the PACT Team
+    - If the PR for the ADR **did not already include** proposed changes to the Technical Specification ([see above](#on-providing-feedback-and-participating-in-the-development-of-the technical-specifications) and was merged into `main` branch -  then a new PR needs to be submitted with the respective changes. Otherwise if the PR was not merged into the `main` branch, please Commit the respective changes in the same PR. <br/><br/>
+    > **_NOTE:_** The PR for Technical Specification related changes only, will be reviewed and merged (if accepted) into `main` branch by the PACT Team
 
-    - If the PR for the ADR **already included** the proposed changes to the Technical Spectification, then no additonal PR is needed and the changes will be merged in `main` branch
+    - If the PR for the ADR **already included** the proposed changes to the Technical Specification, then no additional PR is needed and the changes will be merged in `main` branch
 
 
 

RELEASE-INSTRUCTIONS.md

@@ -2,7 +2,7 @@
 
 Follow the instructions below to trigger a release of the Technical Specifications.
 
-> To trigger a release, you need to have sufficient permissions on the `wbcsd` GitHub organiztion, as well as on this (`wbcsd/data-exchange-protocol`) repositiory and in the target repository [`wbcsd/tr`](https://github.com/wbcsd/tr).
+> To trigger a release, you need to have sufficient permissions on the `wbcsd` GitHub organization, as well as on this (`wbcsd/data-exchange-protocol`) repository and in the target repository [`wbcsd/tr`](https://github.com/wbcsd/tr).
 
 > You also need to have the GitHub CLI tool locally installed and be logged in to GitHub from your local terminal. See https://cli.github.com/ for further information.
 

decisions/log/0012-request-response-patterns.md

@@ -1,4 +1,4 @@
-# 12. Request-Reponse Pattern Variants for wbcsd PACT
+# 12. Request-Response Pattern Variants for wbcsd PACT
 
 Date: 2022-11-22
 

decisions/log/0014-request-response-patterns.md

@@ -1,4 +1,4 @@
-# 14. Event-based communication between Host Systmes (Push based)
+# 14. Event-based communication between Host Systems (Push based)
 
 Date: 2022-10-31
 
@@ -25,7 +25,7 @@ Accepted
 1. Addition of an HTTP endpoint to exchange different kinds of Events between Host Systems
 2. Specification of an Event and a Request/Response flow to notify downstream Customers on PF updates
     - Operating on top of the Events endpoint (Item #1)
-3. Specification of Events and a Request/Response flow for requesting PF data from Supplier which was not available ealrier
+3. Specification of Events and a Request/Response flow for requesting PF data from Supplier which was not available earlier
     - Operating on top of the Events endpoint (Item #1)
 4. Usage of JSON Event Data model from CloudEvents[^1] to encode aforementioned Events
    1. Usage of `Structured Content Mode` [^3] when exchanging events over HTTP
@@ -195,7 +195,7 @@ The response event in case 0 or more ProductFootprints requested are ready:
 
 If the host system has no ProductFootprints matching the request, it MUST still send a response event `pfs` set to the empty array.
 
-If the host system of the original requestor (the data recipient) is not available or does not accept the response with a HTTP success code (2xx), the host system MUST retry sending the response event to the host system referenced in `source` of the original request event using expoenential backoff. 
+If the host system of the original requestor (the data recipient) is not available or does not accept the response with a HTTP success code (2xx), the host system MUST retry sending the response event to the host system referenced in `source` of the original request event using exponential backoff.
 
 A host system MUST NOT retry sending the response event for more than 3 days.
 
@@ -237,4 +237,4 @@ The response event MUST be sent to the `sink` URI specified in the request event
 [^2]: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/formats/json-format.md
 [^3]: https://github.com/cloudevents/spec/blob/v1.0.2/cloudevents/bindings/http-protocol-binding.md#32-structured-content-mode
 [^4]: https://wbcsd.github.io/data-exchange-protocol/v2/#api-error-responses
-[^5]: https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md#324-filters
+[^5]: https://github.com/cloudevents/spec/blob/main/subscriptions/spec.md#324-filters

decisions/log/0017-life-cycle-status-property-additional-rules.md

@@ -12,7 +12,7 @@ Context of this ADR Is the technical specification V1.0.0[^1]. It is lacking det
 
 1. Acceptable changes to an existing ProductFootprint that constitute a new version of the ProductFootprint
 2. Changes that require a new ProductFootprint to be created while the previous is being deprecated.
-3. Communication of the status of an existing ProductFootprint if it is invalid / redacted or superseeded by other ProductFootprint(s)
+3. Communication of the status of an existing ProductFootprint if it is invalid / redacted or superseded by other ProductFootprint(s)
 
 ## Decision
 
@@ -31,4 +31,4 @@ The following changes to the tech spec Bikeshed file[^2] shall be made
 
 
 [^1]: https://www.carbon-transparency.com/media/1qcdbdyn/pathfinder-network_technical-specifications-for-use-case-001.pdf
-[^2]: [spec/index.bs](../../spec/index.bs)
+[^2]: [spec/index.bs](../../spec/index.bs)

decisions/log/0019-increment-pcf-endpoints-version.md

@@ -7,7 +7,7 @@ In Progress
 
 ## Context
 
-In order to accomodate the changes to Use Case 001 Tech Spec v1 to v2, there is a need to increment the prefix of the PCF HTTP Endpoints to /2 (from /0)
+In order to accommodate the changes to Use Case 001 Tech Spec v1 to v2, there is a need to increment the prefix of the PCF HTTP Endpoints to /2 (from /0)
 
 
 ## Decision

decisions/log/0021-openid-base-auth.md

@@ -21,7 +21,7 @@ We propose to extend the Authentication flow for the V2 tech specs. This updated
 
 If successful, a data recipient authenticates through this endpoint instead of the “regular”`Authenticate` endpoint and its static path / URL.
 
-Otherwise, the authentication flow remains the same and a data recipent attempts to retrieve its token through the regular `Authenticate` Action.
+Otherwise, the authentication flow remains the same and a data recipient attempts to retrieve its token through the regular `Authenticate` Action.
 
 This way, a backwards-compatible authentication flow is established.
 

decisions/log/0026-async-request-by-default.md

@@ -15,7 +15,7 @@ Furthermore managing the access rights upfront for `ListFootprints` requests are
 The seconds synchronous request is `GetFootprint` which uses PF IDs to select the requested PCF. But _PF IDs_ are a detail which is usually unknown to the data requester (customer). Data requesters usually only know _Material Identifiers_ (e.g. catalog number, part number).
 Product specific requests would in addition enable data providers (suppliers) to prioritize the calculation of PCF when these are not available yet.
 
-The specification[^1] already adresses all this by supporting `PF Request Events and Responses`. But this feature is _optional_ at the moment whereas synchronous communication mechanisms (as `ListFootprints` or `GetFootprint`) are defined as _mandatory_. This complicates or even block integration of existing PCF exchange apps as those apps usually work in an asynchrounous and productId focused way.
+The specification[^1] already addresses all this by supporting `PF Request Events and Responses`. But this feature is _optional_ at the moment whereas synchronous communication mechanisms (as `ListFootprints` or `GetFootprint`) are defined as _mandatory_. This complicates or even block integration of existing PCF exchange apps as those apps usually work in an asynchronous and productId focused way.
 
 Other exchange networks like Catena-X also use this asynchronous/material approach. With the current specification the PACT API requires the user to handle two APIs with different logic.
 
@@ -39,7 +39,7 @@ The following changes to the tech spec Bikeshed file[^1] shall be made:
         ]
      }
     ```
-4. Add an example of an asynchrounous PF request / repsonse flow to the `Examples` section:
+4. Add an example of an asynchronous PF request / response flow to the `Examples` section:
 
    Example PF Request Event
 

decisions/log/0027-footprint-fragment.md

@@ -15,7 +15,7 @@ The "Asynchronous request and retrieval of Product Footprints" (section 6.8.4) a
 The 'request' event includes a so called 'ProductFootprintFragment' that is defined as:
 * *"A JSON object which references a subset of ProductFootprint properties, including nested properties."*
 
-The 'ProductFootprintFragment' is intended to enable the data recipient (sending the request) to specify what it is looking for (which data) and share that with the data owner (receiving the request). However, the current definition of the 'ProductFootprintFragment' is very open and that might negatively addect the chances on an successful exchange.
+The 'ProductFootprintFragment' is intended to enable the data recipient (sending the request) to specify what it is looking for (which data) and share that with the data owner (receiving the request). However, the current definition of the 'ProductFootprintFragment' is very open and that might negatively effect the chances of a successful exchange.
 * For example, one could - theoretically - make a request for PFs with ["fossilGhgEmission": "1.9"].
 
 It is questionable whether data owners are able and willing to process such a wide variety of scenarios. Hence, the definition needs to be refined to properly support the use case of requesting and retrieving footprints in an asynchronous manner. In short, the 'ProductFootprintFragment' should be refined in such a way that:

decisions/log/0028-provide-clarity-on-characterization-factors.md

@@ -45,7 +45,7 @@ This proposal aims at providing a forward-looking change on characterization fac
 
 Backwards-compatibility is preserved by keeping the `characterizationFactors` property (despite its becoming deprecated).
 
-It is forward-looking because future adaptations are unlikely to break backwards-compatibility. If a more fine-grained account of characterization factors use is ever desired, it can be included through optional properties of `CharacterizationFactorsSource`. If ever other sources become relevant (e.g., for specific industries) this too can be acommodated without the need for a breaking change.
+It is forward-looking because future adaptations are unlikely to break backwards-compatibility. If a more fine-grained account of characterization factors use is ever desired, it can be included through optional properties of `CharacterizationFactorsSource`. If ever other sources become relevant (e.g., for specific industries) this too can be accommodated without the need for a breaking change.
 
 ## Consequences
 

decisions/log/README.md

@@ -16,8 +16,8 @@ This folder and underlying principles is adr-inspired.
 * [11. Capitalization of "specVersion" field](0011-specversion-capitalization.md)
 * [12. Request response Patterns](0012-request-response-patterns.md)
 * [13. Use of Bikeshed for technical specifications](0013-use-bikeshed.md)
-* [14. Event-based communication between Host Systmes (Push based)](0014-request-response-patterns.md)
+* [14. Event-based communication between Host Systems (Push based)](0014-request-response-patterns.md)
 * [15. Pagination (Pull) for handling high Data Volume](0015-pagination.md)
 * [16. Additional support for vendor and product codes (nee Company and Product Ids)](0016-product-ids.md)
 * [17. Life Cycle status property and additional Life Cycle rules](0017-life-cycle-status-property-additional-rules.md)
-* [20. Define expected ListFootprints action behavior when multiple versions of a footprint exist](0020-define-expected-list-footprints-action-behavior-when-multiple-versions-of-a-footprint-exist.md)
+* [20. Define expected ListFootprints action behavior when multiple versions of a footprint exist](0020-define-expected-list-footprints-action-behavior-when-multiple-versions-of-a-footprint-exist.md)

spec/faq/index.bs

@@ -23,7 +23,7 @@ It is recommended that if an Organization hasn't implemented a Solution yet base
 
 <strong>Q: Which Version of the PACT Technical Specification Version should an Organization register for its Conformance Testing / Connectathon participation?</strong>
 
-It depends on the aim of the Organization for participating in a Conformance Testing / Connectathon cycle. If the Organzation's aim is to test its Solution for Conformance with a peer, then it should register with the Version of the PACT Technical Specification for which that peer has implemented its Solution. If the aim of the Organization is to provide a voluntary support for Conformance Testing another Organization's Solution, then they can register with the Version of the PACT Technical Specification for which it's testing peer is doing Conformance Testing (provided the Organization has a Solution implemented based on that particular PACT Technical Specification Version).
+It depends on the aim of the Organization for participating in a Conformance Testing / Connectathon cycle. If the Organization's aim is to test its Solution for Conformance with a peer, then it should register with the Version of the PACT Technical Specification for which that peer has implemented its Solution. If the aim of the Organization is to provide a voluntary support for Conformance Testing another Organization's Solution, then they can register with the Version of the PACT Technical Specification for which it's testing peer is doing Conformance Testing (provided the Organization has a Solution implemented based on that particular PACT Technical Specification Version).
 
 ## Version 2.1.0 ## {#faqs-2.1.0}
 <strong>Q: What are the changes / updates included in Version 2.1.0? </strong>
@@ -51,7 +51,7 @@ without impacting Data Recipients.
 
 <strong>Q: Are these updates backwards-compatible? </strong>
 Yes these are backwards-compatible updates to the Authentication flow. The way this backward compatibility is achieved is via the flexibility for a Data Recipient
-to retreive the token through the `AuthSubPath/auth/token` endpoint or via the token_endpoint url returned in the OpenId Provider Configuration Document.
+to retrieve the token through the `AuthSubPath/auth/token` endpoint or via the token_endpoint url returned in the OpenId Provider Configuration Document.
 
 <strong>Q: If an Organization's Solution is PACT Conformant (to V 1.0.x or V 2.0.x), do they need to update it to incorporate the V 2.1.0 changes? </strong>
 

spec/index.bs

@@ -968,7 +968,7 @@ The following section briefly describes some of the additional functionality whi
 
 ### Establishing data exchange flows between Host Systems ### {#api-data-exchange}
 
-Issue: add section on data exchange between host systems, detailling the information needed for establishing host system-to-host system data exchange, URL examples
+Issue: add section on data exchange between host systems, detailing the information needed for establishing host system-to-host system data exchange, URL examples
 
 
 ### A note on data synchronization between Host Systems ### {#api-host-system-sync}
@@ -1001,7 +1001,7 @@ This is implemented by
 2. the host system issuing an access token as specified in [[!rfc6749]] Section 4.4.3 and Section 5.1
 3. the [=data recipient=] calling one or more Actions of the host system
     - using the value of `access_token` of the response of the [=Action Authenticate=] call as the value for a [[!rfc6750]] <dfn>Bearer token</dfn>
-    - presenting the Bearer token for subsequent call(s) to the host system in accordancew ith [[!rfc6750]] Section 2.1
+    - presenting the Bearer token for subsequent call(s) to the host system in accordance with [[!rfc6750]] Section 2.1
 
 [=Access tokens=] SHOULD expire. In this case, data recipients MUST retrieve a new [=access token=] as described in this section.
 
@@ -1256,7 +1256,7 @@ A <dfn>error response</dfn> is a JSON object with the following properties:
 
 A <dfn>error response code</dfn> is a value from column `Error Response Code` from the table below.
 
-A <dfn>error message</dfn> is a human-readible error description. Example values are in column `Example Message` in the table below.
+A <dfn>error message</dfn> is a human-readable error description. Example values are in column `Example Message` in the table below.
 
 <div class=example>
 Example [=AccessDenied=] [=error response=]:

spec/v2/index.bs

@@ -2589,7 +2589,7 @@ Summary of changes:
 2. addition of a new <{CarbonFootprint/ipccCharacterizationFactorsSources}> property
 3. updates to Action [=Action Events=] implementation requirement - changed from OPTIONAL to MANDATORY
 4. addition of an Example for a ProductFootprintFragment indicating a query for a PCF via productId
-5. addition of Examples of a PCF request and repsonse Action Event flow
+5. addition of Examples of a PCF request and response Action Event flow
 
 ## Version 2.1.0 (Dec 07, 2023) ## {#changelog-2.1.0}
 
@@ -2621,7 +2621,7 @@ Summary of changes:
 Summary of changes:
 
 1. clarification to specification of property <{CarbonFootprint/fossilGhgEmissions}>, <{CarbonFootprint/pCfExcludingBiogenic}>, <{CarbonFootprint/pCfIncludingBiogenic}>, and <{CarbonFootprint/biogenicCarbonWithdrawal}>
-2. in addition, further clarfication on the bounds of the property <{CarbonFootprint/biogenicCarbonWithdrawal}> which must be equal to `0` or less than `0`
+2. in addition, further clarification on the bounds of the property <{CarbonFootprint/biogenicCarbonWithdrawal}> which must be equal to `0` or less than `0`
 
 
 ## Version 2.0.1-20230629 (Jun 29, 2023) ## {#changelog-2.0.1-20230629}