Dear VOQL-TEG,
Please find attached the latest version of the ADQL spec. This version
fixes some problems/typos spotted by Benjamin.
You can find below a detailed summary of all that has been corrected
based on his inputs.
On 2008-3-20 06:12, Benjamin Gufler wrote:
* Since terms MUST, MAY, SHALL etc. are used throughout the document, we
could add a reference to RFC 2119 which defines them.
A link to RFC 2119 has been added in the 'References' and its usage
commented
at the end of '1. Introduction' section.
* 2.1.3 Literals: An unsigned integer may be composed of more than one
digit, so:
<unsigned integer> ::= <digit> [,...]
Corrected.
* 2.2 Query syntax: The construct of a SELECT statement shown here is
different from the specification in the appendix (especially the
FROM-part) - this will probably confuse the reader.
The 'Query syntax' section includes a "compact syntax" of the select
statement. Its aim is just to provide
a quick look showing the primordial elements of the construct without
entering into the full
syntax subtleties. Nonetheless it's true that it might differ from what
the appendix specifies.
Therefore, I have updated this construct so that it still provides a
simplified syntax
(short enough and easy to read) but more in line with the the appendix.
To stress the difference between this simplified syntax and the BNF in
the appendix I have
also replaced the brackets by identifiers in italic.
Hence, the resulting simplified syntax is as follows:
SELECT [ ALL | DISTINCT ]
[ TOP
unsigned_integer ]
{ * | {
value_expression [ [AS]
column_name
] }, … }
FROM {
{
table_name [ [AS]
identifier ] |
( SELECT ….) [ [AS]
identifier ] |
table_name [NATURAL] [ INNER | { LEFT | RIGHT | FULL
[OUTER] } ] JOIN
table_name
[ON
search condition | USING (
column_name,…)
] }
, …}
[ WHERE
search_condition ]
[ GROUP BY
column_name, … ]
[ HAVING
search_condition ]
[ ORDER BY {
column_name |
unsigned_integer } [ ASC |
DESC ],…]
Finally, a sentence has been added at the beginning of the section
pointing out that a complete
syntax of the select statement can be found in Appendix A.
* Are there any databases returning the columns in a different order
than the one specified in the select clause? If not, we should
consider replacing "should" by "shall" in that paragraph.
Corrected.
My personal opinion is that we are defining a language and we should
avoid
discussing on implementation details as much as possible.
I think we can replace 'should' by 'shall' regardless of what the
different vendors implement.
Specially if that is the desired functionality and the expected
behavior for the end user.
* "TOP": Is it clear to everyone what the "first" n rows are, especially
that it could be different rows on subsequent invocations of the same
statement, or should we explicitly state that?
No answers received so far. I leave it as it was unless stated
otherwise.
* 2.2.2 Search condition: "Six different types" -> but only 5 are listed
below.
Corrected.
* 2.3.1 Mathematical functions: Every function is "basic", so maybe we
could avoid repeating that for every single one.
Corrected
* 2.3.2.2.5.4 Contains: "Since the two argument points" --> "Since the
two argument geometries" (as at least the second parameter will
usually not be a point).
Corrected
* 2.3.2.2.5.7 Longitude and 2.3.2.2.5.8 Latitude: What is returned if
the argument is not a point, but some shape? NULL?
No update on this. These sections clearly state that a point should be
used as input parameter.
It might be good enough for the time being.
Furthermore, the following typos have been corrected:
* 2 Astronomical Data Query Language (ADQL):
This section claims that repetitive item (zero or more times) are followed by
[,...] whereas the Appendix A uses "..." instead. [,...] --> ...
* 2.3.2.2.1 Data type functions, 3rd paragraph:
"A geometry <value_expression>" --> "A <geometry_value_expression>"
* 2.3.2.2.5.6 Intersects, 1st paragraph:
"deterrmines" --> "determines"
* 2.3.2.2.5.11 Rectangle, 2nd paragraph:
"latitide" --> "latitude"
* 2.3.2.2.6 Geometry output, last paragraph:
"comverting" --> "converting"
* 2.3.3 User defined functions, 1st bnf block
"<user_defined_function_param>}...]]" -->
"<user_defined_function_param>}][,...]]"
* Appendix A: Repetition of elements is symbolised by "..." throughout
the appendix, whereas the document states it would be symbolised by
"[,...]".
Regards
Iñaki
--
Iñaki Ortiz de Landaluce
European Space Agency (ESA)
European Space Astronomy Centre (ESAC)
Science Operations Department (SCI-O)
Science Archives Engineering Unit (SCI-OE)
E-mail: Inaki.Ortiz@sciops.esa.int
Tel: +34 91 813 13 67 Fax: +34 91 813 13 22
European Space Astronomy Centre (ESAC)
28691 Villanueva de la Cañada
P.O. Box 78, Madrid, SPAIN
================================================================================================
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.
=================================================================================================
Received on 2008-03-25Z15:10:19