TAP VOSI Information

[Douglas Tody]

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



> 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.
>           PQL
>           SQL      Pass through of SQL queries.  Reserved but not
>                    defined.
> 
> 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.

> ADQL.TableSource   Sources for tables uploaded in ADQL (none required)
>
>           Parameter
>           URL
>           VOSpace
> 
> 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
>                    construct.
>           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
access.

> 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.

> --- Should we consider the following?  [Different for Sync/UWS?]
> 
> RowLimit             The maximum number of rows that will be returned
>                      in any single query.
> ByteLimit            The maximum number of bytes that may be returned
>                      in any single query.

I think what we need is more like

     DefaultRowLimit     Default value of MAXREC
     MaximumRowLimit     Maximum allowable value of MAXREC (0 if none).

I doubt if ByteLimit is needed if we already have RowLimit.

> UploadRowLimit       The maximum number of rows that may be uploaded
>                      (per table? total?) in a query.
> UploadByteLimit      The maximum number of byte that may be uploaded.

Not sure a ByteLimit is needed here.  Just UploadRowLimit.

As with execution time, these values could depend upon per-user
authorization.

> 
> ---  Do we want to identify agents and servers?
> 
> TAPServerType        Identifies the software used in the TAP
>                      service.

We need to identify the SQL back-end (vendor and version) in order to
support SQL pass-through.