Hi Miguel -
It is good to see some practical comments.
> (just and stylistic one: The version in the PDF says "version 0.02" it
> must be "version 0.2" isn't it?)
Thats right - thanks, I missed that.
> About service elements: (sect. 2.3):
>
> a) In parameters values (2.3.3): It would be possible to include
> "strings" as a parameter value?
> I mean, in the case of theoretical models, one of the parameters would
> be "class of model"
> with serveral string values ("chemical evolution", "estellar
> population", "spectra"...) Obviously,
> it would be "reparametrized" by a number internally by the service,
> but, having in mind the
> TSAP esquema, I am worry about how the "client of the service" may
> handle it (unless the
> VOTable resulting form ParamQuery can be handle like a "non-standard"
> HTML form in a select
> allowing an "string" to show as a value for the user, and a "number"
> as result of the form...
> (may be is a trivial question, I do not know).
String valued parameters are allowed (and are very common). This section was not intended to enumerate the possible parameter types, rather to cover some of the less obvious cases, such as allowable numeric formats. Perhaps it should be clarified (this text was just copied from the SSA spec by the way).
> b) Error response (2.3.6):
> If TAP can be used to access theoretical models, it possible to add a
> "message response"?
> I mean, an error response have a meaning about "something does not
> work in the service",
> and it will managed in someway in any workflow 8e.j. looking for other
> service or whatever)
An error response includes both the status and a message string. Probably this should be mentioned here. Since it is a small VOTable it is flexible as regards to content and can include other stuff too, such as INFOs (often we echo the input params back for example).
Note that section 2.3 is just to provide a brief summary of the technical aspects of the protocol, such as request format, error handling, etc. The details would be in section 5, which is not there yet, but which would be much the same as the equivalent section 8 from the SSA spec - the basic form and semantics of the service interface is the same for all the 2ndgen DAL services (or at least this was always the plan).
> In the case of theoretical model, it is possible to try "non physical"
> queries, or it is needed
> some cautions in the resulting data. In this case, it is not an
> "error" in the service, but a kind
> of "message" that should be taken into account in the use of the data,
> and hence it must be
> used in any workflow with a different status than an standard "error"
> message...
>
> (they are my comments for the moment, I am still reading...)
This use-case needs more elaboration. For SSA it is more clear, but how to query theoretical models with TAP is not yet clear. Usually one either gets data back, or an error response and no data. It is possible to have an arbitrary error message, but either the operation succeeds and returns data, or it fails with an error of some sort.