[PQL] scope

[Douglas Tody]

Hi Pat -

On Mon, 23 Mar 2009, Patrick Dowler wrote:

> On 2009-03-23 09:59:13 Doug Tody wrote:
>> REGION and MTIME should be provided as well, but could be considered
>> optional advanced capabilities.
>
> So from this would it be correct to say that you would advocate adding
> standard non-query parameters to the P?? document? That is:
>
> MTIME
> MAXREC
> FORMAT
>
> note: REGION is already described in PQL-0.1 as a standard (query) parameter.
>
> And it sounds like Roy would advocate a standard UPLOAD parameter, as that
> would mean that any service that accepted P?? would be more or less a
> multicone service (not counting what kind of content was in or out of the
> cone :-).

In order to avoid duplication of information and version
inconsistencies it is probably better to define the "common" parameters
as part of the main TAP spec.  These are the parameters which are
used for TAP functionality which is the same regardless of how a
query is posed, e.g., FORMAT, MAXREC, and UPLOAD, anything related
to future VOSpace integration, etc.  It would make sense to merely
refer to these briefly in the param or ADQL specs, but have the main
TAP spec fully specify what these do since they are common to all
the query methods and part of the basic TAP service functionality.

In the case of MTIME it might be sufficient to define this only for
the parameter query (as Gerard I think suggested as well).  MTIME is
a parameter query constraint hence belongs with the parameter query
and is not really consistent with the ADQL query.

> Adding these kinds of parameters to P?? would make it a "standard DAL
> parameters" spec and not (just a) query parameter spec.
>
> Note: As with ADQL, the P?? document would specify all these parameters but
> not make any mandatory or optional. A service spec would say "these
> parameters from P?? are mandatory" and "these parameters from P?? are
> optional" and just provide lists of parameters and possibly explanations of
> how they are used (depending on how specific or general P?? is).

Things like FORMAT, MAXREC, and MTIME are actually parts of the generic
DAL2 service interface as you suggest, since they are independent
of the type of data being accessed.  However that makes them part
of the basic service interface and not specific to some specific
query language or method.  We should define these as part of the
standard DAL2 architecture and generic dataset query in addition
to each service interface, however as others (e.g., Alberto) have
pointed out, it is unrealistic to assume that service and application
implementors will carefully real half a dozen IVOA documents just
to use or implement a service (and somehow get it all right in the
process).  We should instead define these basic parameters rigorously
in each versioned service interface, and supplement this with the
architecture specification which will provide additional insight into
how the different types of services relate to each other.  In all
cases the actual data-specialized and versioned service interface
should take precedence over more generic service interface or data
model specifications.

The TAP parameter query spec should be straightforward and explicit,
defining rigorously how to access tables, tablesets, and table metadata
with parameter-based queries.  Much of this functionality is specific
to accessing tables.  The other DAL interfaces such as SIA, SSA, etc.
function differently since they are each accessing a different kind
of data, with a different data model and semantics, and are doing
things such as virtual data generation.  There will be similarities,
but many key differences as well.  A catalog query and a query used
to generate image cutouts, extract spectra (or whatever), are very
different in the detailed semantics, even though they might appear
superficially similar.

 	- Doug