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