ADQL XMATCH

[Mark Taylor]

On Tue, 12 Apr 2016, Markus Demleitner wrote:

> But DISTANCE has been chosen in the original design of ADQL, and I'm
> an enemy of changing thing that are not technically broken for
> essentially aesthetic reasons.  So, my vote is for keeping DISTANCE.

But *if* (not decided yet) we're changing the form of it from
2-arg to 4-arg, that would seem like a reasonable time for
a non-gratuitous change of the name.

Which thought nudges me to think about the consequences of
overloaded geometry functions for TAPRegExt.

TAPRegExt 1.0 sec 2.3 says this about declaring geometry functions:

    ivo://ivoa.net/std/TAPRegExt#features-adqlgeo
       Each feature declares support for one of the geometry functions
       defined by ADQL (support for these functions is in general optional
       for ADQL implementations, though TAP imposes some constraints on
       what combinations of support are permitted).

       The signature of these functions, where supported, is fixed
       by ADQL; the content of the form element is just the name of
       the function.

       Example:

       <feature>
         <form>CONTAINS</form>
       </feature>

but if we're talking about overloads, there is no uniquely fixed
signature for these functions.  In other words, TAPRegExt as
currently defined does not have enough syntax to declare selective
support for overloaded standard geometry functions - a TAP service
can't declare that it supports DISTANCE(POINT,POINT) but not
DISTANCE(REAL,REAL,REAL,REAL).  (note this doesn't apply to
user-defined functions, since ivo://ivoa.net/std/TAPRegExt#features-udf
does require declaration of signatures).

Does it matter?

--
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/