unrecognized custom parameter and optional parameters responses

[molinaro-m]

ConeSearch states (end of §2.1)

If a query includes an optional parameter, either one specified by this document or not, that is not supported by the service implementation, the service must ignore that parameter.

This looks like silent failure.
Maybe we can suggest (a SHOULD?) to add <INFO> elements reporting the unused parameters.

[Zarquan]

Quietly ignoring an unknown parameter and not reporting it is a recipe for a really bad end user experience. What if it is a known parameter but the user misspills it ? If this query is part of a larger workflow it could take hours to track it down.

Good software should fail early and fail loudly.

[molinaro-m]

Reporting considerations from DAL Running Meeting 21.

Reporting parameters parsing messages from the server-side is probably easy. The difficult part is consuming that information on the client-side (involves a lot of business logic).

So, mandating a report here seems too much but encouraging it seems appropriate to avoid silent failure without giving a chance to investigate response behaviour.

[molinaro-m]

Closed in #66 via c130f9b

[msdemlei]

I'd very much like it if we gave specific guidance as to how the INFO regarding the ignored parameters should look like. Following VizieR practicce, I'd say a name="warning" should give clients enough of a chance to do something smart.

Perhaps an example could make a bit clearer what we are hoping for? Such as:

<INFO name="warning"
  value="The following parameters you passed are not evaluated by this service and are hence ignored: MASS, MAG_K, MAG_J"/>

[molinaro-m]

Pull Request #68 set up as a reply to @msdemlei feedback.