-
Notifications
You must be signed in to change notification settings - Fork 46
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix proposal for #319 #327
Fix proposal for #319 #327
Conversation
Thanks @gfenoy ! We should also add the (POST) paths for processes-dru to openapi/paths and then include them in ogcapi-processes.yaml. Then if it works with your demo API, we could add your server as an example supporting DRU to the list of example servers. You could also potentially use the example OpenAPI definition to assemble your API definition for your implementation, with |
Introduce fix for issue opengeospatial#328
Rename responses schemas using the r prefix
I have made the renaming using the |
Thanks @jerstlouis, it is a very nice way to validate our changes to use the |
@gfenoy Now you can add your server to the list of examples and say it supports DRU :) Then we can test it all directly from SwaggerUI. You can also do |
@jerstlouis should I also push the bundle to replace the current one? I ask this question because I noticed that there is no mention of Part 3 in the ogcapi-processes.yaml. Also, we may think of having the following files:
What do you think? |
@gfenoy Yes you can update the updated bundle.
That's because Part 3 does not really define any new paths, it only extends the execution request and defines the
I think it's simpler to just include everything in a single ogcapi-processes.yaml, and developers can comment out the paths they do not implement when they bundle their own OGC API. |
I will proceed after we get confirmation that once deployed a Server Instance relying on the proposed new schemas is properly working. |
Adjust adoc as needed
Thanks @fmigneault for feebcaks on opengeospatial#319
Add short documentation on how to generate the desired files. Small fix to make operationId unique
Use type string for application/cwl
Add instructions to generated the files in the README Thanks @jerstlouis for the comment about this
As per opengeospatial#282 (comment), remove CommonWorkflowLanguage.yml
openapi/README.md
Outdated
@@ -8,7 +8,7 @@ The list of supported paths should be ajusted in `ogcapi-processes-3.yaml`. | |||
|
|||
The `ogcapi-processes-3.bundled.json` was generated with `swagger-cli bundle` from `ogcapi-processes-3.yaml` and its dependencies included from the components sub-directories. | |||
|
|||
The `paths/processes-dru/pProcessListDeploy.yaml` and `paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml` files are generated by concatening multiple files in a single one. you can sue the command bellow to update their value with the current schema: | |||
The `paths/processes-dru/pProcessListDeploy.yaml` and `paths/processes-dru/pProcessDescriptionReplaceUndeploy.yaml` files are generated by concatening multiple files in a single one. you can use the command bellow to update their value with the current schema: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks @gfenoy . bellow is still wrong though :) (below)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for your patience @jerstlouis
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gfenoy No thank you for yours ;) Sorry for being so annoying finding things to fix :P
@@ -0,0 +1,5 @@ | |||
name: w |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@gfenoy What's w
for? Can we add a description
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@jerstlouis it is used to point to the workflow id to be deployed from a CWL containing multiple workflow definitions.
I have added the description, I hope it is clear.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks.
@fmigneault following the discussion there. My understanding is that the schema will be made available from there https://github.com/common-workflow-language/cwl-v1.2/. I don't know yet if we we plan to keep a copy of the schema also in this repository. I would like to have a confirmation about this. If not, then I will wait for the schema to be made available there to update the schema to reference this schema. |
@gfenoy |
@gfenoy @jerstlouis |
In these two definitions, I recall having a nested oneOf:
- $ref: "executionUnit.yaml"
- $ref: "../common-core/link.yaml"
- $ref: "../processes-core/qualifiedInputValue.yaml" executionUnit:
oneOf:
- $ref: "executionUnit.yaml"
- $ref: "../common-core/link.yaml"
- $ref: "../processes-core/qualifiedInputValue.yaml"
- $ref: "ogcapppkg-array.yaml" The Also, https://raw.githubusercontent.com/common-workflow-language/cwl-v1.2/1.2.1_proposed/json-schema/cwl.yaml can now be added to those lists as well. |
Thanks @fmigneault for this great work. Co-authored-by: Francis Charette-Migneault <[email protected]>
@gfenoy Is there something still blocking this PR? |
@fmigneault we were discussing about merging this PR during the last SWG meeting and no objection was raised. I plan to attend the today meeting and hope we can get this PR merged during the SWG meeting except if an objection is exposed. In case you have time, it would be great to have you attending the meeting to support this PR. |
21-AUG-2023: SWG reviewed the PR and agreed to merge. If any issues arrive after the fact, new issues can be created to address those. |
This changes should solve the issue #319 related to moving the schemas location from the extension specific openapi subdirectory to root.