Dear Doug,
During the last STScI, CADC, ST-ECF monthly telecon, we got the action item to read and comment the SSA and the Spectrum DM document. So, it is no surprise that you receive almost at the same time both Inga's and my comments on SSA 0.97.
About 1.1 Architecture
I do share Inga's position on the fact that SSA should not force -and I'm sure that is not the intent- a data provider to only answer to a SSA query with an on-the-fly generated, so called "virtual" dataset. It is completely up to the data provider to come up with a best schema to comply to the VO, and that could very well be a "real" static and fully compliant dataset. That second sentence in 1.1 could be removed from the document without causing any damage, isn't it?
1.3.2 Parameters
"If the same parameter appears multiple times in a request
the operation is undefined."
This basically excludes the ability to provide a logical "OR" which is normally implemented using the "multiple choices" mechanism, (as in a "multiple select" or in the "check buttons" web form elements).
Isn't that a pity? How would SSAP support a logical OR in a query? Do we have to wait until ADQL is in place to see that implemented?
CreationType
The end user wants to know what kind of processing was applied
to the data; hence the user should be told if the data were binned
or mosaic'd, etc.
What is not clear to me is why the SSA service should describe only
the part of the processing it is responsible for, as the word
"Typically"
indicates in the second sentence of 2.4.2, and as indicated in the
very last
sentence in 2.4.2 (which actually contradicts that initial sentence
by forcing the creationtype to express ONLY operations happening
during the VO access).
Wouldn't be better to describe the entire end-to-end process that
brought
the data in the status they are when they rich the user's disk?
Otherwise, what is the value of such information?
Unless the intention is to notify the VO user that the same data *in different form* exist somewhere else, in case s/he is not happy with it. If that is the case, then I would suggest a simpler "original" as opposed to "reprocessed" keyword, and forget all the quite artificial distinctions.
3.3.1 Input Parameters
I think the following two sentences contradict each other, or are at least confusing to the reader (me!).
Early in the text:
At the bottom of 3.3.1:
B. "where a specific value is specified for an attribute which is undefined
for a given data collection, the service should respond by finding
no matching data."
A part from the contradiction, I like B, and do not like A.
Returning too many results is much worse than telling the user:
please refine you query because our service does not support
the input parameter you used.
Also, "A." covers two very different cases:
A1. a parameter is not specified
A2. a parameter is not supported
In the A1 case, I would agree that "all" is generally assumed. In the A2 case, the service should better bail out a warning to the user.
SPECRES
I think a SPEC_RP is the new suggested keyword for a lamdba/d(lambda), which is called resolving power, and not resolution.
Maybe a way out is to let the data provider to choose whether a FWHM (SPECRES) or a L/dL (SPEC_RP) suites better her data?
Units
In various tables (e.g. 3.3.3) the unit DDEG is mentioned, to mean decimal degrees. I do not think that is an agreed standard. To avoid troubles, I suggest you change that into "deg".
Inconsistency about fully compliant services
Ranges
1E-6/3E-7 (that is, max/min)
or
1.3/3.0 (that is, min/max)
But when an open-ended range comes along (e.g. /5) that implies a very specific order: <= 5 (ie min/max).
Minor point, but if one uses all the time the max/min order, s/he could end up getting too used to that, and use /5 to indicate >= 5.
3.3.3.15 COMPRESS
Unclear: Is that paragraph saying that
even if a client asks for compression, the server could return an
uncompressed file?
Enough for input parameters.
Alberto
Received on 2006-11-21Z15:56:31