Dear all,
I send you the minutes that Inaki compiled for us during the last
meeting. Thank you all for a very fruitful meeting, and thanks to Inaki
for taking the minutes and putting them in electronic form.
Remember to check the list of actions (new and old) at the end of the
summary.
We keep in contact through the list.
Cheers,
P.
VOQL-TEG Meeting #2
Date: 16-Nov-2006
Time: 14:00 (UTC)
Present:
AS,GF,DT,FO,IO,KA,PD,PO,YS (see below for acronyms list)
Minutes by: IO
0) Approval of VOQL-TEG#1 minutes
The meeting minutes got approved.
- Review of actions:
+VOQL-TEG-1/AI#1 on KA: To distribute BNF --> XML translator to the list
Status: closed
- KA says ADQL/S-to-ADQL/X translator is available from the AstroGrid
site as stated in a recent mail sent to the group. PO requests the
group to have a look at it and agrees with KA on the usefulness of the
libraries and the BNF grammar as a starting point. Action gets closed.
- PO proposes to combine the ADQL/s to ADQL/x translator with some
stylesheets, to be produced by ESAVO Team, to perform the reverse
conversion: ADQL/x to ADQL/s. KA reckons the have already something
similar to translate ADQL/x into SQL. IO comments that it would be
useful to have everything in the same library to let the implementation
of any translation evolve in line with the rest of efforts. PO proposes
a collaboration between Astrogrid and ESAVO to produce such a library.
DT states that NVO have already an ADQL parser. PO reminds that such
a parser is compatible with ADQL v0.7.4 only.
+VOQL-TEG-1/AI#2 on ALL: To send to the list (voql-teg-at-ivoa.net) where
to put REGION
Status: closed
+VOQL-TEG-1/AI#3 on YS: To send to the list why he believes REGION
should be a new ADQL clause
Status: closed
+VOQL-TEG-1/AI#4 on KA/DT: To send note on why REST and/or SOAP should
be considered Compulsory or optional
Status: closed
- PO comments that these three actions will be addressed in point number
2.
+VOQL-TEG-1/AI#5 on YS: To send note to the list on why he believes
UPLOAD should be part of the language
Status: ongoing
+VOQL-TEG-1/AI#6 on ALL: To send to list inputs on preferences to have
the UPLOAD (whether in the Protocol or in the Service)
Status: ongoing
- PO says no inputs were received yet. YS agrees to discuss it in the
next meeting. In the mean time he is requested to send a note to the
mailing list to start the discussion.
+VOQL-TEG-1/AI#7 on FO (plus DT/KA): to propose a mechanism for getting
table metadata within the TAP and possible output format
Status: ongoing
- PO says inputs have been sent by DT only. DT refers to the e-mail were
he just has phrased his motivations, not any specific proposal. PO
requests inputs from FO for next meeting. FO agrees.
+VOQL-TEG-1/AI#8 on YS/IO/PO to initiate the refurbishing of the ADQL
spec to have it as a basis
Status: ongoing
- PO mentions to wait to have inputs from today's meeting and start the
refurbishing afterwards. Everybody agrees.
+VOQL-TEG-1/AI#9 on PO/DT: to start writing the TAP document
Status: ongoing
+VOQL-TEG-1/AI#10 on PO: To change IVOA wiki pages
Status: ongoing
- PO comments that he has not done it yet. He will do it before next
meeting.
2) Following mailing list discussions, agree on decisions for:
- Region into Where clause
- REST "compulsory", SOAP optional
- One single language, one single BNF (no core plus ext.)
+ Region into Where clause
- PO refers to mail of YS and asks him whether he would like to have the
REGION in a separate clause to avoid "Select REGION(..) from..."-like
constructs or due to technical problems that may arise when implementing
the ADQL parsing. YS states it's due to technical issues. PO states that
any technical difficulty should not impose restrictions on the language
and offers technical support to YS to sort out any possible difficulty.
PO gives the token to the rest of the group. The rest of the groups
agrees on having REGION as part of the WHERE clause. PO asks YS to give
samples on why he thinks it is difficult to implement. Finally a poll is
made and everybody agrees (including YS) to put REGION within the WHERE
clause.
- KA comments that the REGION clause still misses the specification of
tables and columns where to perform the search against. PO agrees and
proposed to address the issue in the next meeting.
- KA raises the point related to the unit handling within the REGION
clause. PO says that's a tough issue while KA comments we should tackle
it at some point. PO agrees to send a note to this respect to address
the issue in the whole VO context.
+ One single language, one single BNF (no core plus ext.)
- PO summarizes KA's mail: "one single language to let the service
describe what it does support". PO finds the approach reasonable from
the ESAVO perspective. DT says that the getCapabilities should handle
that.
- AS argues that they have to use the full language in general but want
to use the CORE in some other cases/implementations for efficiency
reasons. Moreover, he claims they want to use constructs that are
platform/vendor specific. KA says we can't afford that in the language
while PO suggests the usage of a User Defined Function placeholder to
handle those restrictions. AS comments that there are some specific
constructs, like the CROSS APPLY, that do not fit in the UDF/Macro
schema and are heavily used within their systems.
- AS comments that in his understanding CORE should be pure ADQL while
the EXTENSION mechanism would include vendor specific constructs and
allow negotiation. Hence, the extension mechanism would allow to use
custom extensions when the user is on his own. KA says that a single BNF
grammar should be issued and comments her worries about some specific
constructs that would be impossible to put into the grammar.
- KA comments the potential problem of restricting the grammar just to
allow vendor specific constructs besides the fact that it's technically
difficult. PO claims that if we find reasons enough to believe that a
technical solution exists then we might go to accept that.
- Then PO calls for a preliminary agreement. It remains unclear to some
of the group members the difference between a language construct like
CROSS APPLY and the SQL macro/udf syntax and if we can fit the former
into the later. Therefore, PO requests AS to send to the mailing list
samples on how this could be implemented. KA requests a list of extra
constants to be considered.
- The discussion continues and AS ask for ALL to send to the list how
they handle the REGION (though specific SQL macros/udfs? through code?)
so that we all get a clear idea of what is really needed. FO,AS conclude
that, at the end, the approach of NVO and CDS is very similar. PO does
not see strong reasons of disagreement in the concept. PO ask ALL to
send examples on how we deal with macros/udfs and how could we have this
single BNF grammar with 'CROSS APPLY'-like constants. Everybody agrees
that we should clarify all these first and then take a decision.
++Action VOQL-TEG-2/AI#1 on ALL (see below): to send to the list real
code examples of how we deal with REGION constructs _and_ special
constructs (like the CROSS APPLY)
+ REST "compulsory", SOAP optional
- PO clarifies what sync/async means and comments that REST should be
compulsory and SOAP optional. PO and KA explains to AS what REST means.
We ALL decide to get rid of the 'REST' terminology and make use of
'HTTP GET/POST' instead. PO asks for confirmation on whether we are ALL
happy having TAP/REST and not TAP/SOAP. KA agrees and confirms that
though in the past had a different view, finds it reasonable.
- PO talks about the missing bits that we will probably miss if we go
for TAP/REST (Authentication, SOAP features...). He comments a possible
upgrade of the protocol later if it's really needed.
- DT raises the point on how to handle large queries and its interface
with VOSpace. PO comments it might be better to agree on TAP being REST
and discuss that point later in the mailing list so that we can start
writing the document.
3) On cross-match issue (left pending due to Alex absence in previous
meeting)
- PO introduces the topic by pointing to R.Plante's presentation (Moscow
'06 Interop). He comments that we should first make a clear distinction
between the Language (ADQL), the Protocol (TAP) and the Service (e.g.,
ADQL server with CROSS APPLY support) and then find where to put the
cross match. PO thinks the cross match should be handled at the Service
side and asks if everybody agrees on that. PO gives the token to AS to
summarise crossmatch overall concept.
- AS then summarizes his view of the cross-match. He makes a thorough
description on what a cross-match is and its problems (symmetry,
performance... etc).
- PO asks where to define the cross-match. Within a service? Within the
TAP? AS thinks it should be in the service. PO asks again if people
would be happy to address the cross-match as an independent service. AS
agrees again as it has a very clear input and output. PO asks if the
VOQL-TEG should create a new spec. AS thinks it should be in between
VOQL-TEG and other WGs within the IVOA. PO summarizes: There must be a
third specification (besides the ADQL language and the TAP protocol) for
a service. This service will fall under the shared responsibility of
other groups and would be initiated by the VOQL-TEG. AS agrees. DT
agrees but raises a question: does it require any support by the TAP? PO
believes that is up to the service specification, not the TAP.
- AS gives some samples on the data travelling issue (two different
approaches: upload of full output tables or breaking big tables to
perform atomic transactions).
- KA asks if we should provide any cross-match specific functionality in
the ADQL. Her opinion is against it. AS agrees as well. PO reminds this
is one of the most important points for going through this
"refurbishing" exercise.PO summarizes and asks for any other concerns.
FO comments about the number of catalogs/tables to be used in the cross
match and identifies that as an issue. PO puts an action on FO and AZ to
initiate a document on cross-match as they are the experts in the
subject. They both accept and AS comments that we should not make
anything too complex.
++ Action VOQL-TEG-2/AI#2 on AS/FO: to initiate the writing of an IVOA
standard document for the description if a Service that addresses the
Crossmatch issue.
- Finally PO summarizes the agreement on having a three-layer schema
where ADQL is the Language, TAP is the Protocol and there will be a
Service to handle the Cross-Match. No name is being given to that
particular service yet (see action below). PO comments that he will
inform the community about this outcome and agrees to send the minutes
to initiate the work.
Then PO asks for an overall agreement on this cross-match issue.
Everybody agrees.
++ Action VOQL-TEG-2/AI#3 on ALL: to give ideas on the name to give to
the aforementioned Service (describing crossmatch issues)
4) AOB
- BG asks about the UPLOAD issue. PO asks ALL to send inputs so we can
start the discussion at the next meeting.
- Then we ALL decide when to have next teleconf January 15th and the
meting is finished.
List of actions
New actions
+VOQL-TEG-2/AI#1 on ALL: to send to the list real code examples of how
we deal with REGION constructs _and_ special constructs (like the CROSS
APPLY)
open
+VOQL-TEG-2/AI#2 on AS/FO: to initiate the writing of an IVOA standard
document for the description if a Service that addresses the Crossmatch
issue.
+VOQL-TEG-2/AI#3 on ALL: to give ideas on the name to give to the
aforementioned Service (describing crossmatch issues)
Old actions
+VOQL-TEG-1/AI#1 on KA: To distribute BNF --> XML translator to the list
closed
+VOQL-TEG-1/AI#2 on ALL: To send to the list (voql-teg-at-ivoa.net) where
to put REGION
closed (but see VOQL-TEG-2/AI#1 below)
+VOQL-TEG-1/AI#3 on YS: To send to the list why he believes REGION
should be a new ADQL clause
closed
+VOQL-TEG-1/AI#4 on KA/DT: To send note on why REST and/or SOAP should
be considered Compulsory or optional
closed
+VOQL-TEG-1/AI#5 on YS: To send note to the list on why he believes
UPLOAD should be part of the language
open
+VOQL-TEG-1/AI#6 on ALL: To send to list inputs on preferences to have
the UPLOAD (whether in the Protocol or in the Service)
open
+VOQL-TEG-1/AI#7 on FO (plus DT/KA): to propose a mechanism for getting
table metadata within the TAP and possible output format
open
+VOQL-TEG-1/AI#8 on YS/IO/PO to initiate the refurbishing of the ADQL
spec to have it as a basis
open
+VOQL-TEG-1/AI#9 on PO/DT: to start writing the TAP document
open
+VOQL-TEG-1/AI#10 on PO: To change IVOA wiki pages
open
List of personal acronyms:
AS: Alex Szalay
BG: Benjamin Gufler
DT: Doug Tody
FO: Francois Ochsenbein
IO: Inaki Ortiz
KA: Kona Andrews
PD: Pat Dowler
PO: Pedro Osuna
YS: Yuji Shirasaki
--
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 2006-11-21Z12:59:29