<div dir="ltr">Hi all,<div>thanks, Mark, for pointing out the summary slide you presented in Sydney.</div><div>Again, it gives a good view of what we&#39;re looking for at this stage (please, don&#39;t get annoyed with me if I bounce back again to the - minimal? - topic).<br><div class="gmail_extra"><div class="gmail_quote">I do like Laurent&#39;s suggestions and agree with Grégory&#39;s view.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Am I right if I say that we&#39;re converging towards a</div><div class="gmail_quote">- XMATCH seems not a good name</div><div class="gmail_quote">- we have to work out what we can do with DISTANCE given it already exists in the 2.0 version of the REC</div><div class="gmail_quote">- point vs ra/dec should both work but overload as to be nicely specified (again, requires changes wrt 2.0)</div><div class="gmail_quote">- binary versus float function type</div><div class="gmail_quote">?</div><div class="gmail_quote"><br></div><div class="gmail_quote">[my opinion is that we cannot touch what DISTANCE in ADQL already is, but we may experiment the overload solution defining it in the document]</div><div class="gmail_quote"><br></div><div class="gmail_quote">Not to a solution yet, but at least defining the goal?</div><div class="gmail_quote">And this was for the 2.1 (minor) revision.<br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Afterwards we have to better cope with the real intent of a cross match, not only with the &quot;cheap&quot; solution to smooth what is probably in-between and errata and a feature change in the current specification.</div><div class="gmail_quote"><br></div><div class="gmail_quote">May I ask if a specific session/sub-session on this may be of interest in Cape Town? (if you plan to participate)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Cheers,</div><div class="gmail_quote">    Marco</div></div></div></div>