Emmanuel Mathot

> This looks generally good, but a couple of thoughts (for here and partially also the API): > > * headers: Shouldn't this be strictly just be a `Map`? >...

> `keywords`: Wait for #1199 to be merged, then we can PR it into common metadata and directly remove keywords from the collection schema, too. #1199 is not a PR....

ok. I can help with that if needed.

I am not sure we can easily transfer those information that were describing the file to one or more raster bands. There are several cases that should be supported and...

That is really tricky. We should avoid add raster bands to non raster assets. I would create a default raster band so that we do not loose the information ....

@duckontheweb to answer your question in previous discussion: In DotNetStac, I implemented Option 3 with a versioning mechanism reading previous versions (if implemented) with upgrading functions to latest version.

Discussion in STAC meetup: use `Map` that is also an object and thus not break STAC API spec

> If you use the version extension, then you will need the processing timestamp in the ID as you'll need two distinct Items which you can link between. Storing them...

What is proposed is not contradicting the principle of uniqueness of the ids. You can manage multiple version of the same STAC Item with a unique id but 2 different...

@m-mohr @matthewhanson What are the arguments to make title an option in collections. I may write the ticket in https://github.com/opengeospatial/ogcapi-common but I need to justify it.