ADQL XMATCH

[Mark Taylor]

On Fri, 15 Apr 2016, Markus Demleitner wrote:

> Hi Mark,
> 
> On Thu, Apr 14, 2016 at 05:46:12PM +0100, Mark Taylor wrote:
> > 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
> 
> Well, it is if we say "Either implement all variants of a function or
> none".  You'd simply not be allowed to have:
> 
> > 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
> 
> Since it's usually not hard to morph in the ADQL engine between the
> two forms, I think that would be not unreasonable to specify in ADQL.

OK, if there is service provider agreement on that it would be fine
by me.  Obviously under that scheme TAPRegExts that are correct now
would become incorrect under future ADQL versions in absence of
service upgrades, so it would need to be identifiable from the
TAPRegExt which ADQL version was being targetted.

--
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/