TAP VOSI Information
Thomas.A.McGlynn at nasa.gov
Mon Nov 23 07:33:01 PST 2009
Douglas Tody wrote:
> On Wed, 11 Nov 2009, Tom McGlynn wrote:
>> It seems like the first step in specifying the real TAP response to
>> a VOSI capabilities request is understanding what information needs
>> to be there. Here's a first cut. I imagine there could be lots
>> of things that go in that don't have to do with TAP itself (e.g.,
>> copyright). I've not said anything about them. The indentation may
>> not survive mail, but I hope the intent is clear.
> This looks like it gets us 90% of the way there. Minor comments follow
> below. The main thing I see missing is whether the multi-position
> query is supported in PQL since this would be an advanced capability.
> The default and maximum values for MAXREC need to be specified.
> - Doug
I hadn't forgotten multi-position... At least in the current PQL draft,
the only place you can use uploaded tables is in the multi-position
query. So the service would specify that they supported multi-position
queries by giving the kinds of tables that a user can upload in PQL. A
service which did not support multi-position queries would specify no
supported sources for table uploads in PQL.
I had overlooked one of the most critical options though, the supported
Formats. Presumably the conventions adopted for the other DAL protocols
can be used here.
I'm not sure that row limits alone are enough. The database may have
BLOBs or CLOBs which could be very large. Currently we tend to store
metadata in the database and data in the file system, but with modern
database systems, storing the data in the database could make a lot of
sense. If a user has a 500 MB data file in each row, just a few rows
might be pretty nasty for a download.
I like your suggestion with regard to providing an indicator for the
underlying database. In addition to being useful, it would be
fascinating just to see what choices our colleagues make.
>> Key Values Discussion
>> Language The languages supported by the TAP service.
>> ADQL is required and this can be repeated as
>> many times as desired.
>> ADQL Required.
>> SQL Pass through of SQL queries. Reserved but not
>> ADQL.Access Methods through which ADQL can be accessed
>> Sync Required.
>> UWS Required.
>> PQL.Access Methods through which PQL can be accessed
> Same as for ADQL.
The options are the some, but unlike ADQL they are not required.
>> ADQL.TableSource Sources for tables uploaded in ADQL (none required)
>> PQL.TableSource Sources for tables uploaded in PQL multicone.
> Same as for ADQL.
>> ADQL.Geometries Supported geometries.
>> None No support for ADQL geometry.
>> Limited Default. Suggests some support but less than Basic.
>> Service is allowed to accept or reject any geometry
>> Basic Basic Geometry support (No intersects and one or
>> two other functions as mentioned in TAP)
>> Full All atomic geometry objects and functions
>> ADQL.Region The level of support for REGION in ADQL queries.
>> None No query with a REGION parameter will be accepted
>> Limited Default value. Suggests some support but less than
>> Simple. With this value the service is free to
>> accept or reject any REGION.
>> Simple Regions using accepted coordinate systems and a
>> single CIRCLE, BOX or POLYGON are supported.
>> Composite Regions using composites of the three basic regions
>> are accepted (as in latest STC-S note).
>> PQL.Region Same as for ADQL.Region.
>> ADQL.CoordSys Coordinate systems supported in ADQL
>> Taken from STC table. This should be repeated for
>> each supported coordinate system.
>> PQL.CoordSys Coordinate systems supported in PQL
>> UWS.DefaultExecutionTime Default execution time the service will
>> allow in UWS access (seconds?)
>> UWS.MaximumExecutionTime Maximum allowed execution time
>> UWS.DefaultDestructionTime Default time before results deleted.
>> UWS.MaximumDestructionTime Max time before results deleted
> These values will depend upon what the user is authorized to do.
> I guess it still works, e.g., if an authenticated connection is opened
> the values may be customized for the particular user. The values
> cached in the registry would be for the default, non-authenticated
>> VOSI.function VOSI supported capabilities
>> Availability Availability is supported.
>> Tables Tables is supported
>> Capabilities Required. Capabilities is supported.
>> --- I don't really want version negotiation in V1.0, but if it's there, then
>> Version 1.0 Required. Version of current interface.
>> SupportedVersions 1.0 Required
>> Other supported versions.
> Ok. So Version is the default version supported, with the other
> versions as specified in SupportedVersions. This is essential.
That's probably a better way of saying it.
More information about the dal