I love the idea of this, but namespace on the run.workflow is a required field by the Serverless Workflow spec. When you run the child workflow example (easiest way is air inside the /examples/child-workflows directory), it fails validation.

One of the goals of the v0.1 (pre-release) version of this project is to maintain compatibility with the Serverless Workflow spec, so I don't think this should go in in this form.

I love the idea of this, but namespace on the run.workflow is a required field by the Serverless Workflow spec. When you run the child workflow example (easiest way is air inside the /examples/child-workflows directory), it fails validation.

One of the goals of the v0.1 (pre-release) version of this project is to maintain compatibility with the Serverless Workflow spec, so I don't think this should go in in this form.

But I think your implementation is using top level namespace as Temporal queue name.
So this PR is in line with current implementation.
Ref: https://github.com/mrsimonemms/temporal-dsl/blob/facb123abecf6e5ee67575c424265970b2866c83/pkg/dsl/schedules.go#L64

Yes, it allows for the Serverless Workflow's namespace to be aligned to the Temporal task queue, but it still doesn't solve the problem of the Temporal DSL binary to run - when I try it, it errored with a validation error.

Based on what I think you were trying to do, I created #106. This introduces the concept of PostLoad hooks. After the YAML is loaded, it allows for arbitrary changes to the given workflow.

I'd still like to hang fire on the default task queue on the run.worker for the moment, especially as the task doesn't actually have the namespace wired up to anything. I'd love the Python example though, if you can make the change so that workflow.yaml is like the Basic/TypeScript examples.

Hi @mrsimonemms
Could you check current version ? I just re-add namespaces in child-workflow but with correct values.
TL;DR; that's my proposition how mapping to task queues should look like.