Fix #1164: Update legacy serverlessworkflow.io URLs to open-workflow-specification.org

[dgutierr]

Summary

• Update all serverlessworkflow.io domain references to open-workflow-specification.org across 12 files
• Fix pre-existing typos: double https:// prefix and double .io suffix in dsl-reference.md
• Schema $id, standard error type URIs, event source fields, website badge, and community link all updated
• Custom error examples in raise-inline.yaml and raise-reusable.yaml left unchanged (not standard error URIs)

Closes #1164

Test plan

• All updated URLs verified to resolve on the new domain (no 404s)
• schema/workflow.yaml $id points to https://open-workflow-specification.org/schemas/1.0.3/workflow.yaml
• Standard error type URIs in dsl-reference.md table all use new domain
• 0.x schemas and custom error examples are untouched

[Copilot]

Pull request overview

This PR migrates legacy serverlessworkflow.io references to open-workflow-specification.org throughout the spec documentation, schema identifier, and example workflows to align the repository with the new canonical domain.

Changes:

• Updated standard error type URIs and event source fields in spec docs and use-case docs to the new domain.
• Updated example YAML workflows to use the new domain for standard error type URIs and sample event sources.
• Updated the workflow JSON Schema $id and refreshed community/README + main README website link.

Reviewed changes

Copilot reviewed 12 out of 12 changed files in this pull request and generated 4 comments.

Show a summary per file

File	Description
use-cases/managing-github-issues/README.md	Updates emitted event source URIs and standard runtime error type URIs to the new domain.
use-cases/managing-ev-charging-stations/README.md	Updates standard runtime error type URI to the new domain.
schema/workflow.yaml	Updates the schema $id to the new canonical domain.
README.md	Updates the website badge link target to the new domain.
examples/try-catch.yaml	Updates standard communication error type URI to the new domain.
examples/try-catch-then.yaml	Updates standard communication error type URI to the new domain.
examples/try-catch-retry-reusable.yaml	Updates standard communication error type URI to the new domain.
examples/try-catch-retry-inline.yaml	Updates standard communication error type URI to the new domain.
examples/call-asyncapi-subscribe-consume-forever-foreach.yaml	Updates sample event source URI to the new domain.
dsl.md	Updates standard error type URIs referenced in DSL prose to the new domain.
dsl-reference.md	Updates standard error type URIs (and related examples) to the new domain.
community/README.md	Updates community presentations link to the new domain.

Comments suppressed due to low confidence (1)

dsl-reference.md:553

• Same issue as above: the link text is an error type URI, but the hyperlink target points to GitHub instead of the relevant section in this document.

> On success the output of the call is the JSON-RPC result. On failure, runtimes must raise an error with type [https://open-workflow-specification.org/spec/1.0.0/errors/runtime](https://github.com/serverlessworkflow/specification/blob/main/dsl-reference.md#standard-error-types).

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[ricardozanini]

@dgutierr the CI is failing because we need to update it to the new schema ID.

[Copilot]

Pull request overview

Copilot reviewed 12 out of 12 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

schema/workflow.yaml:1

• The schema $id was updated, but the CI schema validator still looks up the workflow schema by the old id ("https://serverlessworkflow.io/schemas/1.0.3/workflow.yaml") in .ci/validation/src/index.ts:27. That will make ajv.getSchema(...) return undefined and cause validation to fail unless the validator’s workflowSchemaId is updated to match this new $id.

$id: https://open-workflow-specification.org/schemas/1.0.3/workflow.yaml

README.md:6

• These badge image URLs use plain HTTP. Switching to HTTPS avoids mixed-content warnings and ensures the README assets are fetched securely.

[<img src="http://img.shields.io/badge/Website-blue?style=flat&logo=google-chrome&logoColor=white">](https://open-workflow-specification.org/) 
[<img src="http://img.shields.io/badge/Slack-4A154B?style=flat&logo=slack&logoColor=white">](https://cloud-native.slack.com/messages/open-workflow) 

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated 1 comment.

Comments suppressed due to low confidence (2)

dsl-reference.md:1231

• The Try example uses a non-standard error type URI path (/dsl/errors/types/communication), but this document’s own “Standard Error Types” section defines communication under /spec/1.0.0/errors/communication. Using the standard URI here avoids conflicting guidance and keeps examples consistent across the spec.

            type: https://open-workflow-specification.org/dsl/errors/types/communication

ctk/features/try.feature:75

• This CTK scenario expects a non-standard error type URI (/dsl/errors/types/communication), while the spec defines the standard communication error type at /spec/1.0.0/errors/communication. Aligning the URI avoids mismatches between the CTK and the specification.

                type: https://open-workflow-specification.org/dsl/errors/types/communication
                status: 503

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (3)

dsl-reference.md:1231

• This Try task example uses an error type URI under /dsl/errors/types/..., but this document’s Standard Error Types (and other examples) use /spec/1.0.0/errors/.... Using the non-standard URI here is inconsistent and may mislead implementers; consider switching to the standard communication error type URI.

            type: https://open-workflow-specification.org/dsl/errors/types/communication

ctk/features/try.feature:31

• The CTK Try Task scenario filters for error type .../dsl/errors/types/communication, but the spec docs in this repo (e.g., dsl.md) define the standard communication error type as .../spec/1.0.0/errors/communication. If a runtime follows the spec, this CTK scenario would not catch the error as intended.

                type: https://open-workflow-specification.org/dsl/errors/types/communication
                status: 404

ctk/features/try.feature:75

• Same issue as above: this scenario filters for .../dsl/errors/types/communication, which appears inconsistent with the spec’s standard error URIs (.../spec/1.0.0/errors/communication). This may cause the scenario to behave incorrectly against compliant runtimes.

                type: https://open-workflow-specification.org/dsl/errors/types/communication
                status: 503

[ricardozanini]

@dgutierr can you please squash and sign your commit with -S?

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

ctk/features/try.feature:30

• This scenario’s error type URI changes path from /dsl/errors/types/communication to /spec/1.0.0/errors/communication, while the second scenario in the same file (line 74) and the Try example in dsl-reference.md use the /dsl/errors/types/communication form. If the intent of this PR is only to update the domain, keep the path consistent to avoid altering CTK expectations.

                type: https://open-workflow-specification.org/spec/1.0.0/errors/communication

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (1)

ctk/features/try.feature:30

• This line changes more than the domain: it switches the error type URI from the prior /dsl/errors/types/communication form to /spec/1.0.0/errors/communication, while the rest of this feature file (and the Try example in dsl-reference.md) still uses /dsl/errors/types/.... Given the PR’s stated goal is only to update legacy domains, this path/version change looks unintended and makes the CTK feature inconsistent.

                type: https://open-workflow-specification.org/spec/1.0.0/errors/communication

[cdavernas]

LGTM! Cheers ❤️

[cdavernas]

@dgutierr Would you be so kind to sign-off your commit with a verified signature?

[dgutierr]

@cdavernas @ricardozanini both done!

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (4)

dsl-reference.md:507

• These Markdown links display a URI as the link text, but the link target is an internal anchor (#standard-error-types). This is misleading because users expect clicking the URI to navigate to that URI. Consider either (a) making the link target the URI itself, or (b) changing the link text to something like runtime / standard error types while keeping the anchor target.

> On success the output is the JSON-RPC result. On failure runtimes must raise an error with type [https://open-workflow-specification.org/spec/1.0.0/errors/runtime](#standard-error-types).

dsl-reference.md:553

• These Markdown links display a URI as the link text, but the link target is an internal anchor (#standard-error-types). This is misleading because users expect clicking the URI to navigate to that URI. Consider either (a) making the link target the URI itself, or (b) changing the link text to something like runtime / standard error types while keeping the anchor target.

> On success the output of the call is the JSON-RPC result. On failure, runtimes must raise an error with type [https://open-workflow-specification.org/spec/1.0.0/errors/runtime](#standard-error-types).

dsl-reference.md:2115

• The table uses (#) as the link target for each error URI, which makes the links effectively non-functional. Since this PR is already touching these rows, consider updating the link targets to the actual URI (or to a relevant local anchor) so the references work in rendered docs.

| [https://open-workflow-specification.org/spec/1.0.0/errors/configuration](#) | `400` | Errors resulting from incorrect or invalid configuration settings, such as missing or misconfigured environment variables, incorrect parameter values, or configuration file errors. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/validation](#) | `400` | Errors arising from validation processes, such as validation of input data, schema validation failures, or validation constraints not being met. These errors indicate that the provided data or configuration does not adhere to the expected format or requirements specified by the workflow. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/expression](#) | `400` | Errors occurring during the evaluation of runtime expressions, such as invalid syntax or unsupported operations. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/authentication](#) | `401` | Errors related to authentication failures. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/authorization](#) | `403` | Errors related to unauthorized access attempts or insufficient permissions to perform certain actions within the workflow. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/timeout](#) | `408` | Errors caused by timeouts during the execution of tasks or during interactions with external services. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/communication](#) | `500` | Errors  encountered while communicating with external services, including network errors, service unavailable, or invalid responses. |
| [https://open-workflow-specification.org/spec/1.0.0/errors/runtime](#) | `500` | Errors occurring during the runtime execution of a workflow, including unexpected exceptions, errors related to resource allocation, or failures in handling workflow tasks. These errors typically occur during the actual execution of workflow components and may require runtime-specific handling and resolution strategies. |

README.md:5

• There appears to be trailing whitespace at the end of this line. If the repo runs Markdown linting/formatting, removing the trailing space avoids unnecessary diffs and potential lint failures.

[<img src="https://img.shields.io/badge/Website-blue?style=flat&logo=google-chrome&logoColor=white">](https://open-workflow-specification.org/) 

[Copilot]

Pull request overview

Copilot reviewed 15 out of 15 changed files in this pull request and generated no new comments.

Comments suppressed due to low confidence (5)

dsl-reference.md:1

• Same issue as the earlier A2A note: the link text is a URL but the href is an internal anchor. Adjust the link text and/or href so the rendered link meaning matches what users expect (either link to the actual URI, or label the anchor link as Standard error types).

# Open Workflow DSL - Reference

dsl-reference.md:507

• This markdown link displays a URL as its label but points to the #standard-error-types anchor, which is misleading for readers (it looks like it links to the URI itself). Consider changing the link text to something like Standard error types (keeping the anchor), or alternatively link the URL label to the actual URL and add a separate reference to the #standard-error-types section.

> On success the output is the JSON-RPC result. On failure runtimes must raise an error with type [https://open-workflow-specification.org/spec/1.0.0/errors/runtime](#standard-error-types).

dsl-reference.md:1231

• Within this PR, most references to standard error types use the /spec/1.0.0/errors/... namespace (and the Standard error types table also uses /spec/1.0.0/errors/...), but this example uses /dsl/errors/types/.... Please align this example with the canonical namespace used elsewhere in the specification (or document clearly why both namespaces exist and when each should be used).

            type: https://open-workflow-specification.org/dsl/errors/types/communication

ctk/features/raise.feature:19

• These URIs use .../errors/types/... while other updated CTK references in this PR use .../dsl/errors/types/... (e.g., ctk/features/try.feature). If these are meant to be part of the same error-type namespace, consider standardizing the base path to avoid confusion and reduce the chance of documenting/testing different conventions unintentionally.

              type: https://open-workflow-specification.org/errors/types/compliance

ctk/features/raise.feature:26

• These URIs use .../errors/types/... while other updated CTK references in this PR use .../dsl/errors/types/... (e.g., ctk/features/try.feature). If these are meant to be part of the same error-type namespace, consider standardizing the base path to avoid confusion and reduce the chance of documenting/testing different conventions unintentionally.

    type: https://open-workflow-specification.org/errors/types/compliance