Pedro et al.,
Alex, Bob, and I discussed the current ADQL PR. The outcome is that
we still have three concerns about the ADQL PR; I will provide
sugggestions as how to address them.
I hope these comments are helpful.
But that was not the point I was making.
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 it currently stands, there is
no such thing and clients would have to query each service as to what
it does and does not understand - or break up the datetime in small
pieces and handle them separately.
I feel that time is sufficiently essential in astronomy to warrant
requiring at least one common format (other than JD or MJD) that
clients can count on to be understood by all servers.
2. The geomerical functions in Section 2.4 are better defined in the
present version, but I still feel that the ADQL-specials complicate life unnecessarily.
I do not see that there is much to be gained (and, imho, much more to be lost) by allowing the same thing to be specified by:
CIRCLE ('UTC-FK5-GEO', 25.0, -20.0, 1) and:
REGION ('Circle FK5 GEOCENTER 15.0 -20.0 1.0')
I am afraid that the duplication is going to lead to a situation where
some clients will support one, but not the other, and services that
support the other, but not the one. That is not interoperability.
Alternatively, everyone has to write code to understand both - the
information is the same, but the formatting subtly different.
(Actually, strictly speaking, the former would need to look up the
AstroCoordSystem in the library that UTC-FK5-GEO points to, so it's
worse off than using STC-S directly.)
This is a waste of resources and would like to advocate that the only
geometric function we recognize be REGION with as argument an STC-S
string.
I think the STC-S syntax in REGION is no more complicated or obtuse
than the arguments in CIRCLE. It has been said that SQL cannot
validate the STC-S string, but the same is true for CIRCLE: SQL can
count the arguments and their types, but cannot make a judgment as to
whether their values make sense - that's left to the CIRCLE function.
The same is true for REGION: SQL can check the number and type of the
parameters (one string), but it is left to REGION to validate the
string.
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')
3. The meaning of a coordinate system specification in the presence of
referenced coordinate values. To some extent, this refers to Section 2.4.9 which is not very clear, but it is more fundamental than that.
What does it mean when I say (as in the example above):
REGION ('Circle FK5 GEOCENTER 15.0 -20.0 1.0') or:
CIRCLE ('UTC-FK5-GEO', t,ra, t.dec, 1) Clearly, it cannot mean: "I will interpret (t.ra,t.dec) as FK5", because they may not be and besides, the server should know. The most intuitive meaning would probably be: "I want (t.ra,t.dec) in FK5, so, if they aren't, do the transformation." But that may not be the most practical solution under all circumstances. The point is, though, this needs to be clarified and specified very explicitly.
> > ------ Forwarded Message
> > From: Pedro Osuna <Pedro.Osuna-at-sciops.esa.int>
> > Date: Mon, 15 Sep 2008 11:20:50 +0200
> > To: IVOA TCG <tcg-at-ivoa.net>
> > Cc: VOQL-TEG <voql-teg-at-ivoa.net>
> > Subject: ADQL Document for Recommendation
> >
> > Dear TCG,
> >
> > following the standard procedure, please find attached the ADQL Document
> > proposed for Recommendation, updated following the RFC comments and
> > interactions during the last interop meeting. The document can also be found
> > at:
> >
> > http://www.ivoa.net/internal/IVOA/IvoaVOQL/ADQL-v2.0-20080908.pdf
> >
> > Placeholders have been allocated at the bottom of the RFC pages at:
> >
> > http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/ADQLv2RFC
> >
> > where you should write the approval for the document or otherwise with
> > eventual comments if any.
> >
> >
> > Regards,
> > Pedro Osuna for the VOQL group
> >
> >
> > ============================================================================
> > ====================
> > This message and any attachments are intended for the use of the addressee
> > or addressees only. The
> > unauthorised disclosure, use, dissemination or copying (either in whole or
> > in part) of its content
> > is prohibited. If you received this message in error, please delete it from
> > your system and notify
> > the sender. E-mails can be altered and their integrity cannot be guaranteed.
> > ESA shall not be liable
> > for any e-mail if modified.
> > ============================================================================
> > =====================
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > ---------------------------------------------
> > * Document change log
> > - New document created with track changes enabled. All additions and
> > deletions are shown.
> > As suggested by Pat's on 23 May 2008, we could also accept the deletions
> > and show the additions only.
> > - Typos and editorial issues corrected as of RFC comments by Bob Hanish.
> > - Join description improved as suggested by Jeff's email 'Spec (BNF) changes
> > parallel to the RFC' on 28 May 2008.
> > - In Section 2.1.3, paragraph added clarifying the usage of
> > datetime/timestamp data types through the string
> > literal construct.
> > - Following the RFC comments on units, trigonometrical functions definition
> > have been improved including required units and legal return and input
> > values.
> > - Following the RFC comments, Mathematical and trigonometrical functions
> > table split
> > into two to be consistent with BNF.
> > - Remove Manipulative functions section as CENTROID is now part of the
> > Geometrical Data Types functions.
> > - Update list of geometrical reserved keywords to be consistent with BNF.
> > LONGITUDE and LATITUDE replaced by
> > COORD1, COORD2. RECTANGLE replaced by BOX.
> > - Following the RFC comments, new function COORDSYS added to extract the
> > coordinate system
> > from a given geometry. Keyword added to the list of keywords on section
> > 2.4 Geometrical Functions.
> > - All BNF excerpts under the Geometrical Function section (old Region
> > section) have been updated to be consistent
> > with latest BNF.
> > - Following the RFC comments, subsectioning has been improved to reduce the
> > section levels. As a result The Functions section has been
> > split into three: Mathematical Functions, Geometrical Functions and User
> > Defined Functions. Geometrical Functions section
> > now covers the Region stuff and has also reduced the section levels for
> > the sake of readability.
> > - As agreed among the TEG members it has been explicitly stated that ADQL
> > uses degrees everywhere in the geometry
> > constructs and region strings while trig functions, adopted from SQL, use
> > radians. When cartesian coordinates are
> > used the restriction is that the vector must be normalized.
> > - Legal ranges for spherical coordinates have been set to [0,360] and
> > [-90,90]. In a cartesian coordinate system,
> > there are no inherent limits but the constrain that vectors should be
> > normalized. Document now clarifies that
> > it's up to the service making use of ADQL to define the errors that should
> > be raised when using values outside
> > the legal ranges.
> > - Added text into the introduction stating the ADQL language is not
> > semantically safe by design (nor SQL) and the
> > specification defines syntactical correctness only.
> > - Following the RFC comments, links to STC and STC-S have been added in the
> > 'References' section and reference
> > to both within the 'Geometrical Functions' section.
> > - Broken link for Reference [2] fixed. Now pointing to
> > http://www.ietf.org/rfc/rfc2119.txt
> > - Coordinate system string literals must be specified by the service. A list
> > of such literals can be found in
> > Appendix of STC document.
> > - Following the RFC comments, BOX defined as of STC replacing RECTANGLE.
> > Samples of usage provided.
> > - Improved samples and description for AREA, CENTROID, CIRCLE, CONTAIN,
> > INTERSECTS, POINT, POLYGON and REGION
> > functions.
> > - Following the RFC comments, LATITUDE and LONGITUDE functions have been
> > replaced by COORD1, COORD2, these being
> > more generic and not attached to the spherical coordinate.
> > - New functions COORDSYS to extract a coordinate system from a geometry.
> > - Define use cases where CONTAINS and INTERSECTS should throw an error
> > message (to be defined explicitely by the
> > service making use of ADQL).
> > - New BNF grammar provided by Jeff with minor corrections (see differences
> > below).
> > - Remove SQUARE and replace MODE by MOD on list of ADQL reserved keywords
> > (section 2.1.2)
> >
> > * BNF change log
> > - Change in ADQL reserved words list: Added BOX, COORD1, COORD2, COORDSYS.
> > Deleted LATITUDE, LONGITUDE, MODE
> > RECTANLE, and SQUARE.
> > - box construct added.
> > - centroid syntax updated now using geometry_value_expression instead of
> > geometry_expression.
> > - character primary updated to use string_value_function instead of
> > user_defined_function.
> > - new constructs string_value_function, string_geometry_function> and
> > <extract_coordsys>
> > - SQUARE function taken out to be consistent with spec.
> > - contains_function replaced by contains.
> > - coord_lon and coord_lat replaced by coord1, coord2 constructs.
> > - new constructs coord_value, coordinate1 and coordinate2.
> > - distance function update now taking twoo coord_value constructs.
> > - extract_coordsys construct added.
> > - geometry_expression replaced by geometry_value_function with box,
> > centroid, circle, point, polygon
> > and region. geometry_value removed. geometry_value_expression updated
> > accordingly.
> > - intersects_function replaced by intersects.
> > - latitude, longitude constructs taken out.
> > - new constructs non_predicate_geometry_function,
> > predicate_geometry_function and numeric_geometry_function added.
> > - <system_defined_function> changed to <geometry_function>.
> > numeric_value_function uses <geometry_function>
> > instead.
> > - rectangle construct taken out.
> > - region_function construct taken out (replaced by
> > predicate_geometry_function)
> > - Added MOD function as described by the spec.
> >
> > _________________________________________
> > Pedro Osuna Alcalaya
> >
> > European Space Agency (ESA)
> > European Space Astronomy Centre (ESAC)
> > Science Operations Department (SCI-O)
> > Science Archives and Computer Support Engineering Unit (SCI-OE)
> > e-mail: Pedro.Osuna-at-esa.int
> > Tel + 34 91 813 13 14 Fax: +34 91 813 11 72
> > _________________________________________
> > European Space Astronomy Centre (ESAC)
> > P.O. Box 78
> > E-28691 Villanueva de la Ca?ada
> > MADRID - SPAIN
> >
> >
> >
> >
> >
> >
> >
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-10-06Z17:35:39