<div dir="ltr">Dear DAL,<div>I agree with both Mark and Markus.</div><div><br></div><div>I support, among others, comments for sections</div><div><br></div><div>4.2 - table_index to be int</div><div>4.3 - generic <span class="" id=":2fd.1" tabindex="-1">datatype</span> terms</div><div><br></div><div>About referencing one version or another of the </div><div>specification I always thought a revision should</div><div>comply with the latest standard available.</div><div>This was also the reason why we slowed TAP-1.1</div><div>waiting for DALI-1.1 to be ready, while <span class="" id=":2fd.2" tabindex="-1">UWS</span>-1.1</div><div>was already there waiting.</div><div><br></div><div>Finally, I wouldn't like to see geometry support</div><div>become mandatory in 1.1, but I'm not exactly</div><div>opposing this.</div><div><br></div><div>Cheers,</div><div> Marco</div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-20 11:06 GMT+02:00 Markus <span class="" id=":2fd.3" tabindex="-1">Demleitner</span> <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank"><span class="" id=":2fd.4" tabindex="-1">msdemlei</span>@<span class="" id=":2fd.5" tabindex="-1">ari</span>.uni-<span class="" id=":2fd.6" tabindex="-1">heidelberg</span>.<span class="" id=":2fd.7" tabindex="-1">de</span></a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear DAL,<br>
<span class=""><br>
On Thu, Jul 20, 2017 at 12:30:27AM +0100, Mark Taylor wrote:<br>
> here are some comments on the recent TAP-1.1-20170707-WD.<br>
<br>
</span>+1 on them from me, and:<br>
<span class=""><br>
> Sec 2.7.2:<br>
> "... schema, table, and column names, function names, and<br>
> other ADQL keywords are not case sensitive."<br>
> I think this neglects the case of delimited identifiers.<br>
> I will leave it up to Markus or some other SQL ninja to<br>
> come up with replacement text.<br>
<br>
</span>When I read the opening of 2.7.2, I have to say I don't like it too<br>
much any more, mainly because the language makes it seem QUERY is<br>
somehow magically linked to ADQL, and services supporting other<br>
(but similar) languages may want to use something else.<br>
<br>
While the "It may also be used..." in the second sentence loosens<br>
things up, I still feel the text could be made more concise.<br>
<br>
What about the following wording, replacing the text "The QUERY<br>
parameter ... not case sensitive":<br>
<br>
When, as for instance with ADQL and other SQL-like languages,<br>
service queries are serialised to character strings in a natural<br>
way, this query is transported in the QUERY parameter. Its<br>
interpretation by the service depends on the value of the LANG<br>
parameter. Since ADQL support is mandatory for TAP services, so is<br>
QUERY.<br>
<br>
I frankly would not say anything on the case sensitivity; DALI<br>
already says parameter values are case-sensitive unless specified<br>
otherwise, and I don't think for a database query anyone would do any<br>
sort of case folding in the first place.<br>
<br>
A word on case sensitivity *might* be in order for LANG in the<br>
previous subsection, perhaps in the form of<br>
<br>
Note that, by DALI sect. 3.1, LANG values must be preserved<br>
literally, i.e., no case folding is allowed.<br>
<br>
But then I don't think we've had interoperability issues based on<br>
that in 1.0 services and clients, so it would probably be<br>
overcautious to add text like that.<br>
<br>
-- Markus<br>
<br>
<br>
[1] I'm privately feeling that references to PQL should be removed<br>
entirely from the document; it's not been forthcoming for all these<br>
years, and somehow implying it will, finally, is probably more<br>
confusing than helpful. It's a private feeling, though, because I'm<br>
not really prepared to work out possible consequences of such a<br>
removal with a standard lawyer's eye.<br>
</blockquote></div><br></div></div></div>