TAP Implementation Notes

[Markus Demleitner]

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

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

>From your other mail:

> So: what about in a future revision of the TAP standard making
> the async mode optional rather than mandatory, while leaving
> sync mode mandatory?  TAPRegExt would need a corresponding edit
> to allow declaration of supported modes.
> 
> I have a vague impression that this might have been the subject of
> one of the great TAP Wars in which I was not intimately involved,
> so if it's too painful to reopen, pretend I didn't say it.

I've added some text on this to the notes draft.  It's not been a war
as far as I remember.  Personally, I've been skeptical about
requiring async, but looking back I'm happy we did it since otherwise
we'd probably have far fewer servers actually supporting async.
Having implemented TAP/async in both server and client, I think it's
a great technology and it would suck if we had less of it.

Of course, now that we have async implementations, and several of
them actually Free, we may think again about lowering the hurdles for
entering the Hall of Valid TAP Services...


Let me use this opportunity to stress that I have doubts, and
sometimes strong doubts, about several of the proposed measures (I
share, for example, Mark's doubts about changing the quote format) --
I mainly took them from the Wiki and reformulated them.

Part of the purpose of the publication is to figure out ("building
consensus") what to keep on "standards track" and what to dump on the
way.  So, let me again invite everyone involved in TAP and friends to
give their feedback (or to even work on the document in SVN).

Thanks,

       Markus