ADQL XMATCH

[Mark Taylor]

you're right - OK.

On Fri, 15 Apr 2016, Patrick Dowler wrote:

> From our VOSI-capablities resource:
> 
> 
> <language>
>       <name>ADQL</name>
>       <version ivo-id="ivo://ivoa.net/std/ADQL#v2.0">2.0</version>
>  ...
> 
> 
> So yes we can do that now and I would be fine with having to provide
> all overloaded versions if we go that way.
> 
> On 15 April 2016 at 08:42, Patrick Dowler <pdowler.cadc at gmail.com> wrote:
> > From our VOSI-capablities resource:
> >
> >
> > <language>
> >       <name>ADQL</name>
> >       <version ivo-id="ivo://ivoa.net/std/ADQL#v2.0">2.0</version>
> >  ...
> >
> >
> > So yes we can do that now and I would be fine with having to provide
> > all overloaded versions if we go that way.
> >
> >
> >
> > On 15 April 2016 at 02:24, Mark Taylor <M.B.Taylor at bristol.ac.uk> wrote:
> >> 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/
> >
> >
> >
> > --
> > Patrick Dowler
> > Canadian Astronomy Data Centre
> > Victoria, BC, Canada
> 
> 
> 
> -- 
> Patrick Dowler
> Canadian Astronomy Data Centre
> Victoria, BC, Canada
> 

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