ADQL-2.1 internal draft

[Marco Molinaro]

Hi Walter, hi DAL,

2015-06-10 1:53 GMT+02:00 Walter Landry <wlandry at caltech.edu>:
> Marco Molinaro <molinaro at oats.inaf.it> wrote:
>> Dear DAL members,
>> a first internal draft of the ADQL-2.1 document in available online,
>> linked on the IVOA TWiki at
>>
>> http://wiki.ivoa.net/twiki/bin/view/IVOA/ADQL
>
> Here are some of my thoughts.
>
> 1) Coordinate systems are deprecated in the geometric functions (BOX,
>    CIRCLE, etc.).  Why don't we just declare new functions that do not
>    take the first argument?  So instead of
>
>      BOX('', 25.4, -20.0, 10, 10)
>
>    it would be
>
>      BOX(25.4, -20.0, 10, 10)
>
>    The functions have different arity, so it is easy to distinguish
>    between them in the parser.  In general, empty strings feel odd to me.

It could be odd, but this solution was taken upon back-compatibility
constraints.
That's why from ADQL-2.1 on, until a major revision, the first string,
if not empty can be ignored by servers
and client are encouraged to pass an empty one. I.e. that parameter is
deprecated from revision 2.1 on.

Doing the "method override", which is for sure a more neat solution,
generates, in my opinion, confusion: the function signature a client
use will be dependent  on the service version he's making the query
at, plus the service should infer what the client wants out of the
arity and not only the function name. Or the VERSION parameter must be
made mandatory to distinguish them---

So, I suppose the only thing we can do is move fast to an ADQL-3.0 or
change back-compatibility rules for IVOA.

> 2) I do not understand the syntax for IN_UNIT().  Shouldn't there be
>    three arguments (value, units_from, units_to) and not two?

here I agree with Markus' reply

> 3) Section 4.6.1 has a cliffhanger ;)

Yes, but consider that this is a draft, and features entering this
revision of the spec depend also on their sustainability for the
various partners involved in the process

> 4) Can we put the math and trig functions into the optional
>    components?  Most of them are not implemented in sqlite.

These are taken directly from the ADQL-2.0 specification.
I don't think removing them from the ADQL core is feasible at this
revision step.
This independently on the efforts needed to implement them.
Maybe this is something to be considered for a major revision, but it
requires at least some usage statistics.

> 5) Why are we making new function names BIT_AND, BIT_OR, etc?  Why not
>    just use the operators?  It is what everyone but Oracle and
>    Informix implement, and they use different names anyway.

I skip, being neutral on this, anyway it was discussed both in Madrid
and reported online.
It can be re-discussed in Sesto, if needed.


Pasting here also the other two points you made, i.e. LOWER/UPPER and ILIKE.
Probably there was not full discussion on them.

LOWER/UPPER Initially they were set as optional for this revision, but
there was also the point made that it would be better to have them
mandatory...and also to have only one of them to help with tables
indexing.
Probably this is something to discuss.

The UTF-8 or not in using them I don't think it came into play. What
the TAPNotes Note says about is:
---
ADQL currently has no facility reliably allowing case-insensitive
string comparisons. This is particularly regrettable since UCDs and at
least the majority of the defined utypes are to be compared
case-insensitively.

Thus, we propose the addition of a string function LOWER and the
case-insensitive variant of LIKE, ILIKE. Since case folding is a
nontrivial operation in a multi-encoding world, ADQL would only
require standard behaviour for the ASCII characters (which would
suffice for UCDs and utypes) and only recommend following algorithm R2
in section 3.13, "Default Case Algorithms" of [std:UNICODE] outside of
ASCII.
---

Thus the level where these function take a role are somehow already limited.

Cheers,
     Marco