new TAP-1.1 WD released

[Patrick Dowler]

Markus,

In svn commit 4220 I added entries to the core ivoabib.bib: DALI-1.1
and UWS1.1 (DALI11 and UWS11 respectively) and I updated the urls in
DALI and UWS so they resolve to the right version. I think that is the
right way to do it so that existing \citep{std:DALI} refers to
DALI-1.0.

All,

I have also pushed svn commit 4221 with PR-TAP-1.1 and I think that
captures/resolves all the issues raised in this discussion thread.

Thanks to everyone for the input - sorry if I missed something (quite
possible: things sometimes hide away in gmail).

Pat

PS-Marco: probably hold of on publishing until Markus says he has seen
this, just in case :-)

On 30 August 2017 at 00:49, Markus Demleitner
<msdemlei at ari.uni-heidelberg.de> wrote:
> 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



-- 
Patrick Dowler
Canadian Astronomy Data Centre
Victoria, BC, Canada