DataLinks and ID data types.

Mcglynn, Thomas A. (GSFC-6601) thomas.a.mcglynn at nasa.gov
Wed Apr 1 15:53:27 CEST 2020


One of the ways to use DataLink is to have a column X in a primary (results) RESOURCE of a VOTable which provides a DataLink ID to be used in a subsequent Resource Descriptor.  At the HEASARC we've recently had some discussion about what, if any, restrictions there are on the types of these.

The column in the primary table is described within a FIELD as something like:
 
...
<FIELD ... />
<FIELD name="X" type="char" dimension="*" ID="DataLinkID" >
<FIELD ... />
...
<TR><TD>...</TD><TD>thisrowsidstring</TD><TD>....</TR>
...
The ID field in the DataLink Resource descriptor is defined in something like

<PARAM name="accessURL" value="https://myhost/datalinkaddress" ... />
<PARAM name="ID" type="char" dimension="*" ref="DataLinkID" value="" />

When we look to associate a row with its datalink value, we grab the appropriate column and construct a URL 
   https://myhose/datalinkaddress?ID=thisrowsidstring

Two questions have arisen in our usage at the HEASARC:

1. Do both the FIELD and the PARAM need to be character arrays, or can they be ints, longs, ...?

2. Do the types of the fields need to be the same in the two locations?  At the HEASARC we
frequently have the FIELD as an integer, but it is given in the PARAM as a string (CHAR*)

I.e., we'd have something like

<FIELD name="X" datatype="int" ID="DataLinkID" >

but we'd describe it as a string in the PARAM.  That's because while the ID happens to be an integer in this case, it's a string in many others.  From the perspective of the datalink service the ID is a string.  It just sometimes happens to be a string that is parseable as number in this case.

As far as I can tell there's nothing in the standard that suggests this is invalid:  the standard doesn't seem to make any statements about the datatypes of the ID fields, but neither is any conversion specified.  In practice there is no problem converting from shorts/ints/longs to strings, but some other datatypes might be more problematic.  Since our code is written in Java and JavaScript which does such transformations silently we've never really worried about this, but now that we're doing some work in Python it's become an issue. 


What do people think?  Are there constraints on the datatypes and if so where are they specified?  Should there be?

	Tom McGlynn



More information about the dal mailing list