Changes for closer alignment with OpenEO.

[pvretano]

No description provided.

[m-mohr]

Suggested change

	- cancelled
	- canceled

openEO uses "canceled", is it double l in OGC API Processes?

[pvretano]

Fixed.

[m-mohr]

Suggested change

	status:
	oneOf:
	$ref: "statusCode.yaml"
	status:
	oneOf:
	$ref: "statusCode.yaml"

Looks invalid

[pvretano]

Fixed.

[m-mohr]

Should it be required or optional?

[pvretano]

I reverted back to the required fields for OAProc and included text in the descriptions based on the value of the "type" property. If the value of "type" is "openeo" then both "created" and "process" MUST be present as per the OpenEO API definition.

[m-mohr]

Thanks.

Generally, I think we can do better to avoid these if/then conditionals as much as possible :-)

[m-mohr]

process type?

It should probably just describe the encoding of the process property

[pvretano]

I've updated the description to indicate that if "type" is "openeo" then the "process" property MUST be present and its value shall be a process graph as per the OpenEO API definition. Otherwise if can be an OAProc process description, a WPS process description, a link to either of these or a link to the request that created the job (e.g. an async coverages request).

[fmigneault]

Do we want this condition to be more explicit?

Since we have the allOf, we can make use of it.

allOf:
  - $ref: descriptionType.yaml
  - type: object
    # ... all other fields ...
  - if:
      properties:
        type: 
          const: openeo  # or 'enum' equivalent if prefered
    then:
      required:
        - id
        - type
        - status
        - process
      properties:
        process:
          $ref: "<uri-to-openeo-process-graph>"

[m-mohr]

I'm wondering whether OGC API - Processes should just define the framework and not have direct dependencies to openEO due to the issue that there are multiple versions of the openEO API...

As long as openEO follows the framework, I guess it's fine, isn't it?

[fmigneault]

I'm expecting that anyone that wants to do strong schema validation would actually use the reference openEO schemas rather than depend on OGC API, so it's fine if we don't define field requirements of openEO explicitly here.

However, if we do so, I don't see much point to have the long description either for specific frameworks. Saying in the description that process is required when type: openeo doesn't actually enforce or validate anything.

[m-mohr]

Yes, I think the spec should not include specifics about openEO. Maybe as an appendix only.

[fmigneault]

Do we want this condition to be more explicit?

Since we have the allOf, we can make use of it.

allOf:
  - $ref: descriptionType.yaml
  - type: object
    # ... all other fields ...
  - if:
      properties:
        type: 
          const: openeo  # or 'enum' equivalent if prefered
    then:
      required:
        - id
        - type
        - status
        - process
      properties:
        process:
          $ref: "<uri-to-openeo-process-graph>"

[fmigneault]

Does openEO have a schema for this?
The definition could be more explicit if we actually pointed to $ref: <uri-openeo-schema#status> or wherever it resides.

[m-mohr]

We don't do the OGC way with snippets, we only have a monolithic OpenAPI document. In principle you can refer to that though:

"$ref:" "https://raw.githubusercontent.com/Open-EO/openeo-api/refs/tags/1.2.0/openapi.yaml#/components/schemas/batch_job/properties/status"

That reminds me that we should probably version the OpenAPI files on gh-pages with the docs so that it will be

"$ref:" "https://api.openeo.org/1.2.0/openapi.yaml#/components/schemas/batch_job/properties/status"

I hope yaml works, but we could also deploy json.

[fmigneault]

The second link would be ideal. It's fine with definition anchors. Either YAML or JSON should work.

[bpross-52n]

SWG meeting from 2025-03-17: We will close this PR as this is not envisioned for the upcoming version of Part 1.