Minutes of the VOQL-Session @ IVOA Interop 05/2008 Trieste

Summary of the current state of the ADQL specification:
 * The document is in RFC and nearly ready for publication.
 * RFC phase was started a bit later than proposed in the Cambridge Interop due
   to region issues.

The RFC page so far contains 4 major issues which will be discussed in this
session, in descending order of priority.

* ADQL explicitly provides functions for 2D (spatial) geometry, following
  roughly the OpenGIS specifications.
* For interoperability with STC (and possibly other geometry specifications),
  there is the REGION function, taking a string as its only parameter. This
  string could, for example, be an STC serialisation.
* It is part of the service specification (or registration) to provide a list
  of supported geometry serialisations.
* This is consistent with SQL dates, timestamps, binary strings etc.
* For the 2D geometry functions, there is a string parameter defining the
  coordinate system. Again, it is up to the services supporting ADQL to define
  what values are allowed.
? Is there a default coordinate system? (Andreas Wicenec)
! No, ADQL does not specify a default coordinate system.
? Why are there no boxes (coordinate ranges)? (Igor Chilingarian)
! It didn't seem necessary to provide them.
? Wouldn't it be easier (at least from the service provider point of view) to
  have functions like ICRS_Point, ICRS_Circle etc.? (Francois Ochsenbein)
! It would be very restrictive to have that in the language specification; we
  tried to be as general as possible. The language should not be tied to single
  coordinate systems.
? Why are there some "explicit" region functions even though it is possible to
  use STC? (Robert Hanisch)
! The functions are consistent with the current STC specification. However,
  functions are easier to implement in most RDBMSes, thus we decided to provide
  them for convenience (as requested by NVO).
? Why are the convenience region functions not explicitly derived from STC, but
  rather redefined in the ADQL document? (Robert Hanisch)
! Depending directly on the STC specification would lead to a couple of issues.
  * STC is object oriented, ADQL is (in order to stay compliant with SQL'92)
    in functional style.
  * Should ADQL depend on a certain, named version of STC? Or on the most recent
    one? Then an Update to STC could accidentally brake ADQL's SQL'92 compliance.
  * Referencing other specifications - like STC - is not as easy from within a
    language definition as it is for e.g. service specifications like TAP.
  * A reference to the STC definition will however be added to the ADQL
    specification, in the section describing the REGION function.
? So, there are two ways of defining basic shapes in ADQL: Using the "native"
  functions and using STC. Is there any advantage out of that? (Robert Hanisch,
  Anita Richards)
! It is easier for people typing their queries manually to use the functions
  like CIRCLE, POLYGON etc. For queries generated automatically (e.g., by a
  service), using REGION and STC serialisations is presumably easier. Via
  REGION, it will e.g. also be possible to send an STC geometry description,
  maybe gotten as a response from a footprint service, straight on to a data
  service.
* An open issue is the RECTANGLE function in ADQL, which corresponds to the BOX
  shape in STC. We will rename the RECTANGLE (a term taken over from OpenGIS) to
  BOX to not create naming ambiguities wrt STC.
* We consider renaming the LATITUDE and LONGITUDE functions to make it clearer
  they are not related to any specific coordinate system.
* For the sake of completeness, we will also add a function for extracting the
  coordinate system from a geometry type.
? How about adding a function for extracting the 3rd coordinate value (when,
  e.g., using coordinates on the unit sphere, or for simulations)? (Gerard
  Lemson)
! We will consider that for a future version of ADQL. The language will continue
  to evolve, but we are trying to get the first version accepted as a standard
  as quickly as possible.
* It is not possible to make the language semantically safe by design. The
  specification can only define syntactical correctnes.
* The ADQL is quite difficult to read as there are no examples. Various
  possibilites are discussed, we finally agree on sticking to the precedence
  case provided by VOSpace: There will be an "ADQL Primer" document providing
  non-technical explanations and examples. This decouples the specification and
  the samples and makes it easier for the Primer to evolve without having to run
  through the IVOA standard acceptance process again and again.
? Coming back to coordinate systems, what error will be replied if a coordinate
  system unknown to the server is being used within a query? (Roy Williams)
! That is again part of the service specifications, not of the ADQL language.