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.

[mbtaylor]

I'm looking at this again in relation to ObjObsSAP, which at time of writing is still in its WD-ObjObsSAP-1.0 phase, i.e. no RECs have been published.

When I made my earlier comment:

A proper fix for this is out of scope for a minor revision.

I was thinking of existing DALI-compliant standards like SCS, SIAP, TAP etc; we can't update the behaviour of those standards in minor updates because clients would break.

But given the problems that this issue is causing for OpenAPI etc, I wonder if we could relax this requirement as applied to new DALI-compliant standards, for instance by saying in DALI 1.2 that parameter names are case-insensitive unless the concrete DALI service specification says otherwise. It's then down to those concrete specifications to manage backwards compatibility (so TAP couldn't introduce case-sensitivity without breaking things, but ObjObsSAP could start off that way).

This would not lead to breakage of clients specific to a new standard like ObjObsSAP since there is no previous behaviour for the case-sensitive behaviour to differ from.

It could lead to breakage in clients implementing such new standards on top of existing generic DALI libraries, but I feel that new clients should be able to avoid doing that.

Comments?

[msdemlei]

On Mon, Apr 20, 2026 at 03:42:30AM -0700, Mark Taylor wrote: mbtaylor left a comment (ivoa-std/DALI#21) Comments?

I, for one, am all in favour of moving towards case-sensitive parameters as good as we can. That is, at least new specs should be case-sensitive. The old specs... ah well...

[gmantele]

Case-sensitive parameters seem the way to go for me too.

As I said before, I would follow the case-folding used until now in documents: most of the time, they are written in upper-case. In order to be as homogeneous as possible (and so, to lead to less surprises for users), I would encourage the upper-case practice in DALI compatible standards....again, as much as possible for new specs and then see what can be accomodate for old specs.

About ObjObsSAP, since it is still a WD and that we have two service and one client developers currently active, I think it would be fairly possible to change the case-folding in the document if we have to.