<div dir="ltr">Hi all,<div>relaxing language on TAP data-side (i.e non TAP_SCHEMA) arose as an idea to let people deploy TAP service in compliance with the spec but having problems with ADQL for two main reasons:</div><div>- no SQL-like backends</div><div>- in-ADQL-geometry issues</div><div><br></div><div>However, apart from the technical problems discussed by Pat's and Markus' mails yesterday, removing the ADQL recommendation from the TAP tableset access will leave us with a spes where only the discovery of the tablesets description is standard and afterwards, clients will require, possibly, service-ad-hoc query building for each service deployed. I have to say I don't like this at all.</div><div><br></div><div>So probably the "ADQL with respect to no SQL (whatever this means) and geometry wrt various backends" should be moved out of TAP-1.1 way. I agree with Markus and Pat that implementation should lead the way to this change.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><div class="gmail_extra"><br><div class="gmail_quote">2015-09-29 21:24 GMT+02:00 Patrick Dowler <span dir="ltr"><<a href="mailto:patrick.dowler@nrc-cnrc.gc.ca" target="_blank">patrick.dowler@nrc-cnrc.gc.ca</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
NoSQL was an example of the kind of thing this is about... and you could be right that the status quo is sufficient.<br>
<br>
My impression was that this was something that people outside the ivoa looking in were interested in and that it could make it clear that TAP was the solution they needed even without a RDBMS. Realising that you can get away with a subset of ADQL and do something valuable is something people usually discover by committing to TAP and then just trying to do it... but the big projects that CSP is interested in satisfying are maybe not likely to do that.<br>
<br>
Pat<div class="HOEnZb"><div class="h5"><br>
<br>
On 29/09/15 10:57 AM, Walter Landry wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Patrick Dowler <<a href="mailto:patrick.dowler@nrc-cnrc.gc.ca" target="_blank">patrick.dowler@nrc-cnrc.gc.ca</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
I'm not very familiar with NoSQL query syntax, havig only hacked<br>
around with ElasticSearch in the context of log analysis... but the<br>
query language wouldn't be in TAP and it would surely take some time<br>
to make it a standard rather than custom lang...<br>
</blockquote>
What I am wondering is if there is a simple mapping from this NoSQL<br>
query syntax to ADQL. My impression is that the NoSQL syntax can be<br>
expressed as a subset of ADQL. In that case, you are not looking so<br>
much for extension as for a way to subset. I already have to subset<br>
ADQL for my services. When I gave a talk about this at Sesto, the<br>
consensus was to let unsupported queries fail. So I am not sure that<br>
anything needs to be done now.<br>
<br>
Cheers,<br>
Walter Landry<br>
<br>
<br>
</blockquote>
<br>
<br></div></div><div class="HOEnZb"><div class="h5">
-- <br>
Patrick Dowler<br>
Canadian Astronomy Data Centre<br>
National Research Council Canada<br>
5071 West Saanich Road<br>
Victoria, BC V9E 2E7<br>
<br>
<a href="tel:250-363-0044" value="+12503630044" target="_blank">250-363-0044</a> (office) <a href="tel:250-363-0045" value="+12503630045" target="_blank">250-363-0045</a> (fax)<br>
<br>
</div></div></blockquote></div><br></div></div></div>