Added the top level evaluate property, used to configure both the r…

…untime expression language and mode.

Partially addresses #848

Signed-off-by: Charles d'Avernas <[email protected]>

dsl-reference.md

@@ -68,6 +68,7 @@ A [workflow](#workflow) serves as a blueprint outlining the series of [tasks](#t
 | timeout | [`timeout`](#timeout) | `no` | The configuration, if any, of the workflow's timeout. |
 | output | [`output`](#output) | `no` | Configures the workflow's output. |
 | schedule | [`schedule`](#schedule) | `no` | Configures the workflow's schedule, if any. |
+| evaluate | [`evaluate`](#evaluate) | `no` | Configures runtime expression evaluation. |
 
 #### Document
 
@@ -98,7 +99,7 @@ Defines the workflow's reusable components.
 
 #### Schedule
 
-Configures a workflow's schedule.
+Configures the schedule of a workflow.
 
 | Name | Type | Required | Description|
 |:--|:---:|:---:|:---|
@@ -107,6 +108,15 @@ Configures a workflow's schedule.
 | after | [`duration`](#duration) | `no` | Specifies a delay duration that the workflow must wait before starting again after it completes. In other words, when this workflow completes, it should run again after the specified amount of time.<br>*Required when no other property has been set.*  |
 | on | [`eventConsumptionStrategy`](#event-consumption-strategy) | `no` | Specifies the events that trigger the workflow execution.<br>*Required when no other property has been set.* |
 
+#### Evaluate
+
+Configures a workflow's runtime expression evaluation.
+
+| Name | Type | Required | Description|
+|:--|:---:|:---:|:---|
+| language | `string` | `yes` | The language used for writting runtime expressions.<br>*Defaults to `jq`.* |
+| mode | `string` | `yes` | The runtime expression evaluation mode.<br>*Supported values are:*<br>- `strict`: requires all expressions to be enclosed within `${ }` for proper identification and evaluation.<br>- `loose`: evaluates any value provided. If the evaluation fails, it results in a string with the expression as its content.<br>*Defaults to `strict`.*
+
 #### Examples
 
 ```yaml

dsl.md

@@ -181,9 +181,11 @@ Runtime expressions allow for the incorporation of variables, functions, and ope
 
 One key aspect of runtime expressions is their ability to adapt to runtime data and context. This means that expressions can access and manipulate data generated during the execution of a workflow, enabling dynamic decision-making and behavior based on real-time information.
 
-All runtimes **must** support the default runtime expression language, which is [`jq`]().
+Runtime expressions in Serverless Workflow can be evaluated using either the default `strict` mode or the `loose` mode. In `strict` mode, all expressions must be properly identified with `${}` syntax. Conversely, in `loose` mode, expressions are evaluated more liberally, allowing for a wider range of input formats. While `strict` mode ensures strict adherence to syntax rules, `loose` mode offers flexibility, allowing evaluation even if the syntax is not perfectly formed.
 
-Runtimes **may** optionally support other runtime expression languages, which authors can specifically use by adequately configuring the workflow. See [`use.language`](dsl-reference.md#use) for more details.
+All runtimes **must** support the default runtime expression language, which is [`jq`](https://jqlang.github.io/jq/).
+
+Runtimes **may** optionally support other runtime expression languages, which authors can specifically use by adequately configuring the workflow. See [`evaluate.language`](dsl-reference.md#evaluate) for more details.
 
 CloudFlows defines [several arguments](#runtime-expression-arguments) that runtimes **must** provide during the evaluation of runtime expressions.