Dear Arnold,
> Yuji,
>
> Inserting the coordinate frame is no more verbose than inserting a
> table alias when there is only one table.
>
> My proposal has been to use STC-S in the ADQL-S queries. That has the
> advantage that it is a fully defined system, consistent, extensible,
> and compliant with other IVOA functions, and that it is convertible to
> the STC-X XML serialization.
> Within that context the default value for a missing element is always
> UNKNOWN. Proper frame identification avoids confusion - which will
> happen if you don't require it. The user will almost always assume
> that it is his/her favorite frame.
My modivation to allow the frame-less region query is arised from the consideration that frame conversion should be done at the client application. It is difficult to assume all the data service does the same quality of translation. The number of data services is expected to be larger than the number of client. I think it is enough to enfornce data service to provide the medata of default search frame, so that client application can do the proper frame-conversion.
> I'd be happy to include simulations in STC-S since they are in STC-X.
> That will allow more sensible querying of those datasets: only being
> able to ask for a circle in (X,Y) seems rather restrictive.
>
> And again, how many users do you expect to actually craft ADQL
> queries? I would imagine that most queries would be constructed by a
> more user-friendly user interface.
I imagine almost all user will use a client application or a portal service (I cannot assume whether it is user friendly or not), so doing the frame conversion on the client side seems to be reasonable to me.
> On two other issues:
> Units are included in the STC-S definition and actually have defaults,
> but should be the same for all related numbers in a query.
>
> For time ISO8601, JD, or MJD are allowed. I would strongly suggest
> for the ISO case to adopt the same restrictions that are in FITS and
> in STC: yyyy-mm-ddThh:mm:ss.s..., optionally dropping the 'T' in SQL
> conversion; no support for time zones or the 'Z' indicator, but
> instead a timescale specification where needed.
With the same reason, I think that the translation from ISO8601 to SQL-standard expression should be done on the client side.
Also about unit, I think it should be translated on the client side.
I don't like to rely all the translation on the data service.
Yuji Shirasaki.
-- Yuji SHIRASAKI <yuji.shirasaki-at-nao.ac.jp>Received on 2006-05-15Z17:43:39