TAP Implementation Notes

[Mark Taylor]

On Thu, 11 Oct 2012, Markus Demleitner wrote:

> Hi,
> 
> 
> On Tue, Oct 09, 2012 at 03:37:09PM +0100, Mark Taylor wrote:
> > On Mon, 8 Oct 2012, Markus Demleitner wrote:
> > > http://wiki.ivoa.net/twiki/bin/view/IVOA/TAPImplementationNotes -- a
> > > collection of various things regarding TAP that need clarification or
> > > improvement -- for a while now.  I've finally tackled it, and the
> > > (intermediate) result is at 
> > > https://volute.googlecode.com/svn/trunk/projects/dal/TAPNotes/TAPNotes-fmt.html
> > ADQL: Empty Coordinate Systems:
> >    SCENTROID, ... (for Simple).  [Um, unless ADQL permits function
> >    overloading by parameter count/type, but I have the impression
> >    it doesn't.]
> It does; if there's a consensus that this is desirable, I'd try to
> write up a grammar extension that allows both forms.  And since

If there's no (serious) syntactic or implementation problem with
overloading to make the first parameter optional, that gets my vote.

> current behaviour as to what to do with these first arguments is
> basically unspecified, it's easy to recommend to ignore them without
> breaking compatibility.

I see this in the definition of CONTAINS (ADQL Sec 2.4.6):

   "Since the two argument geometries may be expressed in different
    coordinate systems, the function is responsible for converting one
    (or both). If it cannot do so, it SHOULD throw an error message,
    to be defined by the service making use of ADQL."

It looks to me like ignoring those parameters (in the case that they
are not identical) would violate this RECOMMENDation.

> 
> > TAP: Inline Table Uploads Sanitized:
> >    I'm not sure what problem ("somewhat fragile") this is trying to solve.
> >    The new proposed upload format doesn't look immediately objectionable,
> >    but I'd hesitate to agree with the change without trying to implement
> >    it first.
> Well, first off I'd like to have "less referencing"; right now, you're
> referencing one parameter for another, which is always a pain, in
> particular if you allow posting parameters later (I *think* the
> current text would allow to first post BAR=<file xy> and in a
> different request UPLOAD=xy:BAR).
> 
> Another, and potentially more important problem is that a "generic"
> UWS frontent will in general serialize posted parameters into
> something like a database.  For file uploads, you really don't want
> to do this, and so it's nice to be able to tell *from a single
> control* whether something is a file upload or not.
>
> But maybe what this says is that uploads should really be talked
> about on a UWS level?

OK I can see that the existing definition does not look like the cleanest
way to do it (and now vaguely remember client-side implementation
complications related to it, though the problems must be worse
for server implementation).  Whether the disruption of changing
at this stage is worth the effort is another matter.

Mark

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