Collection Output: response=landingPage or not?

[jerstlouis]

Currently the requirement /req/collection-output/response-definition defines response as such:

name: response
in: query
required: false
schema:
  type: string
  enum: [ collection ]

and I had removed landingPage from the enum that was still there in response.yaml.

However, there is still a mention of redirecting to a landing page in rExecuteCollectionRedirect.yaml.

Can we confirm that we removed that landingPage response mode, and so we should remove those mentions of landing page redirect and response=landingPage there? The only capability we are losing is for clients that can only be pointed to a landing page rather than directly to a collection.

For returning multiple collections, that can now be done through results.yaml, either as separate one { "collection": ... } value for multiple outputs, or as multiple { "collection": ... } values for one or more outputs. We already have /req/collection-output/response-response-one and /req/collection-output/response-response-many, but now that we've added maxOccurs to outputs, I think the response-one should only apply when maxOccurs=1, so that the collection redirect is only when requesting one output and maxOccurs=1.

(also the draft seems to not be generated properly right now, maybe #571 will fix that)

[fmigneault]

The single { "collection": ... } could work also if supplied with ?response=collection&profile=https://www.opengis.net/def/profile/OGC/0/ogc-results.

I am not sure how a landingPage would be returned if results profile or multi-link with maxOccurs>1 was used in such case. Maybe using href, but confusing in contrast to "usual" href of minimal representation. Therefore, I would lean toward removing that use case, unless limited specifically to the maxOccurs=1 with Location header.

[jerstlouis]

@fmigneault yes that profile would basically override the redirecto the collection resource, and return results.yaml instead.

I think we had already agreed to remove the landing page, just double-checking.

[fmigneault]

I don't recall exactly what was the status, but since the enum is already defined without it, probably best to leave it at that to avoid diffs and merge quickly.