comments on ADQL draft

[Arnold Rots]

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/
--------------------------------------------------------------------------