Deprecating vs:ParamHTTP's testQuery?

[Markus Demleitner]

Dear Registry crowd,

Ten years ago, on April 15th, 2016, I did something fairly stupid.

This was when I added a testQueryString attribute to VOResource's
vr:Interface type.  It seemed an excellent idea at the time, because
I wanted to get rid of all the complex test data models in
SimpleDALRegExt (e.g., having separate entries for ra, dec, and sr in
the SCS extension). Why bother when you can just as well write a
normal urlencoded string -- or, for that matter, something else for
different protocols?

Except: vs:ParamHTTP, which arguably is the right place for this kind
of thing (because what we are aiming at with testQueryString is at
least pretty close to HTTP parameters), already had an equivalent
functionality: testQuery.  Why I had missed that I can't say.  At
least I get more sympathy for the inheritance skeptics (I'm impressed
how much wisdom you can find by asking your favourite search engine
for "Inheritance considered harmful").

The net result, anyway, is that vs:ParamHTTP now has children
testQuery and testQueryString; see here:
<http://docs.g-vo.org/schemadoc/schemas/VODataService_xsd/complexTypes/ParamHTTP.html>.

I think that is confusing and at least some explanation.  My first
instinct has been to just deprecate the more specialised testQuery,
and that's what I tried (with another little blunder) in
VODataService PR#7
<https://github.com/ivoa-std/VODataService/pull/7>.

Renaud did not like this on grounds that testQuery is in active use;
but then that's why we would be deprecating it rather than dropping
it, and we'd have plenty of time to nudge people towards
testQueryString.

However, the longer I consider the matter the less I like the
testQueryString on vr:Interface.  True, for many interfaces, even
ones that don't use urlencoded parameters, a single string could be
enough to produce a validatable result.  But it feels hackish and
wrong, and as people define new interface types, it's probably better
if they consider minimal input for validation purposes again rather
than trying to shoehorn everything into a testQueryString.

On top of that, as Renaud says, testQuery is in active use, whereas a
superficial grep through my registry's harvested records shows that
testQueryString is not.

So, here's my new plan: I'll leave vs:ParamHTTP's testQuery alone and
write a new PR against VOResource deprecating testQueryString.  And
we'd all be watchful that nobody tries anything with testQueryString
until the next VOResource REC.  If that happens, we'd put the
deprecation into an Erratum.

What do you think?

Thanks,

           Markus (with apologies)