RegTAP rec. : lowercasing name in table intf_param

Mon Mar 24 07:30:09 PDT 2014

Dear all, 

This is a question on the current version of the RegTAP recommendation. 

In section 7.9 that discusses the ' intf_param ' table: 

http://www.ivoa.net/documents/RegTAP/20140227/PR-RegTAP-1.0-20140227.html#table_intf_param 

... there's a requirement to lowercase the ' name ' column (the requirement comes from the clause " The remaining requirements and conventions are as per section 7.7 where applicable " at the end). 

However, there appear to exist resources that use names that only differ in case distinguish between parameters. I append one such at the end of this email. You will observe it uses " format " and " FORMAT " as the value of ' name ' in two different parameters: 

<param use="required"> 
<name>format</name> 
... 
<dataType>string</dataType> 
</param> 
... 
<param use="optional"> 
<name>FORMAT</name> 
... 
<dataType>string</dataType> 
</param> 

Others may also exist (or may come into existence in the future) and a similar issue is also possible for the ' table_column ' table in Section 7.7 (from which this lowercase requirement originates after all). Yet, similar issues in ' table_column ' are less likely due to the practice of distinguishing table columns solely on name case being frowned upon even in RDBMSs that allow it. 

But back to the " intf_param " table, lowercasing the ' name ' parameter will result in important information loss for this particular resource. 

I see only two options here: 

[1] we treat this and any other similar resources as singularities and are indifferent to the information loss (arguing perhaps that the authors shouldn't have relied on case - which may be a different argument to make given that the resource is XSD valid). 
[2] we drop the lowercasing directive for ' name ' in table ' intf_param ' (perhaps also cascading the drop to the lowercasing directive for ' name ' in table ' table_column ' to maintain the specification symmetry). 

Kind Regards, 
Menelaus PERDIKEAS. 

---%<---------------------- 

<ri:Resource xmlns:ri=" http://www.ivoa.net/xml/RegistryInterface/v1.0 " xmlns:stc=" http://www.ivoa.net/xml/STC/stc-v1.30.xsd " xmlns:xlink=" http://www.w3.org/1999/xlink " xmlns:vr=" http://www.ivoa.net/xml/VOResource/v1.0 " xmlns:vs=" http://www.ivoa.net/xml/VODataService/v1.0 " xmlns:xsi=" http://www.w3.org/2001/XMLSchema-instance " created="2009-05-26T16:35:28.84" status="active" updated="2009-06-17T21:40:08.55" xsi:type="vs:DataService"> 
<title>Simple Image Access Service Validater</title> 
<shortName>SIAvalidater</shortName> 
<identifier>ivo://nvo.ncsa/validater/SIA</identifier> 
<curation> 
<publisher ivo-id="ivo://rai.ncsa/RAI"> 
NCSA Radio Astronomy Imaging </publisher> 
<creator> 
<name>Dr. Raymond Plante</name> 
<logo> http://nvo.ncsa.uiuc.edu/UofI-NCSA-black_logo_color.md.jpg </logo> 
</creator> 
<date> 2006-01-01 </date> 
<contact> 
<name>Dr. Raymond Plante</name> 
<email> rplante at ncsa.uiuc.edu </email> 
</contact> 
</curation> 
<content> 
<subject>virtual observatory</subject> 
<subject>standard service</subject> 
<subject>validater</subject> 
<subject>validator</subject> 
<subject>publishing</subject> 
<description> 
This service will validate another service that claims to be compliant 
with the Simple Image Access standard (ivo://ivoa.net/std/SIA). It does 
this by sending the service a series of queries and rigorously comparing 
the response with the SIA specification. The SIA service providers can 
use this validater service to check their implementations. This is 
typically done via the interactive web page interface which (at a 
minimum) accepts the SIA service's base URL. For each query that it 
sends, it will return a list of compliance errors, warnings, and 
recommendations. This service also has a REST-like programmatic 
interface. This can be leveraged by IVOA registries to check the 
compliance of registered SIA services and to set the "validationLevel" in 
the service's resource record. 
</description> 
<referenceURL> http://nvo.ncsa.uiuc.edu/dalvalidate/siavalidate.html </referenceURL> 
<type>Other</type> 
</content> 
<capability> 
<interface xsi:type="vs:ParamHTTP"> 
<accessURL use="base"> 
http://nvo.ncsa.uiuc.edu/dalvalidate/siavalidate.html </accessURL> 
<resultType>text/xml</resultType> 
<param use="required"> 
<name>endpoint</name> 
<description>the base URL for the SIA service being tested</description> 
<ucd>meta.ref.url</ucd> 
<dataType>string</dataType> 
</param> 
<param use="required"> 
<name>RA</name> 
<description>the ICRS right ascension of a position that in part defines a search region that, when sent to the service, will return at least one matched record</description> 
<unit>degrees</unit> 
<ucd>pos.eq.ra</ucd> 
<dataType>real</dataType> 
</param> 
<param use="required"> 
<name>DEC</name> 
<description>the ICRS declination of a position that in part defines a search region that, when sent to the service, will return at least one matched record</description> 
<unit>degrees</unit> 
<ucd>pos.eq.dec</ucd> 
<dataType>real</dataType> 
</param> 
<param use="required"> 
<name>RASIZE</name> 
<description>the angular distance along the ICRS right ascension access that in part defines a search region that, when sent to the SIA service, is expected to return at least one record</description> 
<unit>degrees</unit> 
<ucd>pos.angDistance;pos.eq.ra </ucd> 
<dataType>real</dataType> 
</param> 
<param use="required"> 
<name>DECSIZE</name> 
<description>the angular distance along the ICRS declination access that in part defines a search region that, when sent to the SIA service, is expected to return at least one record</description> 
<unit>degrees</unit> 
<ucd>pos.angDistance;pos.eq.dec</ucd> 
<dataType>string</dataType> 
</param> 
<param use="required"> 
<name>format</name> 
<description>The desired format for the validation results. Allowed values are "xml" (a custom XML format) and "html"</description> 
<dataType>string</dataType> 
</param> 
<param use="required"> 
<name>show</name> 
<description>an indication of the type of validation results that should be included in the response. Multiple values should be comma-delimited. Allowed values are "fail" (an enumeration of compliance errors), "warn" (an enumeration of warnings), "rec" (an enumeration of recommendations), and "pass" (an enumeration of successfully passed compliance tests). </description> 
<dataType>string</dataType> 
</param> 
<param use="optional"> 
<name>FORMAT</name> 
<description>an SIA image format search constraint that should be sent to the SIA service in order to ensure that useful results are returned </description> 
<dataType>string</dataType> 
</param> 
<param use="optional"> 
<name>EXTRAPARAMS</name> 
<description>any additional parameters and values that need to be sent to the SIA service in order to return meaningful results. The value is composed of comma-delimited name=value pairs which must be url-encoded</description> 
<dataType>string</dataType> 
</param> 
<param use="optional"> 
<name>runid</name> 
<description>an string identifying a the original query that triggered this call to the validater. </description> 
<dataType>string</dataType> 
</param> 
</interface> 
</capability> 
</ri:Resource> 

---------------------->%--- 
This message and any attachments are intended for the use of the addressee or addressees only.
The unauthorised disclosure, use, dissemination or copying (either in whole or in part) of its
content is not permitted.
If you received this message in error, please notify the sender and delete it from your system.
Emails can be altered and their integrity cannot be guaranteed by the sender.

Please consider the environment before printing this email.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/registry/attachments/20140324/41415e75/attachment-0001.html>