URL templating in SIAP

Fri Oct 31 09:43:26 PST 2003

Hello Dal people,
   Two weeks after the interoperabilty meeting I come back to the URL
templating debate.

   If I remeber well there has been a couple of remarks about my
proposal in the DAL session in
strasbourg.
   a ) Use case: I have one , Suppose you want to write a nice
interface to a SIA service.
  In case a lot of URL refer to the same observation with only
"production" parameters differing
  from one to another, you would like to display this observation as
single to the user and propose
  him list of parameters. With SIA like it is today , once you have
recognized that a couple of lines
  refer to the same observation, you have to analyse all the URL to find
out all the differences: not
  really nice. That's why I think templating the URL could be usefull.
  b ) What was my (quick and dirty) proposal in two words:
         refer to the variable parameters as $"PARAMETER_NAME" in the
URL template
         the PARAMETER_NAME can be either:
                       an image genaration parameter as defined in
SIA 1.0
                        or a service specific parameter defined as a
"PARAM" element in the VOTable.
                        (possible values were strings separated by
blanck in my proposal in the character case
                            ---> could be variable length character
array in VOTable 2)
     c ) the first remark I heard was (Roy Williams) : Keep it simple
!!!
           I can understand that Roy, but Templating the URL could be
only an option, don't prevent a service
to write only URLs : should be undersood by the clients: an URL is a
template with no variable at all!
     d ) Use something cleaner like xpath (Markus Dolensky and others):
            Is it more easy to implement?
      e ) Do not template only the URL : Why not templating in Votable
Fields in general.
              What do the VOtable people think ?
      f ) Use Web service methods (getImage with parameters) instead of
URL templates (Doug Tody)
          ca you describe how it could work with an example Doug? can we
live with getImage as a real
          web service method and ImageQuery as simple URL? If ImageQuery
is a real Webservice method
          will the client see the VOtable anymore ?

Best regards
Fran=E7ois

--
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
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
---------------------------------------------------------------------
--------------25A062583FC65BFA5F0DD959
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit
<!doctype html public "-//w3c//dtd html 4.0 transitional//en">
<html>
Hello Dal people,
<br>   Two weeks after the interoperabilty meeting I come back
to the URL templating debate.
<p>   If I remeber well there has been a couple of remarks about
my proposal in the DAL session in
<br>strasbourg.
<br>   a ) Use case:  I have one , Suppose you want to write
a nice interface to a SIA service.
<br>  In case a lot of URL refer to the same observation with only
"production" parameters differing
<br>  from one to another, you would like to display this observation
as single to the user and propose
<br>  him list of parameters. With SIA like it is today , once you
have recognized that a couple of lines
<br>  refer to the same observation, you have to analyse all the URL
to find out all the differences: not
<br>  really nice. That's why I think templating the URL could be
usefull.
<br>  b ) What was my (quick and dirty) proposal in two words:
<br>         refer to the variable
parameters  as $"PARAMETER_NAME" in the URL template
<br>         the PARAMETER_NAME
can be either:
<br>                      
an image genaration parameter as defined in SIA 1.0
<br>                       
or a service specific parameter defined as a "PARAM" element in the VOTable.
<br>                       
(possible values were strings separated by blanck in my proposal in the
character case
<br>                           
---> could be variable length character array in VOTable 2)
<br>     c ) the first remark I heard was (Roy
Williams) : Keep it simple !!!
<br>           I can
understand that Roy, but Templating the URL could be only an option, don't
prevent a service
<br>to write only URLs : should be undersood by the clients: an URL is
a template with no variable at all!
<br>     d ) Use something cleaner like xpath (Markus
Dolensky and others):
<br>           
Is it more easy to implement?
<br>      e ) Do not template only the URL : Why
not templating in Votable Fields in general.
<br>             
What do the VOtable people think ?
<br>      f ) Use Web service methods (getImage
with parameters) instead of URL templates (Doug Tody)
<br>          ca you describe
how it could work with an example Doug? can we live with getImage
as a real
<br>          web service
method and ImageQuery as simple URL? If ImageQuery is a real Webservice
method
<br>          will the client
see the VOtable anymore ?
<p>Best regards
<br>François
<br> 
<pre>-- 
=====================================================================
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
---------------------------------------------------------------------</pre>
 </html>
--------------25A062583FC65BFA5F0DD959--