SSA-1.1

Pierre Le Sidaner pierre.lesidaner at obspm.fr
Wed Apr 27 09:31:40 PDT 2011


some propositions of comment on SSA 1.1 (may be a bit late)

2.1 Dataset and Data Collection
dont you think a link to the VODataService document where all those 
concept are define for all vo service could be done ?
same comment on
4.1.2.14 COLLECTION

2.5.1 Data Source
artificial :  Artificial or simulated data. This is similar to theory 
data but need not be based
on a physical model, and is often used for testing purposes.
I dont understand the interest of this item : the main purpose is the 
input parameter that make a difference between simulated and 
observational data. Why don't we simply keep simulated or theoretical data


3.2 Methods & Protocols
you mention HTTP and SOAP, may be say also REST as the successor of SOAP 
in the VO

3.3.2 StageData
you mention " is not planned for SSA V1.0", may be it's 1.1

the 3.3.1 GetCapabilities and 3.3.3 GetAvailability can mention that 
this is under definition in the VOSI document and make a ref at the end 
to the proposed recommendation version at least
ref http://www.ivoa.net/Documents/VOSI/20101206/PR-VOSI-1.0-20101206.pdf
instead of 
http://www.ivoa.net/internal/IVOA/IvoaGridAndWebServices/VOSupport
InterfacesMandatory-0.26 . pd f
at the end of the document

4.1 is very confusing
first  service must support POS, SIZE, TIME, BAND then

"For example, if a client queries for data based only on the spectral 
bandpass and the service does not support the BAND
parameter, the query may overflow or be or be declared invalid."
if the service must support BAND there is no reason to declare the query 
invalid
if the service does not take into account BAND the answer would be null 
query response

4.1.1.3 BAND
earlier in the document BAND parameter is in meter as a range
then "The service may support bandpass names in the BAND parameter"
it seems that this kind of service should provide another parameter like 
bandpass_name to be query as a string with dedicated list

4.1.1.5 FORMAT
"If FORMAT is omitted, FORMAT=ALL should be assumed" don't you think it 
verbosity will increase really the size of the output votable ?

8.10.2 Overflow
It's a point I have mention before, may be I miss understand the new changes
in case of overflow no client yet redo the query with maxrec
don't you think the service should answer Overflow an produce a query 
response containing the maximum number of records. Then the client could 
at once give to the user the first N response and inform that there is 
an overflow.
is it still compliant with
   4.1.2.16 MAXREC
   " A service should typically have a
   fairly small default MAXREC, provided to improve the query response 
time, and a large
   upper limit on MAXREC, provided to enable large queries."
   that mean that the service will all the time answer an overflow and 
will not provide data ?


cheers
Pierre

-- 
-------------------------------------------------------------------------
                            Pierre Le Sidaner
                         Observatoire de Paris

Division Informatique de l'Observatoire
Observatoire Virtuel 01 40 51 20 89
61, avenue de l'Observatoire 75014 Paris

mailto:pierre.lesidaner at obspm.fr
http://vo-web.obspm.fr

--------------------------------------------------------------------------



More information about the dal mailing list