<div dir="ltr"><div class="gmail_default" style="font-size:small">In my opinion, the datatypes of all those columns (except content-length) is datatype=&quot;char&quot; arraysize=&quot;[n]*&quot; (where n is optional)*. The fact that this got through RFC without types and without even an example is a little embarrassing/sad, but the fact that this issue came up 5 years later also means that everyone implicitly understood that they were strings.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">I think this is really a bug requiring an erratum, which I would be happy to write up asap.<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">* side issue: I think it would be legit for someone to also specify an xtype like xtype=&quot;uri&quot; (because I think that&#39;s already permitted and matches the whole meaning of xtype) but I don&#39;t know if I would write that into the erratum or not... because I don&#39;t really think it needs to be written it into the specification to be allowed. Would anyone actively want this written in? <br></div><div class="gmail_default" style="font-size:small"><br clear="all"></div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div>--<br></div><div>Patrick Dowler<br></div>Canadian Astronomy Data Centre<br></div>Victoria, BC, Canada<br></div></div></div></div></div><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 2 Apr 2020 at 00:24, Markus Demleitner &lt;<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Tom,<br>
<br>
On Wed, Apr 01, 2020 at 01:53:27PM +0000, Mcglynn, Thomas A. (GSFC-6601) wrote:<br>
&gt; One of the ways to use DataLink is to have a column X in a primary<br>
&gt; (results) RESOURCE of a VOTable which provides a DataLink ID to be<br>
&gt; used in a subsequent Resource Descriptor.  At the HEASARC we&#39;ve<br>
&gt; recently had some discussion about what, if any, restrictions there<br>
&gt; are on the types of these.<br>
&gt; <br>
[...]<br>
&gt; Two questions have arisen in our usage at the HEASARC:<br>
&gt; <br>
&gt; 1. Do both the FIELD and the PARAM need to be character arrays, or<br>
&gt; can they be ints, longs, ...?<br>
<br>
If I had a time machine, I&#39;d go back to datalink 1.0 RFC and put in<br>
type information.  As things are, it seems the only concrete<br>
restriction is that content_length must be a long.<br>
<br>
That&#39;s unfortunate, not the least because if we allow ids different<br>
types, then we also have to admit these types in the ID column of the<br>
links table, and I&#39;d rather not have that polymorphic.<br>
<br>
Given the types are unspecified, what do we do?  I&#39;d hope we could<br>
still fiddle in types without *materially* breaking the spec (in the<br>
sense of: new major version).  Well, we&#39;d be breaking HEASARC<br>
practice, but that breaks with current pyvo at least -- have you<br>
tried with TOPCAT and Aladin?<br>
<br>
If we go for fixing types, an interesting question would be whether<br>
we restrict ID to char[] (my preference) or would also allow<br>
unicodeChar[]...<br>
<br>
&gt; 2. Do the types of the fields need to be the same in the two<br>
&gt; locations?  At the HEASARC we frequently have the FIELD as an<br>
&gt; integer, but it is given in the PARAM as a string (CHAR*)<br>
<br>
Again, we&#39;ve failed to make that explicit, and the use of @ref<br>
Datalink makes (from PARAM to FIELD) isn&#39;t actually forseen as such<br>
in VOTable for all I can make out (at least VOTable 1.4, sect. 3.2<br>
doesn&#39;t say anything that might constrain such a relationship).<br>
<br>
However, here I&#39;m really certain that implicit type conversions from<br>
table row to parameter value are evil, not the least because the are<br>
not canonical (think of floats, and with them points, etc. Of course,<br>
making these IDs is a bad idea in the first place; even for integers<br>
in VOTable Tabledata, however, +1 and 1 are equivalent).<br>
<br>
Hence, I&#39;d say that *if* we allow in-table IDs to be non-strings, we<br>
must allow that for the ID parameter as well.<br>
<br>
And depending on what way we decide, we probably ought to have an erratum on <br>
either Datalink 1.0 (saying ID and PARAM[name=&#39;ID&#39;] have to be<br>
strings) or on VOTable (saying that PARAM/@ref to a FIELD or PARAM is<br>
only allowed if both ends of the relationship agree in type,<br>
arraysize, and xtype).<br>
<br>
        -- Markus<br>
</blockquote></div>