You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
As a working group we've discussed the potential need for having aliases to facilitate codegen use-cases.
Currently, when referencing an operationId within a source specification document, you MUST prefix it with the source name if more than one source exists to avoid collisions. This is stated as follows in the spec:
If more than one source document is defined within a Workflows document, then the operationId specified MUST be prefixed with the source name to avoid ambiguity or potential clashes.
While the above approach ensures clarity within the Workflows Specification, it does not necessarily help codegen tools form figuring out how to name source1.opName and source2.opName to two different meaningful class or function names.
Should we add the ability to support aliases within the core spec, or perhaps we should auto an official codegen extension for the specification.
The text was updated successfully, but these errors were encountered:
@frankkilcommins I am thinking the "if more than one source exists" part should not be an option.. e.g. we should always prefix a reference with the source even if only one exists. I'll play around with this along with aliases.
As a working group we've discussed the potential need for having aliases to facilitate codegen use-cases.
Currently, when referencing an
operationId
within a source specification document, you MUST prefix it with thesource name
if more than one source exists to avoid collisions. This is stated as follows in the spec:While the above approach ensures clarity within the Workflows Specification, it does not necessarily help codegen tools form figuring out how to name
source1.opName
andsource2.opName
to two different meaningful class or function names.Should we add the ability to support aliases within the core spec, or perhaps we should auto an official codegen extension for the specification.
The text was updated successfully, but these errors were encountered: