RegTAP-1.1 & ADQL-2.1 - the ILIKE concerns

[Juan Gonzalez]

Dear Marco, all, 

Let me please add another 2 cents in support of your proposal from the Euro-VO Registry point of view. We also feel ivo_nocasematch offers a well specified, already mandatory definition without the cross-database portability issues that service implementors can find between the I/LIKE implementation in their particular DB and future TAP specification evolution. 

Regards, 
Juan 


From: "Dave Morris" <dave.morris at metagrid.co.uk> 
To: dal at ivoa.net, "IVOA Registry" <registry at ivoa.net> 
Sent: Monday, August 12, 2019 1:14:15 PM 
Subject: Re: RegTAP-1.1 & ADQL-2.1 - the ILIKE concerns 

On 2019-08-12 09:10, Markus Demleitner wrote: 
> 
> there'll be two pieces of syntax that are essentially guaranteed to 
> do the same thing within what ADQL can guarantee in the first place, 
> 

There is no guarantee that the ADQL ILIKE will always behave the way 
that RegTAP requires. It may be similar at the moment, because the 
current definitions deal with ASCII only. That may change in the future. 

> So, I've backed out of requiring ILIKE in RegTAP 1.1 in volute rev 
> 5570 (diff below). I still couldn't resist the following language: 
> 
> Columns intended for presentation are not case-normalised. When 
> matching against these, queries should use case-insensitive matching, 
> for which this specification offers the \verb|ivo_nocasematch| user 
> defined function. ADQL 2.1 is expected to offer an ILIKE operator, 
> which may be used instead. 
> 
> Can everyone live with that? 
> 

Yep, I'm fine with that as long as you recognise that putting this in 
the RegTAP document does not place a requirement on DAL/ADQL to maintain 
compatibility. 

In the future DAL/ADQL may need to change the way that ILIKE handles 
regular expressions in a way that is not backwards compatible with 
RegTAP. 

Or alternatively, RegTAP may need to be more specific about how 
ivo_nocasematch searches handle UTF-8 characters in service descriptions 
in a way that is hard for some platforms to support. In which case, 
DAL/ADQL would not be required to make the same changes to ILIKE. 

I'm just looking ahead to three or four years time when one or other of 
the specifications needs to refine the behaviour in way that is 
incompatible with the other, they are free to do so and we are not 
blocked by a guarantee of compatibility. 


-- Dave 

-------- 
Dave Morris 
Research Software Engineer 
Wide Field Astronomy Unit 
Institute for Astronomy 
University of Edinburgh 
-------- 

-- 
-- 
Juan Gonzalez juan.gonzalez at sciops.esa.int 
ESAC Science Data Centre 
European Space Agency (ESA) - SERCO 

European Space Astronomy Centre (ESAC) 
Camino Bajo del Castillo, S/N Tel: +34 91 813 14 82 
Villanueva de la Canada,, 28691, Madrid, SPAIN Fax: +34 91 813 13 22 
--------------------------------------------------------------------- 

This message is intended only for the recipient(s) named above. It may contain proprietary information and/or
protected content. Any unauthorised disclosure, use, retention or dissemination is prohibited. If you have received
this e-mail in error, please notify the sender immediately. ESA applies appropriate organisational measures to protect
personal data, in case of data privacy queries, please contact the ESA Data Protection Officer (dpo at esa.int).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/registry/attachments/20190904/87108741/attachment.html>