SIA Evolution proposal

[Francois Bonnarel]

Hi all,
A couple of days ago I received a couple of comments from Markus Dolensky
on a preliminary version of the SIAP Evolution proposal. Here are these
comments with my answers.    

<- From a conceptual viewpoint we doubt, however, that IDHA should be 
<piggybacked onto a 'simple' access protocol; backward compatibility aside - 
<it should be the other way round: there is a hierarchical representation of 
<metadata which can be serialized into XML and it may have (CS, SIA, SSA, ADQL, 
<...) access references in it's nodes.
  ---> I think I don't agree with that. SIA/SSA are allready describing
metadata, although in a flat manner. I think it is possible to add structure
in the result in order to reflect more relationships and concepts from the
data model. If we have a totally independant hierarchical representation of
metadata we do not need SIA/SSA any more.

<- if special schema for individual object classes have already been defined 
<(http://www.ivoa.net/xml/), then they should be reused; this means (allowing 
<to) extend the vocabulary beyond the VOTable.dtd.
  ----> That's a good point but I do not see which one I could use at the
moment.

<- since IDHA is one (observation oriented) data model, we need to make 
<provisions to allow similar extensions for other (types of) models
   ----> We think the kind of mechanisms we defined is fully usable for other
data models than the single IDHA. We plan to build ans example with IVOA
Observation draft.

<- attributes in the additional tables should use the utype + URI mechanism (new 
<VOTable 1.1 feature) to uniquely identify data model items; see 
<http://www.ivoa.net/forum/votable/0327.htm
    ----> We added utypes in the example currently on line , slightly different
from the one you have seen.

<- about URL templates:
<What kind of functionality does it provide that cannot be achieved by narrowing 
<down a query using constraints like &FORMAT=MIME-TYPE?
<Remember that an SIA service can define arbitrary optional query parameters. Do 
<we have two redundant ways of achieving the same thing and if so do we need both?
    -----> This point has been extensivly discussed with Doug Tody several
month ago. For example a cutout service requires a free central position
within certain limits. See a discussion of this in :
 http://www.ivoa.net/forum/dal/0075.htm
Using arbitrary optional query parameters suppose that they can be defined
a priori fo the whole service. The URL templating is supposed to be observation
dependant.

<- the proposal does not mention any implications on querying: it seems that a 
<service has to return all possible extension tables; there doesn't seem to be a 
<way that a client can request a specific extension table like WCS info. This 
<potentially increases the overhead and required network bandwidth enormously.
    ----> This is a very good point, we totally focussed on the answer. But
the Request/answer matching will rely on the use of different classes of the
datamodel in each case I Guess. We will check this before Boston.

SAUVONS LA RECHERCHE :  <http://recherche-en-danger.apinc.org/>

=====================================================================
Francois   Bonnarel               Observatoire Astronomique de Strasbourg
CDS (Centre de donnees          11, rue de l'Universite
astronomiques de Strasbourg)    F--67000 Strasbourg (France)

Tel: +33-(0)3 90 24 24 11       WWW: http://cdsweb.u-strasbg.fr/people/fb.html
Fax: +33-(0)3 90 24 24 25       E-mail: bonnarel at astro.u-strasbg.fr
---------------------------------------------------------------------