serverlessworkflow / specification

Contains the official specification for the Serverless Workflow Domain Specific Language. It provides detailed guidelines and standards for defining, executing, and managing workflows in serverless environments, ensuring consistency and interoperability across implementations.
http://serverlessworkflow.io
Apache License 2.0
730 stars 146 forks source link

Use maps instead of arrays for complex objects in the specification #831

Closed ricardozanini closed 3 months ago

ricardozanini commented 5 months ago

What would you like to be added: For the long term, we should use maps (key/value) instead of arrays when listing complex objects. For example:

states:
    - name: state-1
        actions:
        - name: action-1
    - name: state-2
    - name: state-3

Although it looks fine when using tools such as JsonPointer or JSON path to find items in the definition it may pose a challenge: states/0/actions/0/functionRef. One must rely on the array to find the objects. If the flow changes and a state or action changes the original order, the queries will be jeopardized.

Instead, we can use maps:

states:
    state1:
        action1:
    state2:
    state3:

The query then can be pragmatic, order won't matter: states/state1/action1.

Additionally, implementation-wise, a few languages may not guarantee a correct order when serializing/deserializing a workflow. Using maps will definitely get rid of such a risk.

Why is this needed: See context: https://github.com/serverlessworkflow/specification/pull/820#discussion_r1523718212

cdavernas commented 5 months ago

On a side note, we will I believe need to remove naming restrictions on actions and states, as they will be naturally enforced by property naming rules.

github-actions[bot] commented 4 months ago

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

cdavernas commented 3 months ago

This has been addressed in 1.0.0-alpha1, and is closed as part of #843