Some comments:
Ad 1
The effort appears to have lost momentum; it needs a kick.
Ad 2
Yes, don't bother with the parameterized queries.
Ad 4
I would suggest to make ADQL compliance mandatory, but to allow
different levels of compliance: with or without Region support and
with or without utype support. A service that supports neither is a
basic SQL service, but at least this has the advantage that the SQL
flavor used will be uniform.
Ad 5
I think it is absolutely necessary to require at least three output
formats: VOTable, HTML, and tab-delimited. It is silly not to allow
HTML for queries that return very small tables, and tab-delimited is
so universally useful that users will revolt if it's not available.
And providing these three formats is no great burden for providers.
Ad 7
SIAP returns URLs for staged data. What's wrong with allowing
asynchronous queries where the result is staged at the server's site
and the URL is returned to the client, at least for the first TAP
version? That should be simple to implement.
Roy Williams wrote:
[ Charset ISO-8859-1 unsupported, converting... ]
> This is my response to a double presentation this morning on the TAP
> protocol evolution, one from Tody, the other from Stebe/Osuna. I believe
> that this project has gained unacceptable mission-creep from its
> original conception as SIMPLE table access. I was VERY disturbed when
> Osuna joked today that this be renamed "General Access Protocol".
>
> Roy Williams
> -----------------------------------------
>
> (1) It was my impression at the beginning of the discussion a year ago
> that TAP would be a protocol to allow ADQL and/or SQL queries to be sent
> to a database, and a response to be obtained in table form.
>
> (2) The parameterized queries presented this morning should not be part
> of the TAP protocol. The language is not well defined, and would be
> difficult to implement. If a cone search is wanted, then the IVOA
> already has that specification, and TAP is not a replacement for cone
> search. It is no easier to write x="2.5/" than "select * where x>2.5",
> but adds a considerable burden in implementation, and the requirment to
> implement an open-ended parameter-based "language" that is not well-defined.
>
> (3) The presentation this morning suggested that error responses from
> TAP be encoded into the HTTP transport, for example HTTP 204 means "No
> Content". This is problematic on several grounds. First, no other IVOA
> protocol is bound to HTTP in this wat, so we have a new concept where, I
> believe, other ways already exist. Second, why should we bind ourselves
> to a particular transport layer like this? Third, the HTTP messages
> leave no room for elaboration -- for example *why* is there no content?
> I propose that errors can be reported as with other IVOA protocols: a
> VOTable with an INFO element.
>
> (4) I very much like the suggestion of three classes of query: the ADQL,
> the Utype query, the NativeSQL. The Utype method is a natural expression
> of the Source Catalog Data Model, so that the same query can be sent to
> many databases, and the NativeSQL allows an extremely easy
> implementation of TAP for some providers. I believe that none of these
> three should be mandatory. Thus each column of the table can have two
> names: the arbitrary one in the database table or view itself, and the
> IVOA standard Utype name.
>
> (5) Tables and table metadata are both tables, and the IVOA has adopted
> a standard representation for tables, it is called VOTable. I believe
> VOTable should be the principle way that relational schema and the table
> data should be returned from TAP, although other formats may be offered
> by implementers. Because tables and table metadata are unified, it means
> that querying the table metadata is no different from querying table
> data itself.
>
> (6) Please note that the IVOA Recommendation VOResource does NOT include
> a mechanism for expressing table metadata; rather it is VODataService
> that suggests this, and that is not yet defined even as Working Draft.
> It would be unwise to make TAP dependent on a controversial suggestion
> that is not yet even defined or documented. Obviously this could in the
> future be an optional expression of table metadata, but I suggest the
> IVOA should stick with the standards it has already ratified.
>
> (7) The asynchronous query mechanisms presented were rather different,
> and neither was satisfactory to me. Tody suggested a warping of what has
> been drafted (but not implemented) for other DAL services. Stebe/Osuna
> suggested a mechanism with no monitoring or notification that did not
> seem well thought out. I would like to suggest leaving asynchronous TAP
> for a future version, and concentrate on getting the plain, simple,
> synchronous version to Recommendation.
>
> (8) Neither presentation considered TAP queries on private data; how the
> query protocol can include an authentication token so that only a select
> group of people can launch queries. This is just as important as batch
> jobs on public data. I believe that this too should be handled in the
> next version of TAP.
>
>
Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots-at-head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/ --------------------------------------------------------------------------Received on 2007-05-17Z04:02:59