<div dir="ltr">Hi Grégory,<div>I think it comes out of the request I made in Sydney, to have</div><div>availability free from being a sibling to the query resource.</div><div><br></div><div>This is to allow status check of the resource also when the </div><div>resource is down. External monitoring, let's say.</div><div><br></div><div>No one prevents to have it as a sibling like before, it's</div><div>just an additional chance.</div><div><br></div><div>Cheers,</div><div> Marco<br><div class="gmail_extra"><br><div class="gmail_quote">2017-07-21 16:00 GMT+02:00 Grégory Mantelet <span dir="ltr"><<a href="mailto:gmantele@ari.uni-heidelberg.de" target="_blank">gmantele@ari.uni-heidelberg.de</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi DAL,<br>
<br>
I have just a short question (for the moment) about this TAP-1.1 draft:<br>
<br>
Sec 2:<br>
Is there a particular reason why the resource name of the anonymous VOSI-availability is now "service specific"?<br>
In TAP-1.0, it was set to '/availability'. I can understand for the authentified version of this resource but not for the anonymous one.<br>
(sorry in advance if this point has already been discussed before)<br>
<br>
Cheers,<br>
Grégory<div class="HOEnZb"><div class="h5"><br>
<br>
<br>
On 07/20/2017 01:30 AM, Mark Taylor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi DAL,<br>
<br>
here are some comments on the recent TAP-1.1-20170707-WD.<br>
<br>
Reference style:<br>
The text has quite a few references like "As required by<br>
(Dowler and Demleitner et al., 2013)". It would be a bit more<br>
readable to see "As required by DALI 1.0" (possibly followed by<br>
a reference). I'm not sure if that's something that can be<br>
handled at that ivoatex level? Anyway not essential.<br>
<br>
Abstract:<br>
"A multi-position query capability permits queries against an<br>
arbitrarily large list of astronomical targets, providing a<br>
simple spatial cross-matching capability."<br>
This comment seems a bit opaque, I suppose it is alluding to<br>
upload queries, but not in a very straightforward way.<br>
Could be removed or reworded? However, since it's inherited<br>
from TAP 1.0 it may be preferred to leave it intact.<br>
<br>
Sec 1.2.6:<br>
"A TAP service must be able to support use of other query languages ..."<br>
This sounds like it's saying that all TAP services must have more<br>
than one supported language. Replace with something like<br>
"TAP allows for use of other query languages..."?<br>
<br>
Sec 2:<br>
"... compatibility with TAP-1.0 (which required these names."<br>
Add or remove a bracket.<br>
<br>
Sec 2.1:<br>
"Representations of results of queries if defined" -> "is defined"?<br>
<br>
Sec 2.4:<br>
"The content is described by [8]."<br>
This reference is hard coded into the LaTeX source, it doesn't<br>
appear to point to any of the actual bibliography entries.<br>
<br>
Sec 2.6:<br>
"A GET from this endpoint MUST yield a document with a MIME<br>
type of either application/xhtml+xml or text/html.<br>
A service that does not provide examples MUST return a 404 HTTP<br>
status on accessing this resource."<br>
The intention is reasonably clear, but taken literally this says<br>
that even the 404 response must be application/xhtml+xml or text/html.<br>
Write instead "A successful GET from this endpoint ..."?<br>
<br>
"... element with simple text content having a property attribute<br>
valued query" and "attributes having the value table":<br>
These sentences would be more readable if the attribute values<br>
mentioned were `quoted' or {\em emphasized} or something, e.g.<br>
"... property attribute valued `query'" and<br>
"... having the value `query'".<br>
<br>
Sec 2.7.2:<br>
"... schema, table, and column names, function names, and<br>
other ADQL keywords are not case sensitive."<br>
I think this neglects the case of delimited identifiers.<br>
I will leave it up to Markus or some other SQL ninja to<br>
come up with replacement text.<br>
<br>
"Within the ADQL query, the service must support the use of timestamp<br>
values as described in (Dowler and Demleitner et al., 2013)"<br>
This appears to be imposing an unnecessary (and meaningless) burden<br>
on services with no date/time data. Replace with something like<br>
"If timestamp comparisons are supported within ADQL queries,<br>
they must use the syntax defined in ..."?<br>
<br>
"Within the ADQL query, the following ADQL functions mus[t] be<br>
supported: INTERSECTS, CONTAINS, POINT, CIRCLE, and POLYGON."<br>
This is introducing a new requirement for TAP 1.1, namely that<br>
geometry support is mandatory. In TAP 1.0 the equivalent passage<br>
was qualified by the text "If the tables that are queried<br>
through a service contain columns with spatial coordinates<br>
and the service supports spatial querying via the ADQL<br>
`region' constructs...", which made it clear that it was<br>
permitted to avoid geometry support altogether.<br>
I'm not necessarily disagreeing with this change, but if it is<br>
intended it's a significant difference, and should be noted<br>
in the change log more prominently than the current text,<br>
which just says "Clarified required and optional ADQL<br>
geometric functions". Note also that as for the timestamp case,<br>
it doesn't make much sense if there is no sky position<br>
data in the service (e.g. RegTAP, EPN-TAP??)<br>
<br>
"Clients should avoid using the coordinate system argument to<br>
geometric functions should not be used" - redundant text.<br>
<br>
Sec 3.1:<br>
This section looks like it could be mostly or completely replaced<br>
by a reference to DALI. Was this considered?<br>
<br>
Sec 3.2:<br>
"VOTable structure follows the rules in section 2.9" -<br>
The reference to the (non-existent) section 2.9 is hard-coded<br>
into the LaTeX source and needs to be replaced.<br>
<br>
Sec 3.4:<br>
"If the output format is VOTable, section 2.9.1 describes ..."<br>
Non-existent sec 2.9.1 reference hard coded into the LaTeX source.<br>
<br>
Sec 3.5:<br>
"For result tables, the column name or an alias specified in<br>
the query is used to set the name attribute of the FIELD<br>
elements in the output table (the alias overrides the normal<br>
column name)." If the output column is calculated and no<br>
alias is supplied, you can't do either of those and have to<br>
make up a FIELD name somehow. Add "where available" or<br>
similar to this sentence?<br>
<br>
Sec 4:<br>
"The qualified names in the tables of the TAP schema must<br>
follow the rules defined in section 2.4."<br>
Section 2.4 is hard coded into the LaTeX source, it's probably<br>
not the intended reference target here.<br>
<br>
Sec 4.2:<br>
The table_index column datatype is listed as "char".<br>
That looks like a mistake, probably "int" was intended - but<br>
see below.<br>
<br>
Sec 4.3:<br>
The datatypes for columns indexed, principal and std are<br>
listed as boolean. In TAP 1.0 they were integer with<br>
value 0 or 1 indicating false or true. Changing them<br>
to boolean therefore looks like breaking backwards<br>
compatibility, and additionally I believe(?) makes them<br>
impossible to query in standard ADQL, which lacks boolean tests.<br>
So I think these have to go back to an integer type,<br>
though not necessarily "int" in the VOTable sense.<br>
<br>
The description column datatype is "char". DaCHS at least<br>
uses unicodeChar here.<br>
<br>
The column_index column datatype is "int". DaCHS currently<br>
uses short. (See also table_index in TAP_SCHEMA.tables).<br>
<br>
In both these cases, possibly others, I'm not sure it's<br>
necessary or helpful to be as prescriptive as that.<br>
<br>
Similarly, mandating "*" as the arraysize value for the<br>
various character data columns in these tables is<br>
unnecessarily restrictive; there's no reason that<br>
services should not return fixed-width character array<br>
columns here if they want to.<br>
<br>
In general I think all of the TAP_SCHEMA table columns<br>
defined in sections 4.1-4.4 should be described using the<br>
generic terms either "integer" or "string" (or "character array").<br>
Mandating VOTable datatype and arraysize attributes looks<br>
to me like introducing more problems than it solves.<br>
<br>
Sec 5.1.1:<br>
"The client may have to check the phase multiple times until<br>
the job finishes."<br>
If the service implements UWS 1.1, this is no longer necessary,<br>
since you can do a blocking poll. Should we mention this here?<br>
Maybe mention it in sec 5.1.3 as well.<br>
<br>
References:<br>
The citations of DALI and UWS are both to the 1.0 versions of<br>
those standards. Should they be 1.1 in both cases?<br>
I'm not totally sure in any case how the TAP 1.1 version relates<br>
to the versions of other standards (e.g. does TAP 1.1 service have to<br>
support UWS 1.1?) Maybe this could be discussed in the text<br>
somewhere.<br>
<br>
I have also made a few typo corrections at rev 4190.<br>
<br>
Mark<br>
<br>
On Wed, 12 Jul 2017, Marco Molinaro wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear all,<br>
this is to inform you that a new WD for TAP-1.1<br>
has been released on the IVOA Document Repository<br>
<br>
<a href="http://www.ivoa.net/documents/TAP/20170707/" rel="noreferrer" target="_blank">http://www.ivoa.net/documents/<wbr>TAP/20170707/</a><br>
<br>
(change-logs available through volute)<br>
This is expected to be the last WD for version 1.1<br>
and we plan to promote it to PR soon enough to<br>
allow closing RFC before Santiago Interop, i.e.<br>
end of July/start of August, considering the northern<br>
summer vacation period.<br>
<br>
Please read through it and comment!<br>
<br>
Cheers,<br>
François & Marco (DAL chair&vice)<br>
Pat (TAP editor)<br>
<br>
</blockquote>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bris.ac.uk" target="_blank">m.b.taylor@bris.ac.uk</a> <a href="tel:%2B44-117-9288776" value="+441179288776" target="_blank">+44-117-9288776</a> <a href="http://www.star.bris.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bris.ac.uk/~mb<wbr>t/</a><br>
</blockquote>
<br>
<br>
</div></div></blockquote></div><br></div></div></div>