Hello Arnold and colleagues!
I don't think anyone on the TEG for VOQL thinks that ADQL v2.0 is the final word, but I think we have done pretty well to bring it to its current state. It is a good subset but certainly not a comprehensive subset of SQL92. It does have the feeling of consistency, which has been hard won by a lot of patient and detailed work. The next turn of the screw, with attempts to implement the back-end services, will provide a huge amount of feedback invaluable for the next version.
There are gaps, but these are known and have not been considered as part of our remit for version 2. It is obvious we have not tackled temporal data types, string manipulation, bit types and their manipulation, and more abstruse but important things like row value constructors.
I think most members of the VOQL TEG group are sympathetic to the concerns you express, but feel we have gone well beyond v1.0 and need implementation feedback before we make further progress. However, I speak for myself here, and the opinions in the following points are my own.
Temporal Data Types:
> I suggested that recognizing ISO 8601 date-time be mandatory, for the
> simple reason that it would guarantee a single date-time format that
> will be recognized by all services.
As I mention above, temporal data types never appeared in our remit for version 2. As I'm sure you are aware, it is one of the more difficult and complex areas for interoperability of RDBMS's. You may well be correct in mandating one approach (ISO 8601). I think you have my vote. But I am loath to do so on a lack of thought, which certainly I for one would have to plead guilty on this score. We simply have had enough on our plates for version 2.
Geometrical Functions:
> There is the issue of passing references (like "t.ra" and "t.dec") on.
> I am sure we can come to an agreement on that, for instance by
> escaping the names, like:
> REGION ('Circle FK5 GEOCENTER @t.ra @t.dec 1.0')
The above point is very seductive, but understates the problem. Each and every function parameter can be a value expression, and these can be complex things, not just simple literals or column references. So for
CIRCLE ('UTC-FK5-GEO', t.ra, t.dec, 1)
each parameter could be a literal, a column reference, or a derived value of some description. A simple but credible example would be radius as a calculated value.
A certain degree of semantic checking is also called for. This is obvious when you consider table aliases, even in the example above. The simplest case would be to check that a table alias existed. If you combine complex expressions with semantics, the provision of another syntax inside a string, with symbolic pointers to columns which may be from derived tables, makes things quite a bit more difficult.
On a slightly different tack, within the ADQL spec we have syntactical constructs like user-defined function, region, circle, contains, all the way down to more mundane things like truncate and round etc. We have not mandated anywhere how these things are to be implemented. We may call them functions, and indeed they may well be functions, but really they are nuggets of functionality. There could be a vast difference in the implementation across servers. The implementations of circle, box, polygon may well all be called region; we have simply not mandated the implementation. For example, from parsing ADQL, it is feasible to emit an SQL function called Region taking a single string parameter composed of concatenating highly complex expressions. A user would not need to see the details. I don't think that belongs in the current ADQL specification.
As far as interpreting coord system values is concerned, I think we agree that there will be a degree of checking and possible transformation on the server implementations. Every so often throughout the spec you can find phrases like "If it cannot do so, it SHOULD throw an error message, to be defined by the service making use of ADQL". Over and above that, I believe that the tools which inform construction of queries need to know the capabilities of the server.
I hope that helps
Jeff
-- Jeff Lusted tel: +44 (0)116 252 3581 Astrogrid Project mob: +44 (0)7941 599062 Dept Physics & Astronomy email: jl99-at-star.le.ac.uk University of Leicester web: http://www.astrogrid.orgReceived on 2008-10-08Z11:53:53