On clarification for getCapabilities and stageData

Doug,

> getCapabilities is introduced in SSAP and has been under discussion
> between DAL and Registry for some time.

unless I have been unable to find it for any reason, we (VOQL) have not been involved in these discussions. I reckon that if this is going to affect in any way the TAP, we should have some word to say in the definition of such a big thing. I was worried by your previous statement (on the getCapabilities issue):

[...]To summarize our current thinking (which will be cast in stone shortly due to the need to get SSAP out)[...]

I would not like something to be cast on stone when we have not had the chance to discuss about it in a broad (I would say, whole DAL, whole Registry and whole VOQL at least) audience and it might affect some of our deliverables. I still do not know who you mean when you say "our". Is that yours and Ray's?.

I have checked, and there don't seem to be any inputs in the dal forum, nor in the registry forum about the getCapabilities, although I can admitedly be wrong.

> stageData is being actively discussed now between DAL and GWS (Guy).

See same comments as above.

Note that to avoid unnecessary misunderstandings, I have copied this mail to the IVOA TCG Chair for his information.

Roy: you can check previous mails if you need at: http://www.ivoa.net/forum/voql-teg/

Cheers,
P.

On Tue, 2007-04-24 at 09:34 -0600, Doug Tody wrote:
> On Tue, 24 Apr 2007, Pedro Osuna wrote:
>
> > 7) Clarify point with Doug: in which forum is the getCapabilities
> > and stageData (and/or others) being discussed?. Ask for inclusion
> > on it if relevant.
>
> getCapabilities is introduced in SSAP and has been under discussion
> between DAL and Registry for some time. We have to finalize this for
> the SSAP WD shortly (I am working with Ray directly on this one; Ray
> will also join us in the DAL-1 session in Beijing to discuss this).
> We will want the same mechanism in all the DAL services. It returns
> only service metadata.
>
> stageData is being actively discussed now between DAL and GWS (Guy).
> The mail I forwarded earlier summarizes what is planned, but we are
> still actively discussing this. We will want to implement stageData
> initially in both SIAV2 and (presumably) TAP.
>
> There is also the getAvailability method, used to monitor service
> health and availability (discussion between DAL and GWS).
>
>
> For TAP, the key issue would appear to be the scope of queryData,
> and whether this can be used as a uniform mechanism to return both
> table data and metadata (this does not mean we would have to permit
> ADQL for metadata queries). In the other DAL interfaces, it is
> used for discovery, to return dataset metadata, and to propose/plan
> data products (often virtual) which can be computed and returned.
> All of these functions return the query results as a table, hence
> it is reasonable to use the same mechanism to directly query a data
> table as well. In the simplest case of a queryData on a single data
> table, this reduces to what is essentially a cone search, but with
> a somewhat generalized set of input parameters, plus an ADQL option.
>
> - Doug

-- 
Pedro Osuna Alcalaya

European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Research and Scientific Support Department (RSSD)
Astronomy Science Operations Division (SCI-SD)
e-mail: Pedro.Osuna-at-esa.int
Tel + 34 91 813 13 14    Fax: +34 91 813 11 72
-------------------------------------------------                                                                                
European Space Astronomy Centre (ESAC)
P.O. Box 50727
E-28080 Villafranca del Castillo
MADRID - SPAIN

================================================================================================
This message and any attachments are intended for the use of the addressee or addressees only. The
unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its content
is prohibited. If you received this message in error, please delete it from your system and notify
the sender. E-mails can be altered and their integrity cannot be guaranteed. ESA shall not be liable
for any e-mail if modified.
=================================================================================================