Clarification on limit parameter ...

[pvretano]

Consider that a server has specified that the min and max values for the limit parameter are 10000. If a client then makes a request for 50000 records should the server throw an exception (since 50000 is greater than 10000) or should it simply return 10000 records?

[nmtoken]

My gut feeling is it should return 10000 records.

You could write the spec to say either must return, must not return, or may return... the latter a bit like in existing (WMS, WFS..) OGC specifications with duplicate params.

What behaviour is specified for requests larger than a specified bounding box or time period, that would be analogous.

[cholmes]

I agree it should return 10000 records, and then be sure to have numberReturned be 10000, so the client knows how many it got back. With numberMatched still reporting accurately, so they can page through if there's more.

[cportele]

Meeting 2020-04-27: Nothing to clarify, this is already what is said in
http://docs.opengeospatial.org/DRAFTS/17-069r4.html#_response_6 (see the third bullet):

So (using the default/maximum values of 10/10000 ...):

• If you ask for 10, you will get 0 to 10 (as requested) and if there are more, a next link;
• If you don’t specify a limit, you will get 0 to 10 (default) and if there are more, a next link;
• If you ask for 50000, you might get up to 10000 (server-limited) and if there are more, a next link;
• If you follow the next link from the previous response, you might get up to 10000 additional features and if there are more, a next link.

[jampukka]

What about the other way, say limit=-5, should you get 0 to 1 or 0 to 10? Using minimum/default values of 1/10. Or is this a bad request?

[tomkralidis]

Should we consider a limit (integer) property that conveys the default limit at the collection info (or landing page) level?

[jerstlouis]

As I mentioned in Common, I see it as a major interoperability issue that the server may potentially return an error because of a limit query parameter with a value larger than it can return. I suggest that Common and a future update to Features could upgrade that recommendation to return "something" regardless of the value of limit, even though it might be less elements than asked, to a requirement. I believe this is a non-breaking change as any server not already implementing it this way could easily be fixed to conform to the new version without affecting existing clients.

As I see it, the client specifying limit is simply saying "I cannot handle more than this many items", so it does not make sense for the server to return an error saying "I cannot return you that many items". All servers already return less items than the client-specified limit asks for if there doesn't exist that many items in the collection.

[jampukka]

I think we don't allow servers to return an error if the value of limit parameter exceeds the server limit?
From https://docs.ogc.org/is/17-069r3/17-069r3.html#_response_6

So (using the default/maximum values of 10/10000 from the OpenAPI fragment in requirement /req/core/fc-limit-definition):
- If you ask for 10, you will get 0 to 10 (as requested) and if there are more, a next link;
- If you don’t specify a limit, you will get 0 to 10 (default) and if there are more, a next link;
- If you ask for 50000, you might get up to 10000 (server-limited) and if there are more, a next link;
- If you follow the next link from the previous response, you might get up to 10000 additional features and if there are more, a next link.

[jerstlouis]

@jampukka From how I read it, I believe it still does not require the server to consider the request successful if the client requests a larger limit than the server supports:

If you ask for 50000, you might get up to 10000 (server-limited)

I read this as meaning you might also not and get a 400 error, and we did run into servers implementing it this way (which were subsequently fixed based on the discussions in Common).

The server likely has a default value for the limit, and a maximum limit.

It's also not clear what the maximum limit means. I believe it should be clarified that the server cannot return an error if the client request a limit larger than that maximum limit, but that it is the maximum number of results the server can return regardless of any limit specified by the client.

[jampukka]

Maybe we do need a clarification then. Following the same pattern of the first two bullets, would If you ask for 50000, you will get 0 to 10000 (server declared maximum) and if there are more, a next link; make it clear enough?

Maybe declaring minimum/default/maximum values only in the OpenAPI document is not the best solution especially as we require the server not to validate the parameter against its' own OpenAPI definition/schema. Somewhat related #538

[jerstlouis]

@jampukka I think that would be a good thing, but it is still only explanatory text though -- I think Requirement 21 would need something like:

C) The server SHALL ignore limit parameter values greater than supported, 
rather than responding with an error.

Good point about the OpenAPI document and not rejecting a client's limit not conforming to maximum... I am not sure how acceptable it is to define a maximum but not respond with an error if the value exceeds that maximum?

[joanma747]

This might be better:

C) The server SHALL return the maximum possible number of items if the limit 
parameter values greater than the one the server supports, rather than responding with an error.