new TAP-1.1 WD released

[Markus Demleitner]

Hi,

On Tue, Aug 29, 2017 at 05:11:47PM -0700, Patrick Dowler wrote:
> 1. Mark Taylor's comment about a sentence in section 4: I can't
> actually figure out what I was trying to refer to there (probably the
> limited table name syntax allowed in UPLOAD), but it seems like this
> was limiting allowed table and column names more than ADQL. I can't
> find any notes that we decided to do that and it doesn't seem likely
> so I am inclined to justb remove that sentence/paragraph. Comments?

That's, I think, Mark's comment
(http://mail.ivoa.net/pipermail/dal/2017-July/007769.html):

> Sec 4:
>     "The qualified names in the tables of the TAP schema must
>      follow the rules defined in section 2.4."
>     Section 2.4 is hard coded into the LaTeX source, it's probably
>     not the intended reference target here.

What this refers to is, I think (and that's supported by "acceptable
as an operand of a query" language in the WD just after what Mark
quotes), that the table names must be in the form the service accepts
them in a query.  That's non-trivial in that in means that if you
expect schema names, you have to give them here, and if you have
delimited identifiers for whatever reason, the quotes need to be both
in tap_schema.tables (and consequently tap_schema.columns) and in
VOSI tables.

I could dig out the discussion that lead to this decision; it's not
pretty, but I don't think you can write a robust client with any
other convention.

I guess the "Section 2.4" was intended to go to the VOSI /tables
chapter (currently 2.5). That, however, doesn't say a lot about that
issue.  Also, section 4.2 already has clear language on table name
literals in tap_schema.

In sum, I think you're right, the paragraph can go; if it stays in,
we'd have to refactor the explanation of table name literals so
what's now in 4.2 would end up in 2.5.

> 2. Mark also suggested that we mention the blocking get from UWS-1.1
> as an alternative to polling in the section with examples. Right now
> UWS is loosely coupled and someone could implement TAP-1.1 with
> UWS-1.0 or later ... Do we want that or do we want to reference and
> require UWS-1.1 or later?

I'd say something like "With TAP services behind UWS 1.1 \citep{...}
clients can greatly save on the polling overhead by using slow
polling, and are therefore encouraged to support this." in a suitable
place in 5.1.3 wouldn't tie TAP 1.1 to any particular UWS version and
still have great practical benefits.  So, I'm all for it.  I'd even
support including a very brief informational text on how to see
that a service supports UWS 1.1 and what to do to use slow polling
then.

          -- Markus