TAP discovery in 1.1

[Mark Taylor]

On Mon, 11 Sep 2017, Markus Demleitner wrote:

> I wonder: Is there anything we need to have the split sync/async
> capabilities in TAP 1 for?  Is it urgent (e.g., I'm not sure I find
> the ability to declare two different limits on the two endpoints
> proportional to the impacts the whole thing has)?  Are there
> alternatives?
> 
> If not, then, frankly, I'd much rather keep a single capability with
> the old ivo://ivoa.net/std/TAP standardID.

So would I.  I've always been sceptical/unenthusiastic about this
proliferation of registered endpoints for a TAP service, and
anything that hides it to some extent looks good to me.
I've had private discussions with CADC on this topic,
and I made a quickie presentation at Severin's request about
some of my concerns in Shanghai:

   http://wiki.ivoa.net/internal/IVOA/InterOpMay2017Apps/authcap.pdf

To the extent that I've thought about how to deal with TAP 1.1
from a client point of view (which isn't that much; although I've
read the standard I haven't attempted a client implementation)
I've mostly been putting my faith in the text from section 2:

   "At least one set of sync and async resources must be named
    /sync and /async respectively for backwards compatibility
    with TAP-1.0 (which required these names)
    ... 
    The fixed name resources above (async, sync, tables) should
    be used for the primary access mode of the service; this is
    typically anonymous access and other resource names may be
    used for authenticated access."

Having said that, as long as TOPCAT is using GloTS for TAP service
discovery, it is fairly insulated from these issues.  Of course if
the new registrations confuse GloTS sufficiently that it can't
reliably give me something I can treat as a base URL for each TAP
service out there, I'm in trouble.

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/