IVOA Simple Line Access Protocol v0.2

[Doug Tody]

Pedro, Jesus, Marie-Lise, et. al. -

As I said back in the ESAC meeting, I really like the way the SLAP interface
has developed.  It is a simple, straightfoward interface which people are
likely to actually use, but it has had a lot of thought behind it, and
has a sophisticated underlying line data model.  I appreciate the effort
to make it compatible with the approach taken with the other DAL interfaces.

What follow are some notes I made while reading through the documents.
These are in not in any particular order.


Must/Should/Could

     It is not important, but it would be preferable to use Must/Should/May
     to be consistent with the W3C convention reference here (RFC 2119) and
     used elsewhere within DAL.  "May" refers to a feature which is defined
     by the interface but which is optional for a service to implement.


format=metadata

     I think you are doing the right thing by following this convention
     (from SIAP) for the present, until the matter is resolved.  The use of
     the FORMAT keyword to retrieve service metadata may change with the
     next round of interfaces - we haven't decided yet, it is still under
     consideration.  As the document states, how the service metadata is
     returned is still also under consideration.  The registry guys have
     suggested that native XML, consistent with the service description
     in the registry, be returned, instead of a VOTable as in SIA 1.0.


Use of query operators, e.g., INITIAL_LEVEL_ENERGY>370000
Wavelength spectral range as WAVELENGTH_MIN and WAVELENGTH_MAX

     The use of ">" for an open range is inconsistent with what is currently
     specified in SSA, plus I am not sure it is legal (or at least advisable)
     to do this in a GET.  We are not yet committed to what has been proposed
     for SSA, but we should agree upon a standard way to specify ranges of
     parameter values in all DAL query interfaces.  That is, in all simple
     parameter-based query interfaces; ADQL will eventually provide a general
     solution to this problem by adding a general capability for expressions.

     I think we have to assume that parameters are passed in a GET as a
     name/value pair with "=" connecting the two strings.  If for no other
     reason this is advisable as standard URL parsers will look for the "="
     to parse name/value pairs.

     Hence, all that we can finesse is the value string.  It would be
     possible to have a value string such as ">370000", however the ">"
     is not permissible in a URL and would have to be hex-encoded.  Also,
     once we start using actual expression operators it may be difficult
     to know where to stop: do we permit ">", "<", ">=", "<=", etc.?
     Since we will provide a general expression capability elsewhere, a
     simple approach is required here.

     One approach would be to provide separate equality, min, and max
     keywords for all parameters (as in WAVELENGTH above).  The chief
     problem here is verbosity, as it takes at least three such keywords
     to specify every parameter which can support ranges.  Also, what if
     the parameter is list-valued?  This approach quickly becomes unwieldly.

     The approach proposed in the current SSA spec is to use a range-list
     syntax encoded as the parameter value.  The current proposal suggests
     using a comma delimiter to specify ranges.  In this approach we would
     have "WAVELENGTH=5.1E-6,5.6E-1" and "INITIAL_ENERGY_LEVEL=370000,"
     for the examples above.  This provides a simple way to support equality
     as well as open and closed ranges, while still being easy for client
     code to parse.

     This may be a bit too simplistic as we also need to support list-valued
     parameters in some cases.  The obvious thing here is a list of values
     delimited by commas.  To avoid overloading comma, perhaps we should
     use a different metacharacter for ranges than that used for lists.
     We already have a use-case (for cube access) where we want to be
     able to specify a list of wavelength ranges to filter data along the
     spectral axis.

     This needs further thought.  It is not a hard problem but we should
     come up with a standard way to specify simple range-lists in parameter
     values.


UTYPE usage

     In general UTYPE usage in SLAP looks good (e.g., "ldm:Line.wavelength").
     An issue comes up in section 4.2 where WAVELENGTH_MIN and WAVELENGTH_MAX
     have the *same* UTYPE.  This is not permitted!  UTYPE provides a means
     to unambiguously identify individual interface elements, hence every
     such element must have a unique UTYPE.  UCDs, on the other hand, can be
     the same for multiple elements - the whole point of a UCD is to provide
     a means to say that multiple elements are the same type of value.

     In section 6.1 (standard output fields), the spec states that a field
     MUST have name="wavelength", implying that the value of NAME is used
     to identify the field in the interface.  Again, the purpose of UTYPE is
     to identify interface elements.  The data provide can assign anything
     they want to NAME; the interface should specify the value of UTYPE
     (and probably UCD as well), and the service implementor or data provider
     must return this value.  There are numerous other examples of this
     in the remainder of the section.


I read through the Line data model document but did not have many specific
comments.  It was not always clear what the units for a data model
attribute should be.  The UTYPE would be the data model element name,
e.g., "Line.wavelength", which is consistent with current usage in the
query interface.

 	- Doug