Notes/questions/issues on reading TAP 0.31

I know not all sections are normative, nevertheless I am commenting on them as well.

• s1 p4 par2: "... it is not a table containing links to data object ...". I suppose that if someone publishes a table that contains links to data sets, images or spectra, there is no problem with that. Queries might than indeed produce such links.
• s1 end p4: ".. is not visible to users." I don't see why it is a good idea to aim at completely abstracting away form a user whether there is a relational database on the backend or not. In some sense tha fact that one can send ADQL, whihc is clearly an SQL dialect, makes users expect relational database technology. Also I think if this would carry through in our message to potential TAP implementors, that they could just as well implement this on files, we'd do them a disservice. The best way to suport ADQL queries is by storing one's results in a relational database and pass the ADQL, possibly slightly adapted, to the database. Not write one's own database engine. I would also like to see some specific database features such as indexes and foreign keys show up explicitly in the metadata.
• s1 p5 par2: "... joins ... and provided the service supports these capabilities.". I would think that services MUST support joins, as those are an intricate part of ADQL and because service MUST support ADQL queries. Or is it possible to specify that one supports only a subset of ADQL?
• s1 p5 par3:".. conforming to the second generation (DAL2) interface standards [ref]." It would be really good to have this [ref] ! A lot of arguments use this homogeneous family of standards, but where is the "meta-specification" that describes this?
• s1.1.1: Confusing section. There seem to be three ways of querying for table metadata:
  1. querying standardised tables using ADQL or PARAMQUERY
  2. tableset queries
  3. VOSI queries
• s1.1.2 p6 end par2:" ... (ADQL), a standardized subset of SQL92...". Is not quite correct. Is based on SQL92, but no strict subset.
• s1.1.2 p6 par3: "... use an offtheshelf ADQL parser...". This is the problem with ADQL, that in general one can not simply pass it through to the underlying database, evenif properly supplied with the required user-defined-functions.
• s1.1.2 p6 par3: "... simplified parametric queries for the most common use cases." How do we know what the "most common use cases" are? I think this depends strongly on the database. It likely refers to the usual suspect that cone search is the most common use case, is that true? Could be changed to "some common use cases".
• s1.1.3 p6 par3: Use of UWS, which is not accepted yet, in this specification, would seem to require that TAP must define its view of what UWS is for those people who want to implement TAP before UWS is completely accepts. Same is true for possible dependencies on other not-yet-accepted standards.
• s1.1.3 p7 par1: "... there are many more advanced use cases where synchronous queries are not sufficient." I would argue that this has not much to do with how "advanced" a use case is, as with queries requiring lots of work and/or resources on the server side. The query can be as simple as "select * from table", not advanced at all, but possibly leading to timeouts/overflows for /sync queries. Whereas other queries make very advanced use of ADQL, and precisely because of that (calculating statistics on the server iso download, proper index usage, proper database design etc) can be supported with /sync just as well. And /sync is MUCH easier to implement.
• skip 1.2 for now, must be matched to normative sections.
• s2 "Requirements for a TAP service (normative)" (my italics). It seems to me that there are some requirements in this section that are aimed at clients, not the service. Should identify those and if correct should be