Datastream GET vs POST/PUT disconnect/clarification

[SomethingCreativeStudios]

For datastream the redoc is showing different fields available to the datastream based on GET vs POST/PUT

For example POST

Vs GETs

This may be intentional however some fields are not clear on how they are mapped

• Formats: server provided based on the various schema's the datastream supports?
• observedProperties: Where do these come from? The schema? (assuming its not protofuff or other non json schema?)
• Schema: This is less of question of where it comes from (via the PUT update/schema endpoint) and more of should this be an array?

Based on Req 11 it seems there could be multiple formats so in theory schema probably should be an array of each schema based on obsFormat?

Example from Req 11 of multiple formats

https://{api_root}/datastreams/{id}/schema?obsFormat=application/json
https://{api_root}/datastreams/{id}/schema?obsFormat=application/swe%2Bcsv
https://{api_root}/datastreams/{id}/schema?obsFormat=application/swe%2Bbinary

[Sam-Bolling]

The different GET and POST/PUT views are intentional and follow the returnable/receivable distinction now standardized in OGC API Common Part 3: formats, observedProperties, phenomenonTime, resultTime, and resultType are returned by the server, while the embedded schema member is receivable when creating or updating a DataStream. As decided in #65, the server derives the observed properties and temporal/result summaries from associated Observations and uses null before observations exist. The name schema can be confusing here because it is not the logical schema of the DataStream metadata; it supplies one Observation-payload schema identified by its obsFormat.

I recommend retaining this model but updating the Part 2 and OpenAPI descriptions to use the Common Part 3 returnable/receivable terminology and explicitly distinguish the DataStream metadata schema from its per-format Observation schemas. formats should list every representation the server can provide, while /datastreams/{id}/schema?obsFormat=... returns one schema for the selected format, so the embedded schema remains singular. The encoding-specific validation details should remain coordinated with #181. @alexrobin, @SpeckiJ, and @autermann, please review this recommendation and provide any comments before our upcoming SWG meeting so the group can consider the feedback and work toward resolving and closing this issue.