Merge branch 'serverlessworkflow:main' into outcome

Author: cdavernas

GOVERNANCE.md

@@ -38,6 +38,7 @@ depend on and trust to make decisions in the best interest of the project.
 Periodically, the existing maintainers curate a list of contributors that have
 shown regular activity on the project over the prior months. From this list,
 maintainer candidates are selected and proposed on the project mailing list.
+Only one maintainer per organization is allowed to avoid taking over votes in case of conflicts.
 
 After a candidate has been announced on the project mailing list, the
 existing maintainers are given fourteen business days to discuss the candidate,
@@ -116,6 +117,12 @@ As a result, all decisions can be expressed as changes to the repository. An
 implementation change is a change to the source code. An API change is a change
 to the API specification, and so on.
 
+Decisions are built on consensus between maintainers. Proposals and ideas can be submitted
+for agreement via a GitHub [issue](issues) or [discussion](discussions).
+Upon agreement, a pull request should be opened. We encourage not opening pull
+requests without a discussion first either in a new [issue](issues) or using
+the [discussion](discussions) tool.
+
 All decisions affecting Serverless Workflow, big and small, follow the same 3 steps:
 
 * Step 1: Open a pull request. Anyone can do this.
@@ -133,8 +140,18 @@ document for more information about opening pull requests.
 
 ## Conflict Resolution
 
-If you have a technical dispute that you feel has reached an impasse with a
-subset of the community, any contributor may open an issue, specifically
-calling for a resolution vote of the current core maintainers to resolve the dispute.
-The same voting quorums required (2/3) for adding and removing maintainers
-will apply to conflict resolution.
+At least 66% approval from the project's maintainers is necessary to merge changes
+in the specification. [Lazy consensus](http://communitymgt.wikia.com/wiki/Lazy_consensus)
+is considered by maintainers that do not directly express their opinions in the pull request.
+
+Discussions and voting can be posponed in case one of the maintainers expressed that
+they won't be available for personal reasons, e.g. parental leave, vacations, sick leave, etc.
+
+We generally prefer that technical issues and maintainer membership are amicably
+worked out between the persons involved. If a dispute cannot be resolved independently,
+get a third-party maintainer (e.g., a mutual contact with some background on the issue
+but not involved in the conflict) to intercede. If a dispute cannot be resolved,
+the core maintainers have the final say in deciding an issue. The core maintainers
+may reach this decision by consensus or by a simple majority vote if necessary.
+The maintainers should endeavor to make this decision within a reasonable amount
+of time, not to extend it longer than two weeks.

README.md

@@ -86,6 +86,11 @@ consuming, parsing, validating and testing their workflows that use the Serverle
 In order to enhance developer experience with the specification, we also provide a [Visual Studio Code extension](https://marketplace.visualstudio.com/items?itemName=serverlessworkflow.serverless-workflow-vscode-extension).
 The sources of the extension are found [here](https://github.com/serverlessworkflow/vscode-extension).
 
+## Requirements
+
+To generate the SVG diagram from the YAML or JSON file, you need to have the following tools installed:
+- https://www.graphviz.org/download/source/
+
 ## Community
 
 We have a growing community working together to build a community-driven and vendor-neutral

comparisons/comparison-temporal.md

@@ -82,7 +82,7 @@ public static class GreetingWorkflowImpl implements GreetingWorkflow {
 {
   "id": "greetingworkflow",
   "name": "Greeting Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "autoRetries": true,
   "states": [
@@ -164,7 +164,7 @@ WorkflowOptions workflowOptions =
 {
   "id": "greetingworkflow",
   "name": "Greeting Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "autoRetries": true,
   "timeouts": {
@@ -268,7 +268,7 @@ WorkflowOptions workflowOptions =
 {
   "id": "HelloSaga",
   "name": "Hello SAGA compensation Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "states": [
     {
@@ -392,7 +392,7 @@ static class GreetingActivitiesImpl implements GreetingActivities {
 {
   "id": "HelloActivityRetry",
   "name": "Hello Activity with Retries Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "autoRetries": true,
   "start": "GreetingState",

examples/README.md

@@ -67,7 +67,7 @@ data output, which is:
 ```json
 {
 "id": "helloworld",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Hello World Workflow",
 "description": "Inject Hello World",
@@ -151,7 +151,7 @@ Which is added to the states data and becomes the workflow data output.
 ```json
 {
 "id": "greeting",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Greeting Workflow",
 "description": "Greet Someone",
@@ -296,7 +296,7 @@ filters what is selected to be the state data output which then becomes the work
 ```json
 {
 "id": "eventbasedgreeting",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Event Based Greeting Workflow",
 "description": "Event Based Greeting",
@@ -424,7 +424,7 @@ result of the workflow execution.
 ```json
 {
 "id": "solvemathproblems",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Solve Math Problems Workflow",
 "description": "Solve math problems",
@@ -521,7 +521,7 @@ to finish execution before it can transition (end workflow execution in this cas
 ```json
 {
 "id": "parallelexec",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Parallel Execution Workflow",
 "description": "Executes two branches in parallel",
@@ -611,7 +611,7 @@ does not wait for its results.
 ```json
 {
  "id": "sendcustomeremail",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "name": "Send customer email workflow",
  "description": "Send email to a customer",
@@ -702,7 +702,7 @@ property to `continue`.
 ```json
 {
  "id": "onboardcustomer",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "name": "Onboard Customer",
  "description": "Onboard a Customer",
@@ -784,7 +784,7 @@ period, the workflow transitions to the "HandleNoVisaDecision" state.
 ```json
 {
 "id": "eventbasedswitchstate",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Event Based Switch Transitions",
 "description": "Event Based Switch Transitions",
@@ -946,7 +946,7 @@ If the applicants age is over 18 we start the application (subflow action). Othe
 ```json
 {
    "id": "applicantrequest",
-   "version": "1.0.0"
+   "version": "1.0.0",
    "specVersion": "0.8",
    "name": "Applicant Request Decision Workflow",
    "description": "Determine if applicant request is valid",
@@ -1090,7 +1090,7 @@ The data output of the workflow contains the information of the exception caught
 ```json
 {
 "id": "provisionorders",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Provision Orders",
 "description": "Provision Orders and handle errors thrown",
@@ -1286,7 +1286,7 @@ In the case job submission raises a runtime error, we transition to an Operation
 ```json
 {
   "id": "jobmonitoring",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "name": "Job Monitoring",
   "description": "Monitor finished execution of a submitted job",
@@ -1577,7 +1577,7 @@ CloudEvent upon completion of the workflow could look like:
 ```json
 {
 "id": "sendcloudeventonprovision",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "name": "Send CloudEvent on provision completion",
 "start": "ProvisionOrdersState",
@@ -1711,7 +1711,7 @@ have the matching patient id.
 {
 "id": "patientVitalsWorkflow",
 "name": "Monitor Patient Vitals",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "start": "MonitorVitals",
 "events": [
@@ -1906,7 +1906,7 @@ when all three of these events happened (in no particular order).
 {
 "id": "finalizeCollegeApplication",
 "name": "Finalize College Application",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "start": "FinalizeApplication",
 "events": [
@@ -2117,7 +2117,7 @@ And for denied credit check, for example:
 ```json
 {
     "id": "customercreditcheck",
-    "version": "1.0.0"
+    "version": "1.0.0",
     "specVersion": "0.8",
     "name": "Customer Credit Check Workflow",
     "description": "Perform Customer Credit Check",
@@ -2322,7 +2322,7 @@ Bidding is done via an online application and bids are received as events are as
 ```json
 {
     "id": "handleCarAuctionBid",
-    "version": "1.0.0"
+    "version": "1.0.0",
     "specVersion": "0.8",
     "name": "Car Auction Bidding Workflow",
     "description": "Store a single bid whole the car auction is active",
@@ -2452,7 +2452,7 @@ The results of the inbox service called is expected to be for example:
 {
 "id": "checkInbox",
 "name": "Check Inbox Workflow",
-"version": "1.0.0"
+"version": "1.0.0",
 "specVersion": "0.8",
 "description": "Periodically Check Inbox",
 "start": {
@@ -2596,7 +2596,7 @@ For this example we assume that the workflow instance is started given the follo
     "id": "VetAppointmentWorkflow",
     "name": "Vet Appointment Workflow",
     "description": "Vet service call via events",
-    "version": "1.0.0"
+    "version": "1.0.0",
     "specVersion": "0.8",
     "start": "MakeVetAppointmentState",
     "events": [
@@ -2747,7 +2747,7 @@ In our workflow definition then we can reference these files rather than definin
 ```json
 {
   "id": "paymentconfirmation",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "name": "Payment Confirmation Workflow",
   "description": "Performs Payment Confirmation",
@@ -2951,7 +2951,7 @@ If the retries are not successful, we want to just gracefully end workflow execu
 {
   "id": "patientonboarding",
   "name": "Patient Onboarding Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "start": "Onboard",
   "states": [
@@ -3123,7 +3123,7 @@ This example shows the use of the workflow [execTimeout definition](../specifica
 {
   "id": "order",
   "name": "Purchase Order Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "start": "StartNewOrder",
   "timeouts": {
@@ -3407,7 +3407,7 @@ the data for an hour, send report, and so on.
 {
   "id": "roomreadings",
   "name": "Room Temp and Humidity Workflow",
-  "version": "1.0.0"
+  "version": "1.0.0",
   "specVersion": "0.8",
   "start": "ConsumeReading",
   "timeouts": {
@@ -3581,7 +3581,7 @@ We fist define our top-level workflow for this example:
 {
  "id": "checkcarvitals",
  "name": "Check Car Vitals Workflow",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "start": "WhenCarIsOn",
  "states": [
@@ -3696,7 +3696,7 @@ And then our reusable sub-workflow which performs the checking of our car vitals
 {
  "id": "vitalscheck",
  "name": "Car Vitals Check",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "start": "CheckVitals",
  "states": [
@@ -3836,7 +3836,7 @@ For the sake of the example we assume the functions and event definitions are de
 {
  "id": "booklending",
  "name": "Book Lending Workflow",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "start": "Book Lending Request",
  "states": [
@@ -4128,7 +4128,7 @@ Its results are then merged back into the state data according to the "toStateDa
 {
  "id": "fillglassofwater",
  "name": "Fill glass of water workflow",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "start": "Check if full",
  "functions": [
@@ -4541,7 +4541,7 @@ We assume that our workflow input has the runtime-imposed quota:
      "end":{
       "continueAs": {
        "workflowId": "notifycustomerworkflow",
-       "version": "1.0.0"
+       "version": "1.0.0",
        "data": "${ del(.customerCount) }"
       }
      }
@@ -4661,7 +4661,7 @@ decide which activity to perform based on the transaction value.
 {
  "id": "customerbankingtransactions",
  "name": "Customer Banking Transactions Workflow",
- "version": "1.0.0"
+ "version": "1.0.0",
  "specVersion": "0.8",
  "autoRetries": true,
  "constants": {

schema/events.json

@@ -74,22 +74,21 @@
       "additionalProperties": false,
       "if": {
         "properties": {
-          "kind": {
-            "const": "consumed"
+          "source": {
+            "type": "null"
           }
         }
       },
       "then": {
         "required": [
           "name",
-          "source",
           "type"
         ]
       },
       "else": {
         "required": [
           "name",
-          "type"
+          "source"
         ]
       }
     },

schema/workflow.json

@@ -212,7 +212,7 @@
           "description": "Amount of time (ISO 8601 duration format) to sleep after function/subflow invocation. Does not apply if 'eventRef' is defined."
         }
       },
-      "oneOf": [
+      "anyOf": [
         {
           "required": [
             "before"