Order of schema validation and input transformation

[matthias-pichler]

This example

https://github.com/serverlessworkflow/specification/blob/feb9ca9228eba1b9fabaebb442245ebbfc81046b/dsl-reference.md?plain=1#L1512C1-L1522C4

implies to me that

1. first input.from transformations are applied
2. input.schema is validated against the result of input.from

Firstly I think we should properly & explicitly document the order somewhere.

However: I frequently get the order of schema validation and input transformation wrong. For me personally it would make more sense to validate the input to my runtime expression rather than its result. It feels a bit like output validation instead of input validation.

for me the following order would make sense:

1. input validation
2. input transformation
3. task execution
4. output transformation
5. output validation
6. context transformation
7. context validation

[cdavernas]

@matthias-pichler Thanks for the insightful discussion; it's a fascinating and nuanced topic.

For me personally it would make more sense to validate the input to my runtime expression rather than its result. It feels a bit like output validation instead of input validation.

I agree with your perspective—it's also how I've been approaching it so far. However, on further reflection, I believe that the schema should ensure the validity of the input at the point where it's actually being used, which naturally occurs after any transformations.

The rationale is that the schema's primary role is to confirm that the workflow or task is receiving the correct input when it executes. Validating the raw input doesn't seem to add much value in this context, in my opinion. Additionally, it's more common to encounter issues with invalid runtime expressions than with incorrect raw inputs in a flow.

From a user’s perspective, though, it’s clear that using the schema to document and validate raw input would be beneficial for both workflows and custom actions.

The same logic extends to output validation, but with fewer complications, in my opinion. Should we ensure that the raw output is valid (which, again, seems of limited value) or focus on the final, transformed output? I believe it should be the latter, enabling authors to ensure that tasks and workflows produce outputs that meet expectations.

---

In conclusion, I think you’ve highlighted a critical issue, particularly for workflows and custom functions, though it’s less relevant for inline tasks. There's an obvious need to document the expected input for flows and custom functions and to validate data before it's used. However, doing both might become cumbersome and counterintuitive.

[cdavernas]

@matthias-pichler After careful consideration and private discussions, I (and @JBBianchi afaik) totally second the proposal you started the discussion with!

Could you open a PR to address documenting that flow?