I am not happy with the way ADQL handles STC metadata in the PR.
First, as a minor point, it would be nice if an isodatetime data type were added, so that we could directly use ISO 8601 datatime strings:
yyyy[-mm[-dd[Thh[:mm[:ss[.s...]]]]]] I.e., the limited ISO 8601 format only, as defined for FITS and in STC.
The PR introduces a "geometry" data type, but it really is a
hodgepodge of stings - essentially, a geometry data type is defined,
if I understand it correctly, as a string that contains a function
call, with a variety of functions and parameters that seem to be
reinventing STC.
If one wants to introduce a new data type, there is a much more
elegant and ready-made option: an STC-S string.
I would be more inclined to call it an STC data type, since the term
geometry data type is misleadingly narrow, but that can be discussed.
Having defined such a data type, one can use the to-be-developed STC library to verify its validity and manipulate (interpret) the string, and define a set of STC core functions to provide the necessary operations, such as intersection, union, contained_in, etc. The STC-S string has the added advantage that it can also handle coordinates, so that problem would be resolved, too.
As it is, the PR basically develops its own STC model, through an ad-hoc set of functions and parameters. This, I think, is undesirable. If the IVOA has an accepted standard for certain structures, one should use it, rather than roll one's own. The reason is a very practical one: it encapsulates the model issues in that particular standard, allowing its related library to handle the details in a transparent and uniform way across applications, allowing models to evolve as necessary without impacting the users. If ADQL and SIAP and SSAP and Registry all would start using their own definitions of, say, Circle we create chaos for the user.
I have heard many complain that incorporating STC greatly complicates the systems into which it is to be integrated. That is nonsense. I have said it numerous times and will say it again: There is nothing wrong with applications recognizing only a limited subset of STC structures and coordinate systems - returning an error if they encounter something they cannot handle. That is the way STC was incorporated into VOEvent - and it works. It's perfectly acceptable to accept only simple strings and a limited set of shapes and coordinate systems. It is not hard to parse those strings and the enormous advantage is that (a) one is compliant with an IVOA standard and (b) one is ready to expand functionality to include more cases, shapes, and coordinate systems at any time, without any changes to the interface, just by adding code to the server software.
Aside from the fact that it is not a good idea to develop a new STC model for ADQL, there are a number of specific problems with the way it has been done, as well.
The only coordinate system flavor recognized in the PR is 2-D spherical. Coordinates are specifically assumed to consist of a longitude and latitude. This may seem sensible, but it means that one is painting oneself into a corner for future extensions. Another issue is that, again, if I understand it correctly, the parameters in the function calls may be valued or consist of column references. The problem is that there is no way to handle the coordinate system if the coordinate elements consist of references. I cannot say "function ('ICRS', table.ra, table.dec)" because I do not necessarily know whether the table contains ICRS positions - nor should I have to. If I ask whether the positions in a table lie within a certain region that I define in a certain coordinate system, the server (knowing what its own coordinate system is, one would hope) should perform the necessary transformations. The PR specifies that when a server cannot perform a necessary transformation, it should return a NULL. I question whether this is a sensible thing: it is indistinguishable from "I have no data". I would much rather see a standardized warning returned.
Arnold H. Rots Chandra X-ray Science Center Smithsonian Astrophysical Observatory tel: +1 617 496 7701 60 Garden Street, MS 67 fax: +1 617 495 7356 Cambridge, MA 02138 arots-at-head.cfa.harvard.edu USA http://hea-www.harvard.edu/~arots/Received on 2008-05-16Z22:45:58
--------------------------------------------------------------------------