Hi Carlos and Miguel,
thanks for your information about the "TSAP test application". I did not know that one, but find it very useful to do some further testing and debugging of my metadata response. (Of course I am glad to hear that some of the problems are just caused by different versions of the standard.)
To answer Gerard's question:
I believe that also VOSpec did not deal correctly with our SSA service, until some extra custom work was performed (correct Ulrike?).
VOSpec's problem first was to harvest the registry automatically and to "detect" new SSAP servers for theoretical data. Once our server was on their "private TSAP list" it was no problem to post a "format=metadata" query via a VOSpec client. However, VOSpec still is not able to interpret our metadata response, because I used min and max values (according to the standard). They are working on this, I was told.
In the end every SSA service should respond to format=metadata with the parameters they support and clients should (eventually) make use of this information to at least not send positional queries to services that do not support them, and once all metadata is there (getCapabilities will hopefully use the requirements form this discussion) GUIs can be generated that capture also more generic queries.
That was exactly what I had in mind, when I posted my suggestions about theoretical SSA to the mailing lists: encourage all client developers to support more generic queries. I agree with Gerard in that it is not a problem of the protocol specification.
You may think of different possible solutions regarding the client user
interface:
e.g.1) start any SSA dialogue (regardless of observational or
theoretical spectra) with a format=metadata request and base the
following query on the parameters given : this is a very general way
but would probably not be very ergonomic for users who are only
interested in "standard" parameters like pos and time, because it
complicates the dialogue and makes it more difficult to address several
services with one query. On the other hand an "intelligent" client might
be able to hide this dialogue from the user if it recognizes that only
standard parameters are returned from all servers it questioned for
metadata.
2) create two different GUIs: one for observational, one for theoretical
SSA (like VOSpec does), the observational one uses standard parameters,
the theoretical one starts the format=metadata dialogue with following
generic queries. For this approach the client must be able to recognize
the difference between observational and theoretical SSA servers when
harvesting the registry.
3) If it is true what Petr Skoda stated i.e. that 90% of theoretical
spectra use temperature, gravity and metallicity as parameters, you
might even think of standardizing these additional optional parameters
within SSAP. Thus clients could query several theory SSA servers within
one query based on those "quasi-standard" parameters.
4) GUIs could offer a broader selection of parameters to enter e.g. the
mandatory ones + the typical theoretical ones . This would send
queryData-requests to all kinds of servers and the servers themselves
have to decide wether they can fulfill this request or not: A
theoretical server that receives a request containing mandatory
parameters like pos or time will return "no result" (as defined in the
standard specification already). An observational server that receives a
request without mandatory parameters will probably answer with an
overflow error because there are no constraints it can use. I admit it
is not a nice way to use error responses within a normal workflow.
Of course, an additional parameter could specify which kind of data to
search: either "theory" or "observation", then you could send it
directly to the correct selection of servers....
I would be happy to hear of any efforts to create clients for
theoretical spectra access.
Cheers
Ulrike
Received on 2007-10-16Z07:44:50