opengeospatial / ogcapi-processes

Home Page:https://ogcapi.ogc.org/processes

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Inconsistent schemas in DRU extension since OpenAPI restructure

fmigneault opened this issue · comments

Since #306, both of these files exist at the same time:

Although their names are the same, their contents are entirely different.

Multiple other items under https://github.com/opengeospatial/ogcapi-processes/tree/master/extensions/deploy_replace_undeploy/standard/openapi have not been moved at all.

Having both locations with inconsistent schemas makes it very confusing for referencing this extension.

@fmigneault @gfenoy

When I worked on #306, I updated all of the reference from Processes - Part 1, but not those from Part 2.
That is why I left the schemas in Part 2 until it is updated properly.
I am not sure what the ogcapppkg in the root openapi directory is -- it might be the updated one from Gerald.
Gerald could you please verify and do a PR to update Part 2 to reference the new one, and remove the old schemas once everything works fine?

Note that the top-level metanorma document for Part 2 will have to be moved to the root alongside Part 1 & 3 to avoid errors referencing above it.

@fmigneault thanks for your patience.

The schemas should now be correct in the root openapi location 62f3743. Also, I have modified the ogcapi-processes.yaml to include Part 2, but did not push the generated json bundle yet.

@fmigneault it defenetely makes sense to add these content types, so I added them 24077f6.

As @jerstlouis said in this comment implementers can then comment content-types not supported. Note that, on case there is only one content-types remaining, then the oneOf should also be removed, I think.

@fmigneault an updated version is available here: GeoLabs@26e325b. We are now able to have the select list for Deploy and Undeploy from there https://app.swaggerhub.com/apis/ZOO-Project/the-zoo_project_wps_ogc_api_processing_development_server/0.1#/. Still, there is this error when you select it, probably due to the wrong example we inserted to fake an empty object to get to select list...

To be continued.

@gfenoy
If you feel like providing a detailed schema, I have it for CWL here: https://services.crim.ca/weaver/api#/Deploy/post_processes
(JSON schemas somewhere under https://services.crim.ca/weaver/json definitions).

Otherwise, a minimalistic CWL schema could be defined. Minimally, it has "cwlVersion": "v{SEMVER}" at the root that distinguishes it from other deploy body contents.

@fmigneault it seems you read my mind. Indeed, I am searching for the schema of the application/cwl+json but I am unable to find any official one unfortunately.

On the other hand, I have worked on this new version here: https://app.swaggerhub.com/apis/ZOO-Project/the-zoo_project_wps_ogc_api_processing_development_server/Part-2-Deploy-Replace-UndeployProcess

This time we don't have any error when loading another content type for the requestBody parameter, we even provide an example for each content types (all using the exact same CWL file).

Nevertheless, the minimal schema for CWL would be helpful to have something relevant when there is no example defined within the API.

I have finally used https://raw.githubusercontent.com/common-workflow-language/cwl-v1.2/1.2.1_proposed/CommonWorkflowLanguage.yml as schema for application/cwl+json there: 16ba65b.

I hope it is correct, feedbacks are welcome.

With b47410e we get back to the trick using the schema object with an example field.

You can find here: https://app.swaggerhub.com/apis/ZOO-Project/the-zoo_project_wps_ogc_api_processing_development_server/GIT_2023-oas3#/DRU/replace the latest bundle generated with swagger-cli bundle.

@gfenoy
I looked at the reference. This is actually a Schema Salad YAML definition, not an OpenAPI / JSON Schema.
I don't think OpenAPI is able to parse it.

@fmigneault Thanks a ton for the help!

The work on providing the schema for CWL you handle should solve this issue, once we will update to make reference to it (cf. #329) I think we should be fine.