[TABLE] Re: TAP1.0 Comments

[Douglas Tody]

Patrick Dowler a écrit :
> 
> A legal ADQL query will not produce multiple
> tables. Since PQL is under development, it could in principle (and
> either could in future) be extended so that it could produce multiple
> TABLEs. The wording of this section should probably be improved to
> make it clear that this is not a TAP limitation per se, but rather
> must an indication of what current languages actually do.

As someone else suggested, a sufficient solution to this problem for
now is to just reword this section of the main TAP spec so that a
specific query method (such as PQL) is allowed to return more than
one TABLE or RESOURCE in a single output VOTable.

On Tue, 21 Jul 2009, Francois Bonnarel wrote:
> 
> I think I understand all the good reasons for the single TABLE output,
> in the case of ADQL and reloadable PQL queries.
> 
> But having the possibility to request and extension using for example
> a PQL "Extension" parameter, will allow a lot of use cases we have
> to be taken into account.
> 
> It would not be a major issue to assume that an output obtained with this
> feature will not be UPLOADable to another TAP service. 
> 
> Structured VOTABLES should not be forbidden in the VO. Model
> Associations (contrary to aggregations) are not well taken into account
> by jointures. Not only Vizier and Simbad outputs but also SSA/SIA
> Extension mechanism (see SSA Recommandation for details) which we use
> for footprints with Aladin and Virgo are examples of that. Probably
> GDS, if it is to be implemented in TAP, which I think is a good idea,
> if we want to extend it to complex data (see DAL2 architecture Note
> for details of what that means) could take benefit of such a feature.

The GDS query as currently proposed in PQL already has some support
for complex data in that associations and data links can be described
(which we think is sufficient to model complex data associations and
standard views).

The associations are part of the main table query response.  Fetching
the data links for a given object would currently require a separate
query since there is a many-to-one relationship hence a separate table
is used for the data links.  One possible solution here might be to
optionally include the data links in the query response as a separate
table.  This would still not include all the data pointed to (which is
probably unwise in a general interface where we can link to anything),
but it would be close to what has been suggested.

Hence, if we are a bit flexible about what is returned (probably there
would always be one main table but possibly with extensions in some
cases, hence we would still be relational to first order) then we can
wrap up TAP 1.0 and PQL 1.0 now without this feature, and address it
when the GDS query is prototyped in the next phase of development.

 	- Doug