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