>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