<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&#39;s say.</div><div><br></div><div>No one prevents to have it as a sibling like before, it&#39;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">&lt;<a href="mailto:gmantele@ari.uni-heidelberg.de" target="_blank">gmantele@ari.uni-heidelberg.de</a>&gt;</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 &quot;service specific&quot;?<br>
    In TAP-1.0, it was set to &#39;/availability&#39;. 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 &quot;As required by<br>
    (Dowler and Demleitner et al., 2013)&quot;.  It would be a bit more<br>
    readable to see &quot;As required by DALI 1.0&quot; (possibly followed by<br>
    a reference).  I&#39;m not sure if that&#39;s something that can be<br>
    handled at that ivoatex level?  Anyway not essential.<br>
<br>
Abstract:<br>
    &quot;A multi-position query capability permits queries against an<br>
     arbitrarily large list of astronomical targets, providing a<br>
     simple spatial cross-matching capability.&quot;<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&#39;s inherited<br>
     from TAP 1.0 it may be preferred to leave it intact.<br>
<br>
Sec 1.2.6:<br>
    &quot;A TAP service must be able to support use of other query languages ...&quot;<br>
    This sounds like it&#39;s saying that all TAP services must have more<br>
    than one supported language.  Replace with something like<br>
    &quot;TAP allows for use of other query languages...&quot;?<br>
<br>
Sec 2:<br>
     &quot;... compatibility with TAP-1.0 (which required these names.&quot;<br>
     Add or remove a bracket.<br>
<br>
Sec 2.1:<br>
     &quot;Representations of results of queries if defined&quot; -&gt; &quot;is defined&quot;?<br>
<br>
Sec 2.4:<br>
     &quot;The content is described by [8].&quot;<br>
     This reference is hard coded into the LaTeX source, it doesn&#39;t<br>
     appear to point to any of the actual bibliography entries.<br>
<br>
Sec 2.6:<br>
     &quot;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.&quot;<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 &quot;A successful GET from this endpoint ...&quot;?<br>
<br>
     &quot;... element with simple text content having a property attribute<br>
      valued query&quot; and &quot;attributes having the value table&quot;:<br>
     These sentences would be more readable if the attribute values<br>
     mentioned were `quoted&#39; or {\em emphasized} or something, e.g.<br>
     &quot;... property attribute valued `query&#39;&quot; and<br>
     &quot;... having the value `query&#39;&quot;.<br>
<br>
Sec 2.7.2:<br>
     &quot;... schema, table, and column names, function names, and<br>
      other ADQL keywords are not case sensitive.&quot;<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>
     &quot;Within the ADQL query, the service must support the use of timestamp<br>
      values as described in  (Dowler and Demleitner et al., 2013)&quot;<br>
     This appears to be imposing an unnecessary (and meaningless) burden<br>
     on services with no date/time data.  Replace with something like<br>
     &quot;If timestamp comparisons are supported within ADQL queries,<br>
      they must use the syntax defined in ...&quot;?<br>
<br>
     &quot;Within the ADQL query, the following ADQL functions mus[t] be<br>
      supported: INTERSECTS, CONTAINS, POINT, CIRCLE, and POLYGON.&quot;<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 &quot;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&#39; constructs...&quot;, which made it clear that it was<br>
     permitted to avoid geometry support altogether.<br>
     I&#39;m not necessarily disagreeing with this change, but if it is<br>
     intended it&#39;s a significant difference, and should be noted<br>
     in the change log more prominently than the current text,<br>
     which just says &quot;Clarified required and optional ADQL<br>
     geometric functions&quot;.  Note also that as for the timestamp case,<br>
     it doesn&#39;t make much sense if there is no sky position<br>
     data in the service (e.g. RegTAP, EPN-TAP??)<br>
<br>
     &quot;Clients should avoid using the coordinate system argument to<br>
      geometric functions should not be used&quot; - 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>
     &quot;VOTable structure follows the rules in section 2.9&quot; -<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>
     &quot;If the output format is VOTable, section 2.9.1 describes ...&quot;<br>
     Non-existent sec 2.9.1 reference hard coded into the LaTeX source.<br>
<br>
Sec 3.5:<br>
     &quot;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).&quot;  If the output column is calculated and no<br>
      alias is supplied, you can&#39;t do either of those and have to<br>
      make up a FIELD name somehow.  Add &quot;where available&quot; or<br>
      similar to this sentence?<br>
<br>
Sec 4:<br>
     &quot;The qualified names in the tables of the TAP schema must<br>
      follow the rules defined in section 2.4.&quot;<br>
     Section 2.4 is hard coded into the LaTeX source, it&#39;s probably<br>
     not the intended reference target here.<br>
<br>
Sec 4.2:<br>
     The table_index column datatype is listed as &quot;char&quot;.<br>
     That looks like a mistake, probably &quot;int&quot; 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 &quot;int&quot; in the VOTable sense.<br>
<br>
     The description column datatype is &quot;char&quot;.  DaCHS at least<br>
     uses unicodeChar here.<br>
<br>
     The column_index column datatype is &quot;int&quot;.  DaCHS currently<br>
     uses short.  (See also table_index in TAP_SCHEMA.tables).<br>
<br>
     In both these cases, possibly others, I&#39;m not sure it&#39;s<br>
     necessary or helpful to be as prescriptive as that.<br>
<br>
     Similarly, mandating &quot;*&quot; as the arraysize value for the<br>
     various character data columns in these tables is<br>
     unnecessarily restrictive; there&#39;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 &quot;integer&quot; or &quot;string&quot; (or &quot;character array&quot;).<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>
     &quot;The client may have to check the phase multiple times until<br>
      the job finishes.&quot;<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&#39;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 &amp; Marco (DAL chair&amp;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>