Hi Doug,
thanks very much for the update.
It is precisely what the getCapabilities functionalities are going to be what worries me, not when it was first mentioned, and the same thing for stageData.
English not being my mother tongue I might sound rude when saying this, but honestly reading your mail I get lost in your reasoning, as it seems to be mixing when a thing was first mentioned with whether the important details are being discussed and with whom, and finally I have the sensation to not have understood what you want to say. I would beg you to consider that many of us in the IVOA are not using our own languages to express our ideas or questions, neither are we reading in our own language, so it would be helpful if you simplify your reasoning lines.
I am only asking for an open discussion on important things like getCapabilities and stageData which are important for many services. If you bring it "cast on stone" to Beijing after having discussed it with only one or two persons, we risk finding severe problems in their conception, and we might finally end up failing to satisfy the community's needs.
P.
On Wed, 2007-04-25 at 07:50 -0600, Doug Tody wrote:
> Hi Pedro -
>
> This topic - the new DAL service profile, including getCapabilities
> etc. - goes back to at least the 2006 interop in Victoria, where it was
> discussed in the full DAL sessions and in the plenary. The approach is
> based on OpenGIS and was built into the SSA protocol about that time.
> We (you and I) have also discussed these issues in connection with
> SLAP, with the conclusion that SLAP would wait to update to the new
> service profile and getCapabilities, after it was developed and tested
> within SSAP.
>
> It is true that the most recent discussion of service metadata
> and getCapabilities has been mostly between Ray and myself (as the
> Registry and DAL chairs) over the past several months. However,
> this discussion has thus far mainly been on the high level issues,
> such as the scope of service metadata, and these have had adequate
> exposure elsewhere, most recently in the TEG forum (where this has come
> up repeatedly, e.g., in the description of the DAL service profile).
> The related issue of dataset metadata, and the relationship between
> service and dataset metadata, has also been discussed. Thus far,
> I have seen almost no response from the TEG to anything of this sort
> which I have posted.
>
> Given that this overall approach has been out for discussion for about
> a year, and is now implemented in actual protocols and implementations
> (SSAP), I can't see making major changes at this point. The details
> of what getCapabilities contains and how it is used, however, are
> still open for discussion. As I say, we have a session dealing with
> getCapabilities scheduled for Beijing (DAL-1), where Ray and probably
> some other registry folks will be present.
>
> Regarding stageData, the concept for this has been out since SIA 1.0;
> there is a section on it in the SIA specification. It has never been
> implemented as we have not had the low level technology available to
> do so. The role of this in the DAL service profile is well established
> at this point, however the details are still TBD, and are now being
> considered. The concept was gone into in some detail again within
> the TEG in the TAP design study which I posted earlier this month.
> It was also discussed in the GWS list a month ago in connection with
> the REST discussions. There has been additional discussion in the
> past week, most of it in the context of the IVOA Assessment over the
> past week, which you will have seen (I also copied a section of this
> to the TEG as a heads-up). Guy, Matthew, and myself have had a bit
> more discussion in private emails as well. We plan to continue this
> in the DAL and GWS sessions in Beijing.
>
> Substantive discussion of this would be welcome. There is plenty of
> material out there to review, and has been for some time.
>
> - Doug
>
>
>
> On Wed, 25 Apr 2007, Pedro Osuna wrote:
>
> > 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. =================================================================================================Received on 2007-04-25Z16:18:57