Fixed inconsistencies between listen and emit

ctk/features/set.feature

@@ -3,7 +3,7 @@ Feature: Set Task
   I want to ensure that set tasks can be executed within the workflow
   So that my implementation conforms to the expected behavior
 
-  # Tests emit tasks
+  # Tests set tasks
   Scenario: Set Task
     Given a workflow with definition:
     """yaml

dsl-reference.md

@@ -25,8 +25,8 @@
         + [Shell](#shell-process)
         + [Script](#script-process)
         + [Workflow](#workflow-process)
-    - [Switch](#switch)
     - [Set](#set)
+    - [Switch](#switch)
     - [Try](#try)
     - [Wait](#wait)
   + [Flow Directive](#flow-directive)
@@ -42,6 +42,7 @@
     - [Standard Error Types](#standard-error-types)
   + [Event Consumption Strategy](#event-consumption-strategy)
   + [Event Filter](#event-filter)
+  + [Event Properties](#event-properties)
   + [Retry](#retry)
   + [Input](#input)
   + [Output](#output)
@@ -229,9 +230,9 @@ The Serverless Workflow DSL defines a list of [tasks](#task) that **must be** su
 - [Call](#call), used to call services and/or functions.
 - [Do](#do), used to define one or more subtasks to perform in sequence.
 - [Fork](#fork), used to define one or more subtasks to perform concurrently.
-- [Emit](#emit), used to emit [events](#event).
+- [Emit](#emit), used to emit [events](#event-properties).
 - [For](#for), used to iterate over a collection of items, and conditionally perform a task for each of them.
-- [Listen](#listen), used to listen for an [event](#event) or more.
+- [Listen](#listen), used to listen for an [event](#event-properties) or more.
 - [Raise](#raise), used to raise an [error](#error) and potentially fault the [workflow](#workflow).
 - [Run](#run), used to run a [container](#container-process), a [script](#script-process) , a [shell](#shell-process) command or even another [workflow](#workflow-process). 
 - [Switch](#switch), used to dynamically select and execute one of multiple alternative paths based on specified conditions
@@ -368,7 +369,7 @@ The [HTTP Call](#http-call) enables workflows to interact with external services
 | Name | Type | Required | Description|
 |:--|:---:|:---:|:---|
 | method | `string` | `yes` | The HTTP request method. |
-| endpoint | [`endpoint`](#endpoint) | `yes` | An URI or an object that describes the HTTP endpoint to call. |
+| endpoint | `string`\|[`endpoint`](#endpoint) | `yes` | An URI or an object that describes the HTTP endpoint to call. |
 | headers | `map` | `no` | A name/value mapping of the HTTP headers to use, if any. |
 | body | `any` | `no` | The HTTP request body, if any. |
 | output | `string` | `no` | The http call's output format.<br>*Supported values are:*<br>*- `raw`, which output's the base-64 encoded [http response](#http-response) content, if any.*<br>*- `content`, which outputs the content of [http response](#http-response), possibly deserialized.*<br>*- `response`, which outputs the [http response](#http-response).*<br>*Defaults to `content`.* |
@@ -494,7 +495,7 @@ Allows workflows to publish events to event brokers or messaging systems, facili
 
 | Name | Type | Required | Description |
 |:--|:---:|:---:|:---|
-| emit.event | [`event`](#event) | `yes` | Defines the event to emit. |
+| emit.event | [`eventProperties`](#event-properties) | `yes` | Defines the event to emit. |
 
 ##### Examples
 
@@ -508,15 +509,16 @@ do:
   - emitEvent:
       emit:
         event:
-          source: https://petstore.com
-          type: com.petstore.order.placed.v1
-          data:
-            client:
-              firstName: Cruella
-              lastName: de Vil
-            items:
-              - breed: dalmatian
-                quantity: 101
+          with:
+            source: https://petstore.com
+            type: com.petstore.order.placed.v1
+            data:
+              client:
+                firstName: Cruella
+                lastName: de Vil
+              items:
+                - breed: dalmatian
+                  quantity: 101
 ```
 
 #### For
@@ -528,9 +530,9 @@ Allows workflows to iterate over a collection of items, executing a defined set
 | Name | Type | Required | Description|
 |:--|:---:|:---:|:---|
 | for.each | `string` | `no` | The name of the variable used to store the current item being enumerated.<br>Defaults to `item`. |
-| for.in | `string` | `yes` | A [runtime expression](#runtime-expressions) used to get the collection to enumerate. |
+| for.in | `string` | `yes` | A [runtime expression](dsl.md#runtime-expressions) used to get the collection to enumerate. |
 | for.at | `string` | `no` | The name of the variable used to store the index of the current item being enumerated.<br>Defaults to `index`. |
-| while | `string` | `no` | A [runtime expression](#runtime-expressions) that represents the condition, if any, that must be met for the iteration to continue. |
+| while | `string` | `no` | A [runtime expression](dsl.md#runtime-expressions) that represents the condition, if any, that must be met for the iteration to continue. |
 | do | [`task`](#task) | `yes` | The task to perform for each item in the collection. |
 
 ##### Examples
@@ -555,8 +557,8 @@ do:
                 one:
                   with:
                     type: com.fake.petclinic.pets.checkup.completed.v2
-              output:
-                as: '.pets + [{ "id": $pet.id }]'        
+            output:
+              as: '.pets + [{ "id": $pet.id }]'        
 ```
 
 #### Fork
@@ -964,7 +966,7 @@ do:
 
 ##### Switch Case
 
-Defines a switch case, encompassing of a condition for matching and an associated action to execute upon a match.
+Defines a switch case, encompassing a condition for matching and an associated action to execute upon a match.
 
 | Name | Type | Required | Description |
 |:--|:---:|:---:|:---|
@@ -1113,7 +1115,7 @@ document:
 use:
   secrets:
     - usernamePasswordSecret
-  authentication:
+  authentications:
     sampleBasicFromSecret:
       basic:
         use: usernamePasswordSecret
@@ -1389,6 +1391,28 @@ Represents the configuration of an event consumption strategy.
 | any | [`eventFilter[]`](#event-filter) | `no` | Configures the workflow to wait for any of the defined events before resuming execution.<br>*Required if `all` and `one` have not been set.* |
 | one | [`eventFilter`](#event-filter) | `no` | Configures the workflow to wait for the defined event before resuming execution.<br>*Required if `all` and `any` have not been set.* |
 
+### Event Properties
+
+An event object typically includes details such as the event type, source, timestamp, and unique identifier along with any relevant data payload. The [Cloud Events specification](https://cloudevents.io/), favored by Serverless Workflow, standardizes this structure to ensure interoperability across different systems and services.
+
+#### Properties
+
+| Property | Type | Required | Description |
+|----------|:----:|:--------:|-------------|
+| id | `string` | `no` | Identifies the event. `source` + `id` is unique for each distinct event.<br>*Required when emitting an event using `emit.event.with`.* |
+| source | `string` | `no` | An URI formatted string, or [runtime expression](dsl.md#runtime-expressions), that identifies the context in which an event happened. `source` + `id` is unique for each distinct event.<br>*Required when emitting an event using `emit.event.with`.* |
+| type | `string` | `no` | Describes the type of event related to the originating occurrence.<br>*Required when emitting an event using `emit.event.with`.* |
+| time | `string` | `no` | A string, or [runtime expression](dsl.md#runtime-expressions), representing the timestamp of when the occurrence happened. |
+| subject | `string` | `no` | Describes the subject of the event in the context of the event producer. |
+| datacontenttype | `string` | `no` | Content type of `data` value. If omitted, it implies the `data` is a JSON value conforming to the "application/json" media type. |
+| dataschema | `string` | `no` | An URI formatted string, or [runtime expression](dsl.md#runtime-expressions), that identifies the schema that `data` adheres to. |
+| data | `object` | `no` | The event payload. |
+
+*Additional properties can be supplied, see the Cloud Events specification [documentation](https://github.com/cloudevents/spec/blob/main/cloudevents/spec.md#extension-context-attributes) for more info.*
+
+*When used in an [`eventFilter`](#event-filter), at least one property must be supplied.*
+
+
 ### Event Filter
 
 An event filter is a mechanism used to selectively process or handle events based on predefined criteria, such as event type, source, or specific attributes.
@@ -1397,7 +1421,7 @@ An event filter is a mechanism used to selectively process or handle events base
 
 | Property | Type | Required | Description |
 |----------|:----:|:--------:|-------------|
-| with | `object` | `yes` | A name/value mapping of the attributes filtered events must define. Supports both regular expressions and runtime expressions.  |
+| with | [`eventProperties`](#event-properties) | `yes` | A name/value mapping of the attributes filtered events must define. Supports both regular expressions and runtime expressions.  |
 | correlate | [`map[string, correlation]`](#correlation) | `no` | A name/definition mapping of the correlations to attempt when filtering events. |
 
 ### Correlation
@@ -1473,7 +1497,7 @@ When set, runtimes must validate input data against the defined schema, unless d
 | Property | Type | Required | Description |
 |----------|:----:|:--------:|-------------|
 | schema | [`schema`](#schema) | `no` | The [`schema`](#schema) used to describe and validate input data.<br>*Even though the schema is not required, it is strongly encouraged to document it, whenever feasible.* |
-| from | `string`<br>`object` | `no` | A [runtime expression](#runtime-expressions), if any, used to filter and/or mutate the workflow/task input.  |
+| from | `string`<br>`object` | `no` | A [runtime expression](dsl.md#runtime-expressions), if any, used to filter and/or mutate the workflow/task input.  |
 
 #### Examples
 
@@ -1502,7 +1526,7 @@ When set, runtimes must validate output data against the defined schema, unless
 | Property | Type | Required | Description |
 |----------|:----:|:--------:|-------------|
 | schema | [`schema`](#schema) | `no` | The [`schema`](#schema) used to describe and validate output data.<br>*Even though the schema is not required, it is strongly encouraged to document it, whenever feasible.* |
-| as | `string`<br>`object` | `no` | A [runtime expression](#runtime-expressions), if any, used to filter and/or mutate the workflow/task output. |
+| as | `string`<br>`object` | `no` | A [runtime expression](dsl.md#runtime-expressions), if any, used to filter and/or mutate the workflow/task output. |
 
 #### Examples
 
@@ -1636,6 +1660,17 @@ minutes: 15
 seconds: 30
 ```
 
+### Endpoint
+
+Describes an enpoint.
+
+#### Properties
+
+| Property | Type | Required | Description |
+|----------|:----:|:--------:|-------------|
+| uri | `string` | `yes` | The endpoint's URI. |
+| authentication | `[authentication](#authentication)` | `no` | The authentication policy to use. |
+
 ### HTTP Response
 
 Describes an HTTP response.

dsl.md

@@ -81,7 +81,7 @@ Workflows in the Serverless Workflow DSL can exist in several phases, each indic
 
 Additionally, the flow of execution within a workflow can be controlled using [directives*](dsl-reference.md#flow-directive), which provide instructions to the workflow engine on how to manage and handle specific aspects of workflow execution.
 
-**To learn more about flow directives and how they can be utilized to control the execution and behavior of workflows, please refer to [Flow Directives](dsl-reference.md#flow-directive).*
+\**To learn more about flow directives and how they can be utilized to control the execution and behavior of workflows, please refer to [Flow Directives](dsl-reference.md#flow-directive).*
 
 #### Components
 
@@ -102,14 +102,14 @@ The Serverless Workflow DSL defines several default [task](dsl-reference.md#task
 
 - [Call](dsl-reference.md#call), used to call services and/or functions.
 - [Do](dsl-reference.md#do), used to define one or more subtasks to perform in sequence.
-- [Fork](dsl-reference.md#fork), used to define one or more two subtasks to perform in parallel.
 - [Emit](dsl-reference.md#emit), used to emit [events](dsl-reference.md#event).
 - [For](dsl-reference.md#for), used to iterate over a collection of items, and conditionally perform a task for each of them.
+- [Fork](dsl-reference.md#fork), used to define one or more two subtasks to perform in parallel.
 - [Listen](dsl-reference.md#listen), used to listen for an [event](dsl-reference.md#event) or more.
 - [Raise](dsl-reference.md#raise), used to raise an [error](dsl-reference.md#error) and potentially fault the [workflow](dsl-reference.md#workflow).
 - [Run](dsl-reference.md#run), used to run a [container](dsl-reference.md#container-process), a [script](dsl-reference.md#script-process), a [shell](dsl-reference.md#shell-process) command or even another [workflow](dsl-reference.md#workflow-process). 
-- [Switch](dsl-reference.md#switch), used to dynamically select and execute one of multiple alternative paths based on specified conditions
 - [Set](dsl-reference.md#set), used to dynamically set or update the [workflow](dsl-reference.md#workflow)'s data during the its execution. 
+- [Switch](dsl-reference.md#switch), used to dynamically select and execute one of multiple alternative paths based on specified conditions
 - [Try](dsl-reference.md#try), used to attempt executing a specified [task](dsl-reference.md#task), and to handle any resulting [errors](dsl-reference.md#error) gracefully, allowing the [workflow](dsl-reference.md#workflow) to continue without interruption.
 - [Wait](dsl-reference.md#wait), used to pause or wait for a specified duration before proceeding to the next task.
 
@@ -138,7 +138,7 @@ A workflow begins with the first task defined.
 
 Once the task has been executed, different things can happen:
 
-- `continue`: the task ran to completion, and the next task, if any, should be executed. The task to run next is implictly the next in declaration order, or explicitly defined by the `then` property of the executed task. If the executed task is the last task, then the workflow's execution gracefully ends.
+- `continue`: the task ran to completion, and the next task, if any, should be executed. The task to run next is implicitly the next in declaration order, or explicitly defined by the `then` property of the executed task. If the executed task is the last task, then the workflow's execution gracefully ends.
 - `fault`: the task raised an uncaught error, which abruptly halts the workflow's execution and makes it transition to `faulted` [status phase](#status-phases).
 - `end`: the task explicitly and gracefully ends the workflow's execution. 
 
@@ -196,7 +196,7 @@ Runtimes **may** optionally support other runtime expression languages, which au
 
 CloudFlows defines [several arguments](#runtime-expression-arguments) that runtimes **must** provide during the evaluation of runtime expressions.
 
-When the evaluation of an expression fails, runtimes **must** raise an error with type `https://https://serverlessworkflow.io/spec/1.0.0/errors/expression` and status `400`.
+When the evaluation of an expression fails, runtimes **must** raise an error with type `https://serverlessworkflow.io/spec/1.0.0/errors/expression` and status `400`.
 
 #### Runtime expression arguments
 
@@ -220,7 +220,7 @@ Errors in Serverless Workflow are described using the [Problem Details RFC](http
 
 *Example error:*
 ```yaml
-type: https://https://serverlessworkflow.io/spec/1.0.0/errors/communication
+type: https://serverlessworkflow.io/spec/1.0.0/errors/communication
 title: Service Unavailable
 status: 503
 detail: The service is currently unavailable. Please try again later.
@@ -263,7 +263,7 @@ Workflows and tasks alike can be configured to timeout after a defined amount of
 
 When a timeout occur, runtimes **must** abruptly interrupt the execution of the workflow/task, and **must** raise an error that, if uncaught, force the workflow/task to transition to the [`faulted` status phase](#status-phases).
 
-A timeout error **must** have its `type` set to `https://https://serverlessworkflow.io/spec/1.0.0/errors/timeout` and **should** have its `status` set to `408`.
+A timeout error **must** have its `type` set to `https://serverlessworkflow.io/spec/1.0.0/errors/timeout` and **should** have its `status` set to `408`.
 
 ### Interoperability
 
@@ -275,7 +275,7 @@ Serverless Workflow DSL is designed to seamlessly interact with a variety of ser
 - [**AsyncAPI**](dsl-reference.md#asyncapi-call): Facilitates interaction with asynchronous messaging protocols. AsyncAPI is designed for event-driven architectures, allowing workflows to publish and subscribe to events.
 - [**OpenAPI**](dsl-reference.md#openapi-call): Enables communication with services that provide OpenAPI specifications, which is useful for defining and consuming RESTful APIs.
 
-Runtimes **must** raise an error with type `https://https://serverlessworkflow.io/spec/1.0.0/errors/communication` if and when a problem occurs during a call.
+Runtimes **must** raise an error with type `https://serverlessworkflow.io/spec/1.0.0/errors/communication` if and when a problem occurs during a call.
 
 #### Custom and Non-Standard Interactions
 

examples/accumulate-room-readings.yaml

@@ -14,16 +14,14 @@ do:
               correlate:
                 roomId:
                   from: .roomid
-              output:
-                as: .data.reading
             - with:
                 source: https://my.home.com/sensor
                 type: my.home.sensors.humidity
               correlate:
                 roomId:
                   from: .roomid
-              output:
-                as: .data.reading
+      output:
+        as: .data.reading
   - logReading:
       for:
         each: reading