Experimenting with JAVOT

[Niall Gaffney]

Fancois,

Its not a problem with the service that I was trying to illustrate in 
this table but rather the inconsitancy of failure modes for different 
cone searches.  It was as I tried to write a tool with JAVOT for the 
cone search that this became an issue.  What I wast trying to do was 
look at the JAVOT package and see how it worked with the Cone Search 
services.  After I got it working I found very quicky that it worked as 
expected for this parser and while many others did not to different 
degrees...so I started digging into what was going on and here we are 
now. Its not to say that this is bad or even unexpected as the hardest 
thing to address is how to address things you didn't expect.  This is 
one thing to do on a web page or even a program you have control over, 
but when you try to integrate an external set of services to an program 
using someones library, the issues become clear.  

The cone search guidelines has prescribed things that should happen when 
a query is malformed as described in 
http://us-vo.org/metadata/conesearch/.  I found it after my first email 
in this thread...error handling is often the last thing we think about 
when creating things.  Section 3 reads

> The service will respond with a stub version of the VOTable in the 
> case of error. This could happen if the three parameters (RA, DEC, SR) 
> are not all present, or if they cannot be parsed to floating-point 
> numbers, or if the numbers are bad (DEC=91.0 for example). The service 
> may also make an error return if the Search Radius is larger than the 
> MaxSR parameter of the Resource Profile (see below).
>
> In the case of error, the service MUST respond with a VOTable that 
> contains a single parameter called *Error*, where the corresponding 
> value should contain some explanation of the nature of the error. An 
> example of such an error return is here 
> <http://us-vo.org/metadata/conesearch/cover2.xml>.
>
> Other conditions may NOT be considered erroneous, for example if a 
> query cone is in the Southern hemisphere and the catalog coverage is 
> in the Northern hemisphere. This type of query is different from an 
> error return; it should return a VOTable as described above, with 
> metadata, but no data records. In particular, a zero value of Search 
> Radius should not return an error condition. This is because an 
> application may be more interested in the metadata than the data, and 
> send a fixed query (for example RA=0&DEC=90&SR=0) simply to discover 
> the fields delivered by the service.
>

So wrapping around the poles several times to get to a projected dec of 
20000 is not what should happen according to this.  However it is 
something that someones program could put into the field if it was 
speeking in the wrong units (arc seconds of declination say).  For this 
service its probably no big deal to debug that one, but for more complex 
ones it might not be.  

The responce to the query with no objects returned a VOTable document 
with no table of objects or meta data in it:

><?xml version="1.0" encoding="UTF-8"?>
><!DOCTYPE VOTABLE SYSTEM "http://vizier.u-strasbg.fr/xml/VOTable.dtd">
><VOTABLE version="1.0">
> <DESCRIPTION>
>   VizieR Astronomical Server: vizier.u-strasbg.fr 	2002-08-15T00:54:34
>   Explanations and Statistics of UCDs:			See LINK below
>   In case of problem, please report to:	question at simbad.u-strasbg.fr
> </DESCRIPTION>
><!-- VOTable description at  http://vizier.u-strasbg.fr/doc/VOTable/ -->
>
><DEFINITIONS>
>  <COOSYS ID="J2000" system="eq_FK5" equinox="J2000"/>
></DEFINITIONS>
>
>
><!-- Parameters used for the Query:
> -source=GSC2
> RA=0
> DEC=0
> SR=0.0001
> VERB=
> -->
>  
>
><INFO ID="Ref" name="-ref" value="VOTx23266" />
><INFO ID="Target" name="-c" value="000.000000+00.000000,rm=0.006"/>
></VOTABLE>
>
It is as a whole that these descrepancies are an issue as the program 
expects everyone to respond to things the same way.

There was really only the one test I could make of the Vizier services 
as the cone searches listed in the registry had the same Name key for 
many services.  So this was for the Vizier GSC2.   Again this is not the 
fault of Vizier but rather that the Cone Search registry needs to make 
certain it has a unique key for each service, which is a separate issue 
we will need to look at when we start to look into registries at large.

As I have said before we are focusing on getting to the demos for the VO 
and that should take top priorty right now.  I just want to make sure we 
also look at where things are not quite right, make note,and address 
them as we can to learn what we need to have in place to support all the 
services that will go into the VO.  

Niall

>Hi Niall,
>
>Thanks for your tests -- I'm trying to understand the problems you quote
>about vizier:
>
>#Vizier on GSC2      works          no table in votable
>#      returned objets at RA = 0 and dec = 20000 which were at RA = 180 and dec
>#      = -20
>What is the meaning of "no table in votable" ? 
>     <VOTABLE> contains a <RESOURCE> which itself contains a <TABLE>,
>     what is missing ?
>     And my guess about RA=0 and Dec=20000 should be OK if you allow
>     Dec outside the (-90,+90) range -- each time you pass through the pole
>     both RA and Dec increases or decrease by 180deg to reset the
>     point in the 'legal' range. Do you mean that
>     values outside the 'legal' range have to be refused ?
>
>#VizieR
>#    did not have required UDCs for ID, RA and Dec
>   which of the examples did you take ? Did you get a lot of tables,
>   just some wihtout UCDs, or is it another problem ?
>
>Again, thanks for your tests !
>================================================================================
>Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
>   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
>Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
>================================================================================
>  
>