SSA working draft

[Alberto Micol]

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:

A. "if a given parameter is not specified or is not supported by the  
service,
a logical value of "all" is generally assumed."

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
---------------------------------------------
3.3.3 initial sentence states that "all" the "should or may" parameters
are required for a fully compliant service. I think that is wrong
and does not match with 1.4.1.
Only the "should" parameters are required for a fully compliant service,
isn't it?



Ranges
----------

1. Why not allowing ranges in all (at least numerical) fields?

2. Apparently there is no mandatory order when specifying a range;
in many examples throughout the entire document one can find
both:

   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