<p dir="ltr">AngDistance[24CP] ?</p>
<div class="gmail_quote">On Apr 14, 2016 2:25 PM, "Alex Szalay" <<a href="mailto:szalay@jhu.edu">szalay@jhu.edu</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Distance2/Distance4<br>
Or<br>
DistanceP (for points) / DistanceC (for coords) ?<br>
<br>
<br>
--Alex<br>
<br>
-----Original Message-----<br>
From: <a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a> [mailto:<a href="mailto:dal-bounces@ivoa.net">dal-bounces@ivoa.net</a>] On Behalf Of Mark Taylor<br>
Sent: Thursday, April 14, 2016 12:46 PM<br>
To: <a href="mailto:dal@ivoa.net">dal@ivoa.net</a><br>
Subject: Re: ADQL XMATCH<br>
<br>
On Tue, 12 Apr 2016, Markus Demleitner wrote:<br>
<br>
> But DISTANCE has been chosen in the original design of ADQL, and I'm<br>
> an enemy of changing thing that are not technically broken for<br>
> essentially aesthetic reasons. So, my vote is for keeping DISTANCE.<br>
<br>
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.<br>
<br>
Which thought nudges me to think about the consequences of overloaded geometry functions for TAPRegExt.<br>
<br>
TAPRegExt 1.0 sec 2.3 says this about declaring geometry functions:<br>
<br>
ivo://<a href="http://ivoa.net/std/TAPRegExt#features-adqlgeo" rel="noreferrer" target="_blank">ivoa.net/std/TAPRegExt#features-adqlgeo</a><br>
Each feature declares support for one of the geometry functions<br>
defined by ADQL (support for these functions is in general optional<br>
for ADQL implementations, though TAP imposes some constraints on<br>
what combinations of support are permitted).<br>
<br>
The signature of these functions, where supported, is fixed<br>
by ADQL; the content of the form element is just the name of<br>
the function.<br>
<br>
Example:<br>
<br>
<feature><br>
<form>CONTAINS</form><br>
</feature><br>
<br>
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://<a href="http://ivoa.net/std/TAPRegExt#features-udf" rel="noreferrer" target="_blank">ivoa.net/std/TAPRegExt#features-udf</a><br>
does require declaration of signatures).<br>
<br>
Does it matter?<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mbt/</a><br>
</blockquote></div>