<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="char" arraysize="[n]*" (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="uri" (because I think that's already permitted and matches the whole meaning of xtype) but I don't know if I would write that into the erratum or not... because I don'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 <<a href="mailto:msdemlei@ari.uni-heidelberg.de">msdemlei@ari.uni-heidelberg.de</a>> 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>
> One of the ways to use DataLink is to have a column X in a primary<br>
> (results) RESOURCE of a VOTable which provides a DataLink ID to be<br>
> used in a subsequent Resource Descriptor. At the HEASARC we've<br>
> recently had some discussion about what, if any, restrictions there<br>
> are on the types of these.<br>
> <br>
[...]<br>
> Two questions have arisen in our usage at the HEASARC:<br>
> <br>
> 1. Do both the FIELD and the PARAM need to be character arrays, or<br>
> can they be ints, longs, ...?<br>
<br>
If I had a time machine, I'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'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'd rather not have that polymorphic.<br>
<br>
Given the types are unspecified, what do we do? I'd hope we could<br>
still fiddle in types without *materially* breaking the spec (in the<br>
sense of: new major version). Well, we'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>
> 2. Do the types of the fields need to be the same in the two<br>
> locations? At the HEASARC we frequently have the FIELD as an<br>
> integer, but it is given in the PARAM as a string (CHAR*)<br>
<br>
Again, we've failed to make that explicit, and the use of @ref<br>
Datalink makes (from PARAM to FIELD) isn't actually forseen as such<br>
in VOTable for all I can make out (at least VOTable 1.4, sect. 3.2<br>
doesn't say anything that might constrain such a relationship).<br>
<br>
However, here I'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'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='ID'] 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>