Case sensitive params

[Zarquan]

Allowing param names to be case insensitive makes it harder to write a DALI compatible service using modern development frameworks.

DALI/DALI.tex

Lines 580 to 586 in f86401e

	\subsection{Case Sensitivity}
	Parameter names are not case sensitive; a DAL service must treat
	\hbox{upper-,} \hbox{lower-,}
	and mixed-case parameter names as equal. Parameter values are case sensitive
	unless a concrete DAL service specification explicitly states that the values of
	a specific parameter are to be treated as case-insensitive. For example, the
	following are equivalent:

Almost all of the current development tools assume that param names will be case sensitive. This adds yet another bit of friction that new developers have to contend with.

[pdowler]

This is largely a historical issue; DALI is to a large extent a refactoring of existing practices (eg existing RECs) so that they become consistent practices... I don't disagree that this causes pain for developers, but I think the idea was to not cause pain for users.

Specifically, it combines with another common practice: services should ignore any params they don't grok so clients can add "junk" without breaking anything. The reason this is related is that you can't have this "silently ignore" and help users when they use the wrong case for a param name without making assumptions.... eg service accepts upper case POS={something} and a user might include "pos=circle 12 34 1" by mistake or they might intentionally include "pos=uncertain" to tag a request for their own purposes. The service can either ignore "pos" or give an error due to unknown parameter input (which might help the first case but break the second)

[mbtaylor]

A proper fix for this is out of scope for a minor revision. But we could add in section 4.1 a strong recommendation for clients to use uppercase only (or lowercase only) when specifying parameters, in the hope that it will ease the transition if we mandate case-sensitivity in a future DALI update.

[gmantele]

Since it is something more or less required by OpenAPI, I think having at least for the moment a section encouraging a particular case folding is a very good approach. So, I entirely support the idea of @mbtaylor

The real question is: when do we envision the strict case folding in DAL standards?

[pdowler]

Over in PR #58 I wrote the param names in upper (style) so we probably need to pick which case is the long term goal. I was not intending that to be strict at this point, but it is time to be careful. I should add some looking forward text as part of that PR...

in my opinion: lower case.

[gmantele]

I agree. And I would also go for lower case, but if users/clients use more often the upper case maybe upper case should be our choice because it won't break most of the clients or users habits.

[gmantele]

We may have to investigate a bit among existing clients.

[mbtaylor]

I can't guarantee that I've been totally consistent about it, but it looks like TOPCAT and STILTS use upper case for parameter names when submitting Cone, SIA, SSA and TAP requests.