Hi Kona -
> Doug, are you suggesting that TAP has to provide a one-to-one mapping
> with a particular service implementation (the DAL service model you are
> referring to)?
TAP doesn't necessarily have to map one-to-one, but yes, I do think it is important that it be consistent with the other DAL protocols, unless there is a compelling technical reason to diverge (as already argued in my earlier postings and detailed analysis). We should start from this perspective, and see if the requirements of table access actually require that the approach differ in some areas. It may actually simplify the design problem considerably to do so, not to mention future implementations and client applications.
> Keeping TAP as simple as possible, at least in the first version, seems
> a sensible way to get broad implementation, compliance and deployment
> across the VO.
Of course a simple entry level is important - but we already have cone search and SkyNode, and TAP needs to be a step beyond these.
Yesterday I posted the following examples of what some simple TAP queries might look like. Do you feel that these are too complicated?
Example data queries
<baseURL>?REQUEST=queryData&TABLE=foo&POS=180,0&SIZE=0.2
<baseURL>?REQUEST=queryData&query=SELECT+*+FROM+a+WHERE+foo%3D2
Example metadata queries
<baseURL>?REQUEST=queryData&TABLE=schema.tables
<baseURL>?REQUEST=queryData&TABLE=schema.tables&POS=180,0&SIZE=0.2
<baseURL>?REQUEST=queryData&TABLE=schema.columns&TableName=foo
<baseURL>?REQUEST=queryData&TABLE=schema.columns&TableName=foo&FORMAT=xml
These are simple parameter and ADQL-based data queries, and queries for both table metadata and column data (based on the SQL information schema approach). Although it is not obvious from the examples, the table-level queries are extensible to support use of stageData to do large queries.
Comments?