Comments on TAP1.0 Chapter 2

[Alberto Micol]

On 12 Aug 2009, at 18:13, Doug Tody wrote:

> 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.

ok

>
>> 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.

This is not what many people think the utype should be.
We have always used the VOTable1.1 definition of UTYPEs (given that it  
was invented
there for votable specific reasons), and there it is clearly defined  
to be a pointer to a
Data Model element, not to an interface element.
We still miss an official specification about UTYPEs, their scope, etc.
That's why there is some confusion.


>
>> 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.
>
And I never liked that either... ;-)
It would be very nice (for the users!) to strengthening the rule!


>> 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.
>
But the specs makes catalog optional and schema required by writing:
  [catalog.]schema
That needs clarification.

Thanks,
Alberto