Scenes API as a separate part

[m-mohr]

I think the Scenes API is distinct and separated enough functionality that it should be a separate part of Coverages (Part 2 or so). It has similar characteristics to STAC and Records and I assume it should evolve together with them, so having it separate would allow it to evolve a bit more agile without touching Core. Also, generally it is preferrable to keep things small and easily digestible.

[jerstlouis]

@m-mohr Since it's its own requirements class, it would be possible to update only requirements class without touching the other requirements classes of the Part 1: Core document.

Given the overhead of the standardization process and limited time to put into the editing efforts, I prefer doing more at once, and I feel the separate requirement classes have the same flexibility.

It also makes it easier for implementers to know that a particular functionality is available than if it is in a separate document.
But I have no major objection if the SWG members decides to move it to a Part 2, and that might indeed provide the opportunity to specify more normatively and do more implementation testing.

Have you looked at the possibility to implement Scenes on your end?
The requirements defined in the requirements class are mostly orthogonal with STAC / Records, and with the exception of the .../scenes instead of .../items, the intention is that you could negotiate a STAC item representation for an individual scene. The requirements are more about being able to retrieve a coverage from .../scenes/{sceneId}/coverage, and the concept that the scenes are individual parts of the coverage, with the possibility to implement CRUD on ../scenes as well.

[jerstlouis]

SWG 2024-11-27: We agreed to move the Scenes requirements class to a future part in order to have the opportunity to do more experimentation, and define separate requirements classes for different aspects such as uploading new scenes, STAC item representations, etc.