Comments on TAP1.0 Chapter 2

[Doug Tody]

On Wed, 12 Aug 2009, Alberto Micol wrote:

> par 2.3.6 FORMAT: I would have claimed useful to optionally support latex 
> (application/x-latex);
> can a service use a FORMAT not listed in that table?
> This should be clarified in that pararaph.
> -- The sentence "should reject queries with unsupported formats" might be 
> read in two ways:
> -- 1. a latex query is to be rejected by my service
> --    because is not listed in the TAP FORMAT  table
> --   (despite the fact that my service supports it)
> -- 2. a latex query is accepted by my specific service--   because my service 
> supports latex
> --   (despite the fact that it is not mentioned in the TAP FORMAT table).
> -- Which one of the two is valid? if (2) is valid, how does someone get
> -- to know that such service supports latex (it is not listed in the
> -- getCapabilities, is it?) ?

In general with all the DAL services any MIME type may be specified for
the FORMAT, including service-custom types (for example for specific
native data formats).  In the case of TAP since this is not a discovery
query it has to be an error if an unsupported FORMAT is specified.
getCapabilities would specify the formats supported by the service
as well as all other service capabilities.  You are probably right
that this could be clarified slightly in the document.

> par 2.3.8 MTIME utypes
> Some utypes (Record.Modified and Record.Deleted) have been introduced for 
> MTIME.
> It makes me think that a Data Model for a Record exists, but nowhere is it 
> mentioned in the document.
> A utype should not be created by a protocol.
> I think UCDs should be created and used instead.

I don't agree with this Alberto.  UTYPEs can be used to identify
interface elements as well as data model elements.  They provide a
means to identify an element of any such formal structure.  A service
specification is just as capable of specifying UTYPEs formally as
a data model specification.  It is just that if a data model is
reusable in more than one place we prefer to separate it out as a
separate specification.  But this is not required.

> par 2.3.12 When request parameters are duplicated with conflicting values, 
> the response
> from the service is undefined (may reject or pick up any value and continue).
> Wouldn't be better to impose the service to fail (and issue a specific error) 
> in such cases?
> The risk of providing the wrong answer, without the user noticing, is in my 
> opinion not acceptable.

Note that the service *can* issue an error response in this case,
and most should do so.  The weasel words about "undefined" were to
give the service some scope to break this rule in special cases.
This comes from DAL2/SSA and was mostly motivated by the use of
parameters in base-URLs in older DAL services.  I would be ok with
strengthening the rule, although it would be nice to be consistent
about this in all the DAL2 services so that common operation/parameter
processing code can be used.

Here is what it says about this in "Basic Service Elements" in the
SSA spec (this section was intended to specify basically the same
semantics in all the services):

     (8.7.1) When request parameters are duplicated with conflicting
     values, the response from the server may be undefined. This
     document does not mandate which of the duplicated values sent by
     the client are to be used by the server. It is recommended that
     neither the client nor the service should repeat parameter values
     in a query URL.

> par 2.6.1 Schemas
> Such table is useless if my dbms does not support schemas,
> nevertheless in 2.6 and in 2.6.4 is written that services must provide it.
> How to get out of this impasse? changing "must" into "should"?
> Providing a schemas table with no records?

A given DBMS may provide only "catalogs", only "schemas", or both (in
the DBMS sense).  What TAP_SCHEMA calls a "schema" could be implemented
with either a catalog or a schema within the underlying DBMS, hence
it should be a useful abstraction for any DBMS.  Some such construct
is needed to organize data in any complex tableset.  Note the fully
qualified table name syntax supports both catalogs and schemas hence
it is possible to pass actual DBMS table names out in table metadata
queries and get them back as-is in subsequent data queries.

 	- Doug