<div dir="ltr"><div class="gmail_default" style="font-size:small">The adql:TIMESTAMP xtype is the legacy of TAP-1.0 and I consider it equivalent to DALI "timestamp" (in the context of TAP, DALI xtypes are used more widely than that). So to me any s/w would be justified in converting from the legacy value to the equivalent DALI value. That would (with DALI-1.2) apply to adql:REGION and DALI "shape" whenever that moves forward. I would consider converting from a DALI xtype back to a legacy xtype to be incorrect behaviour: if the s/w knows they are equivalent then it knows the DALI xtype is preferred (caveat: we may not have made that clear in DALI, in which case we should add some text to the DALI-1.2 WD... I don't think that's a controversial stand).<br></div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">For an unrecognized xtype, it should be preserved exactly.</div><div class="gmail_default" style="font-size:small"><br></div><div class="gmail_default" style="font-size:small">If I recall, our TAP services probably behave in about the same way, but if they do happen to preserve adql:TIMESTAMP it would be an implementation detail and probably not even my intent. I will check. I do know that our tap_upload does not correctly preserve timestamp values (UTC vs local tz issue in the insert). That's a bug.</div><div class="gmail_default" style="font-size:small"><br></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 Fri, 16 Apr 2021 at 02:27, Mark Taylor <<a href="mailto:m.b.taylor@bristol.ac.uk">m.b.taylor@bristol.ac.uk</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">Dear DAL, especially TAP experts,<br>
<br>
I'm looking at some persistent TAP validation issues relating to<br>
roundtripping VOTable column metadata in an upload query like<br>
"SELECT * FROM TAP_UPLOAD.t1". In taplint I prepare a VOTable<br>
with columns giving a variety of (datatype,arraysize,xtype)<br>
triples and see if they come back the same from a trivial upload<br>
query like the above. Applied to DaCHS, that leads to the following<br>
taplint Error report:<br>
<br>
E-UPL-TMCX-1 Upload result column xtype mismatch timestamp != adql:TIMESTAMP<br>
<br>
since the column that's uploaded with xtype="adql:TIMESTAMP" comes<br>
back with xtype="timestamp".<br>
<br>
I'm working from TAP 1.1 section 3.5 here:<br>
<br>
3.5 Mapping Table Datatypes<br>
----------------------------<br>
<br>
The mapping between VOTable and database tables uses the datatype,<br>
arraysize, and xtype values from the VOTable FIELD elements and the<br>
TAP_SCHEMA.columns table. Mapping for primitive types (numbers and<br>
strings) is straightforward; services should ensure that input values<br>
behave as expected in query processing and output values should have<br>
correct and complete metadata. Mapping for specially structured values<br>
use xtype(s) as specified in DALI. The behaviour and usability of such<br>
structured values in queries depends on the query language (section<br>
2.7.1) being used and support for optional features of the language.<br>
<br>
Datatype mapping rules apply to input tables supplied via an UPLOAD<br>
parameter (see section 2.7.6) and to result tables after successful<br>
query execution. TAP services should at least be able to round-trip<br>
all values from an uploaded VOTable to the database and back when<br>
columns in the uploaded table are selected (e.g. SELECT * from<br>
TAP_UPLOAD.mytable).<br>
<br>
My initial reading was that the (datatype,arraysize,xtype) triple<br>
had to be preserved for upload round-trips. But re-reading this<br>
I'm not so sure: it only talks about round-tripping "all values"<br>
rather than the metadata as such, and moreover there isn't a MUST<br>
in the whole section.<br>
<br>
So I'm wondering whether I ought to loosen/downgrade/eliminate<br>
the current taplint behaviour, e.g. to allow an "adql:TIMESTAMP"<br>
xtype to get converted to "timestamp" (and hence, mabye,<br>
any unknown xtype to get converted into any other unknown xtype)<br>
during round-tripping. For this particular case, I may sidestep<br>
the issue by adjusting taplint to upload the more current<br>
xtype="timestamp".<br>
However, this is a more general issue, e.g. Markus said<br>
"I'd like to be able to round-trip polygon into a moc".<br>
<br>
So my question to the TAP authorship and DAL in general is:<br>
should taplint require the (datatype,arraysize,xtype) triple<br>
to be unmodified by upload round-trips (which is its current<br>
behaviour) or not (and if not, what requirements should it make)?<br>
I'm thinking maybe detection of such changes should be<br>
downgraded from Error to Warning.<br>
<br>
Thanks for consideration,<br>
<br>
Mark<br>
<br>
<br>
--<br>
Mark Taylor Astronomical Programmer Physics, Bristol University, UK<br>
<a href="mailto:m.b.taylor@bristol.ac.uk" target="_blank">m.b.taylor@bristol.ac.uk</a> <a href="http://www.star.bristol.ac.uk/~mbt/" rel="noreferrer" target="_blank">http://www.star.bristol.ac.uk/~mbt/</a><br>
</blockquote></div>