Pedro,
I am still not satisfied with the responses to my comments on the ADQL RFC.
However you turn it, the PR still provides duplicate standards for common Region shapes and clients will have to (unnecessarily, in my view) query each service on what they support. The services may get away with supporting either one or two standards, but clients need to support both.
It also introduces a variety of data types (geometry, coordinates) that do not make sense to me. It would seem much simpler to define, if you like, a single stc_s data type that is known to SQL as a string and that SQL is not required to validate. SQL can handle them as strings and they are only interpreted as stc_s type in functions: confine the handling of STC-S specified regions to a set of specially defined functions.
My point is that using the stc_s type is not really more complicated than using the set of shapes defined in the PR.
CIRCLE ('ICRS', 123, 45, 12)
translates into:
'Circle ICRS 123 45 12'
If an ADQL implementation can handle the former, it should have no trouble
with the latter.
And points are:
'Position ICRS 123.45 67.89'
If one were to go this route, services would be free to implement only the
special functions currently provided in the PR (though the syntax would be
slightly different - but no more complicated) and, if clients submitted a
more complicated stc_s string, reply that the service does not support that
type of expression. This is precisely the kind of simplification technique
that we have used in VOEvent.
But the significant advantage would be that there is only one standard in
ADQL for expressing regions and coordinates, and clients do not have to
worry about what a service does or does not support - if the query is too
complicated for the service it will say so.
Then there is the issue of information that is internal to the service.
I argued that there is a problem when parameterizing coordinate information.
A client cannot say:
'Position ICRS your.ra your.dec'
since the service's ra and dec may not be ICRS.
The response was that the solution would be:
'Position your.coordsys your.ra your.dec'
which would require services to start including all kinds of extra (and
constant) columns in their tables. Well, agreed, there are other ways of
doing this. But I think it is not realistic to expect this to happen.
Finally, I had advocated to make ISO-8601 (or, rather, the limited set that
is included in FITS and STC) explicitly as part of ADQL. The response was that
many SQL version support various ways of expressing date-time types and that
ISO-8601 is often one of them.
I don't think that is good enough. I would advocate that services may support
whatever date-time formats they like, but that ISO-8601 is required.
That way, clients can at least be sure that one common format is understood
by all services.
Cheers,
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-07-03Z20:21:46