validation of SIA 2

James.Dempsey at csiro.au James.Dempsey at csiro.au
Thu Feb 25 07:51:12 CET 2016 

Hi Pierre,

Thanks for the test validator. That helped me trace the issue to the use of https URLs. I've temporarily activated non-secure connections to our service and have been able to run the validator against it.

A few things I noticed when running against http://casda.csiro.au/casda_vo_tools/sia2/query?
1. https doesn’t seem to work, as noted above.

2. I see a "Warning: file_get_contents(./services/Simple Image Access 2.0-test.txt): failed to open stream: No such file or directory in /share/web/voparis-validator/index.php on line 44" on the validator form.

2. DTYPE should be DPTYPE according to section 2.1.14 (this is corrected on the Simple Image Access 2.0-test page)

3. It would be nice to have a blank option in the DPTYPE drop-down in the validator

4. The messages for rejected fields are a bit difficult to interpret. Would it be difficult to pull out which of the ucd, utype, type or unit is incorrect? As an example I receive the validation error 

Error: one FIELD or PARAM s_ra should have ucd="pos.eq.ra", with utype containing"Char.SpatialAxis.Coverage.Location.Coord.Position2D.Value2.C1", and s_ra, and double or adql:DOUBLE , and deg, is missing, or some of its required attributes are missing or erroneous No match found.

My field def is <FIELD name="s_ra" ID="s_ra" datatype="double" unit="deg" ucd="pos.eq.ra" utype="obscore:Char.SpatialAxis.Coverage.Location.Coord.Position2D.Value2.C1" >

So I'm guessing it is the utype, but a close read is needed for each message to determine the issue.

5. The utype validation seems to be objecting to the obscore: prefix as every field is marked as being in error. Appendix B of ObsCore v1 20111028 specifies this as required.

6. It would be nice to have lack of a schema location as a warning rather than showing as an invalid VO table.

7. In batch mode the parameter values are not URL encoded.

8. Returning a VOTable v1.3 is marked as invalid - while the 1.2 version is listed as a reference, the link goes to the current VOTable recommendation, which is v1.3. We've assumed that means the latest version is legal.

Cheers,
James.

-----Original Message-----
From: Pierre Le Sidaner [mailto:pierre.lesidaner at obspm.fr] 
Sent: Wednesday, 24 February 2016 9:06 PM
To: Dempsey, James (IM&T, Yarralumla) <James.Dempsey at csiro.au>; dal at ivoa.net
Subject: Re: validation of SIA 2

Dear James

On 02/23/2016 07:56 AM, James.Dempsey at csiro.au wrote:
> Hi Pierre,
>
> It's great to see a validator for SIA2. Thank-you!
>
> I tried to run it myself but kept getting a " Fatal: Error while retrieving data. Is the remote service URL correct?" so I am assuming I am not putting my URL in correctly. It could also be caused by us not recognising (and thus rejecting) the REQUEST parameter. If the REQUEST parameter is the issue, could you show the error message coming back from the service please?
did you try with a ? at the end of the URL
>
> Speaking for the CASDA implementation:
> 1. We added support for +Inf and -Inf ranges in our last release, around two weeks ago. A query with BAND=0.21 +Inf will work so long as the + is URL encoded.
nice
>
> 2. Was the schema location a request to implementers? We could add that to our response if so.
If we want to validate the VOTable it 's much more convenient to have the associated schema for it. And it's not unusual to see non valid VOTable.
It's a request from me to the DAL group
>
> 4. We removed support for the REQUEST parameter as it was removed from the SIA2 spec in version WD-SIA-2.0-20140707. I see it is still in the examples though, which is confusing.
Ok Could one of the author of SIA modify the example that is wrong ?
It's really important if you want to have valid services and be able to use them
>
> 5. It might be worth checking the obscore validator in taplint for what it enforces in Obscore. I know our SIA2 response is a reuse of the obscore TAP response, so we would prefer to see them have exactly the same requirements.
Ok I have check only the parameters that are explicitly describe in the
SIA2 document
>
> 7. With MAXREC I would assume you need to test that you get no more results than requested and that if a query with a lower MAXREC gets less results then it should have an overflow entry. I've just noticed that we do limit the results returned but don’t provide an overflow entry. We'll fix that in our next release.
My question was more : should I put MAXREC as a "mandatory" parameter that the service must handle ?
This is not clear for me regarding the SIA2 documentation


until the problem of REQUEST parameter is solved, I put a test validator 
of SIA2 (choose Simple Image Access 2.0-test)  same as the other one but 
with no REQUEST=query and no Inf in the parameters request
it work wth your url http://casda.csiro.au/casda_vo_tools/sia2/query?
as in the other one, I have put as mandatory Xtype and datatype in the 
VOTable response
Let me know about all errors in the validation, I'll try to be reactive

Regards
Pierre
>
> Cheers,
> James Dempsey
>
>
> -----Original Message-----
> From: dal-bounces at ivoa.net [mailto:dal-bounces at ivoa.net] On Behalf Of Pierre Le Sidaner
> Sent: Tuesday, 23 February 2016 5:15 AM
> To: dal at ivoa.net
> Subject: validation of SIA 2
>
> Dear All
>
> I was working on the SIA2 validator on the last days I have a first version as a draft http://voparis-validator.obspm.fr
>
> I try it with the 3 examples taken from RFC Page http://wiki.ivoa.net/twiki/bin/view/IVOA/Siav2RFC
> The SIA2 document is confusing because it refer to ObsCore without telling exactly what is mandatory.
> Moreover I have question about SIA V2 and the implementations
>
> * non of them support Inf as > or < of as it's proposed in the last documentation of sia2 like BAND=300 +Inf
>
> * could you please reference the schema in votable to validate it, something like
> xsi:schemaLocation="http://www.ivoa.net/xml/VOTable/v1.3
> http://www.ivoa.net/xml/VOTable/VOTable-1.3.xsd"
>
> * for Utype example use an extension in the Utype name like
> obscore:Char.SpatialAxis.Coverage.Location.Coord.Position2D.Value2.C1
> but as the Utype come from Characterisation, is it relevant to add obscore, specially taking into account that Utype should be normalized.
>
> * for request in the query. In the example inside the document, REQUEST take the value query. Nothing in the documentation is related to DALI for that. http://dalservices.ivoa.net/sia_b?REQUEST=query&POS=CIRCLE
> 180.475 -18.70 0.01&BAND= 0.0008 0.0009&TIME= 55708 55710&COLLECTION=ALMA. It should be more explicit in the documentation.
> And one ref implementation does not support this parameter/value.
>
> * what about datatype and xtype are they both mandatory in the votable output ? for s_region, s_fov ... in Obscore document there is both adql:REGION and AstroCoordArea does both are acceptable. VOTable schema should include a list of xtype if it's possible
>
> * don't you see any problem as s_resolution have datatype=float and xtype=adql:DOUBLE and sometime double in obscore doc.
>
> * what should I do with MAXREC, I mean what to test ?
>
>
>
> The 3 examples I took where
>
> http://www.cadc-ccda.hia-iha.nrc-cnrc.gc.ca/sia/v2query?
> it was my reference for test, if you try you must remove all the Inf
>
> casda implementation
> http://casda.csiro.au/casda_vo_tools/sia2/query
> does not support Request=query,
>
>
> VAO implementation
> http://vaosa-vm1.aoc.nrao.edu/ivoa-dal/siapv2-vao/sync?
> problem with DTD on votable
>
>
> Please give feedback about the validator, I am sure there is some bogus left.
>
> Regards
> Pierre
>
> --
> -------------------------------------------------------------------------
>                              Pierre Le Sidaner
>                           Observatoire de Paris
>
> Direction Informatique de l'Observatoire Observatoire Virtuel 01 40 51 20 82 61, avenue de l'Observatoire 75014 Paris
>
> mailto:pierre.lesidaner at obspm.fr
> http://vo.obspm.fr
>
> --------------------------------------------------------------------------
>


-- 
-------------------------------------------------------------------------
                            Pierre Le Sidaner
                         Observatoire de Paris

Direction Informatique de l'Observatoire
Observatoire Virtuel 01 40 51 20 82
61, avenue de l'Observatoire 75014 Paris

mailto:pierre.lesidaner at obspm.fr
http://vo.obspm.fr

--------------------------------------------------------------------------

More information about the dal mailing list