Experimenting with JAVOT
gaffney at stsci.edu
Wed Aug 14 18:07:58 PDT 2002
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
> 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">
> 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
><!-- VOTable description at http://vizier.u-strasbg.fr/doc/VOTable/ -->
> <COOSYS ID="J2000" system="eq_FK5" equinox="J2000"/>
><!-- Parameters used for the Query:
><INFO ID="Ref" name="-ref" value="VOTx23266" />
><INFO ID="Target" name="-c" value="000.000000+00.000000,rm=0.006"/>
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.
>Thanks for your tests -- I'm trying to understand the problems you quote
>#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 ?
># 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
More information about the votable