Frank Kilcommins
Frank Kilcommins
Revisit the structure of the README. Move the charter etc. to a separate file
See #164
Ideally we should have a media types for workflows so that they can be exposed as proper resources. Once registered etc., we should add the relevant information to the specification.
This issue is to work towards deliver of an _implementer_ version of the Workflows Specification that can be used by interested vendors (or community members) to build prototype tooling and...
The exit process for new specifications coming out of Special Interest Groups require a home within the OpenAPIs website. At a minimum, we need to: - update the specs page...
> Section [Reference Object](https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#reference-object), field `$ref` says > > > This MUST be in the form of a URI. > > Which is only half of the truth: the fragment...
As per feedback [comment](https://github.com/OAI/sig-workflows/issues/49#issuecomment-1833885941), it would be good to enhance the Section [Data Types](https://github.com/OAI/sig-workflows/blob/main/versions/1.0.0.md#data-types): link to the [Formats Registry](https://spec.openapis.org/registry/format/index.html), ideally per format. This likely also needs a review of the...
Work with @MikeRalphson to create a dedicated preamble for the _pretty print_ version of the specification which will be housed on https://spec.openapis.org/ **Draft version:** https://mikeralphson.github.io/OpenAPI-Specification/workflows/1.0.0.html **To resolve:** hardcoding related to...
Add more examples into the specification (or example documents) that show case having multiple success/failure objects with different criteria. This will draw better attention to the possibilities of branching.
Having the following event handlers could be advantageous for steps and workflows - onNext - onCompletion The addition would likely negate the creation of vendor specific extensions to cover similar...