new TAP-1.1 WD released

[Marco Molinaro]

Dear DAL,
I agree with both Mark and Markus.

I support, among others, comments for sections

4.2 - table_index to be int
4.3 - generic datatype terms

About referencing one version or another of the
specification I always thought a revision should
comply with the latest standard available.
This was also the reason why we slowed TAP-1.1
waiting for DALI-1.1 to be ready, while UWS-1.1
was already there waiting.

Finally, I wouldn't like to see geometry support
become mandatory in 1.1, but I'm not exactly
opposing this.

Cheers,
    Marco

2017-07-20 11:06 GMT+02:00 Markus Demleitner <msdemlei at ari.uni-heidelberg.de
>:

> Dear DAL,
>
> On Thu, Jul 20, 2017 at 12:30:27AM +0100, Mark Taylor wrote:
> > here are some comments on the recent TAP-1.1-20170707-WD.
>
> +1 on them from me, and:
>
> > Sec 2.7.2:
> >     "... schema, table, and column names, function names, and
> >      other ADQL keywords are not case sensitive."
> >     I think this neglects the case of delimited identifiers.
> >     I will leave it up to Markus or some other SQL ninja to
> >     come up with replacement text.
>
> When I read the opening of 2.7.2, I have to say I don't like it too
> much any more, mainly because the language makes it seem QUERY is
> somehow magically linked to ADQL, and services supporting other
> (but similar) languages may want to use something else.
>
> While the "It may also be used..." in the second sentence loosens
> things up, I still feel the text could be made more concise.
>
> What about the following wording, replacing the text "The QUERY
> parameter ... not case sensitive":
>
>   When, as for instance with ADQL and other SQL-like languages,
>   service queries are serialised to character strings in a natural
>   way, this query is transported in the QUERY parameter.  Its
>   interpretation by the service depends on the value of the LANG
>   parameter.  Since ADQL support is mandatory for TAP services, so is
>   QUERY.
>
> I frankly would not say anything on the case sensitivity; DALI
> already says parameter values are case-sensitive unless specified
> otherwise, and I don't think for a database query anyone would do any
> sort of case folding in the first place.
>
> A word on case sensitivity *might* be in order for LANG in the
> previous subsection, perhaps in the form of
>
>   Note that, by DALI sect. 3.1, LANG values must be preserved
>   literally, i.e., no case folding is allowed.
>
> But then I don't think we've had interoperability issues based on
> that in 1.0 services and clients, so it would probably be
> overcautious to add text like that.
>
>         -- Markus
>
>
> [1] I'm privately feeling that references to PQL should be removed
> entirely from the document; it's not been forthcoming for all these
> years, and somehow implying it will, finally, is probably more
> confusing than helpful.  It's a private feeling, though, because I'm
> not really prepared to work out possible consequences of such a
> removal with a standard lawyer's eye.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dal/attachments/20170721/5cbe950d/attachment.html>