Comments on TAP1.0 Chapter 2

[Doug Tody]

On Wed, 12 Aug 2009, Alberto Micol wrote:

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

For the record, UTYPE was invented in a visit I made to CDS (around
2004 or so) where we discussed DAL needs and what to do about the
"VOX:xxx" UCDs in use in SIA.  It is just that the first formal mention
of UTYPEs was in the VOTable context.  While we are very glad to have
UTYPE support in VOTable, there is nothing VOTable specific about
a UTYPE.

The original concept for UTYPE was always that it specify the elements
of a formal interface, be it a service interface or a data model
(which is also a type of interface albeit with more complex semantics).
In a service for another example, the service operations and their
input parameters might be assigned UTYPEs.  While this is not normally
needed it could be used for example if we used separable parameter
sets to pass the parameters for a service operation.

Another more data model specific example is that any time a data model
is used in a service interface the service may effectively subclass the
data model, or inherit from multiple data models (e.g. aggregating them
into a new model), in which case it is the service interface which has
the last word on the data model as defined by the service.  Hence in
SSA, the service interface model is defined by SSA.  This model is
based primarily upon Spectrum and GDS/Obs, but SSA adds some things,
redefines what is optional/mandatory in the SSA queryData context,
further constraints units, etc.

This sort of thing is very typical, and is needed, when we use data
models in a specfic application such as a service interface.  The most
"stand alone" use of a data model is for a data instance such as a
Spectrum, Image, etc.

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

I never liked these repeated parameters either; perhaps the time
has come to strengthen the rule.  Note that with the addition of
/sync and /async to baseURLs (done with simple string concatenation)
it is no longer possible to embed a "hidden" parameter in a baseURL,
which is what people have long done.  What people used to do is
have baseURLs like "/foo/bar/conesearch?survey=nvss?".  While this
has been popular and useful it may no longer even be possible, and
is probably needed much less for the DAL2 services since most common
cases are now covered by formal parameters.

That said, I have used the flexibility occasionally myself, e.g.,
to add REQUEST and VERSION to legacy cone search etc. service
implementations to allow easier use of a modern DAL2 service framework
to implement such services.  This is perfectly legal for these older
protocols.  Unfortunately or otherwise this is something we will lose
with the adoption of /sync /async type constructs.

 	- Doug