On 2008-5-12 07:13, Pedro Osuna wrote:
> Dear all,
>
> there is one single session for VOQL to present the ADL document.
>
> I would like to more or less repeat what we did in Cambridge last
> time, and have:
>
> - Inaki presenting the overall ADQL
> - Jeff presenting the BNF and parser
> - Pat presenting the Region
>
> Would you guys agree on that?
Since we are in the RFC, it seems like we are inviting discussion of the whole spec. I feel it would be better to have a session where we air the specific comments made on the RFC page and answer them as well as we can.
> It would also be nice to hear from you on a previous mail I sent
> regarding the collection of inputs for the RFC from the different
> communities, as that should also be reported in Trieste.
The comments so far are from bob (as NVO?), Roy (as TCG chair?), and Francois (who is already on the TEG).
Aside from some lesser issues, the comments from both Bob and Roy (and Arnold on the list) are about how we did or did not use STC. That is a reasonable question for the TCG chair to ask and we have a well-reasoned answer for it. I would be willing to stand up and lead this discussion, but I really don't think we should present, just be ready to answer.
-- The question(s) from Francois are things we discusses at length within the TEG and we already agreed to comprimise on the functional representation (instead of operator syntax). I should know, I was one of the ones wanting operators and agreeing to the comprimise :-) I don't see the point of bringing this out again as it indirectly brings a bunch of other things onto the table. Specifically, if we go with functions, people can implement it inside the DB and we can (must) exclude anything that does not fit existing SQL syntax. If we go with operators, people must have an ADQL parser and once we admit/accept that position we are open to adding anything that does not fit standard SQL syntax. -- On Francois' other issue with a spherical distance function taking simple numeric arguments, everyone will recall that in Cambridge we presented region without a point type and just numeric arguments. The one strong message that came out of that meeting was to have the point type (just as we now have it). If an existing DB has numeric columns, it means the query has some extra stuff to clarify, for example DISTANCE ( POINT( a.coordsys, a.x, a.y), POINT( b.coordsys, b.ra, b.dec) ) and the service has to transform coordinate systems or throw an error. ** Side note: I think I said in the past that we could get rid of RECTANGLE completely without loss of functionality. We either need to do that or explicitly specify that it is a short-hand for a POLYGON (rather than a range of coord values). I would favour just removing it entirely and in the RFC response just say that we had discussed doing that but forgot to conclude :-) sincerely, -- Patrick Dowler Tel/Tél: (250) 363-6914 | fax/télécopieur: (250) 363-0045 Canadian Astronomy Data Centre | Centre canadien de donnees astronomiques National Research Council Canada | Conseil national de recherches Canada Government of Canada | Gouvernement du Canada 5071 West Saanich Road | 5071, chemin West Saanich Victoria, BC | Victoria (C.-B.)Received on 2008-05-12Z19:53:19