<div dir="ltr"><div>Markus,<br><div class="gmail_extra"><br></div>I'll admit that I have always been a bit fuzzy on how ObsCore/ObsTAP ties in with the DAL protocols. <br></div>I've been trying to review some of that today.. with limited success.<br><br><br><div><div><div><div class="gmail_extra"><div>On Thu, Jul 9, 2015 at 7:39 AM, Markus Demleitner <span dir="ltr"><<a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank">msdemlei@ari.uni-heidelberg.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear DM,<br>
<span class=""><br>
On Wed, Jun 24, 2015 at 04:07:25PM -0400, CresitelloDittmar, Mark wrote:<br>
> B3.5: creation date<br>
> Shouldn't we update this to clarify that this is not strictly ISO 8601,<br>
> but rather, the FITS standard which is 8601 without the "Z" tag. There<br>
> was a discussion on this some time ago, and that is the language folded<br>
> into the DatasetMetadata model (Section 6.4.1.1).<br>
<br>
</span>Running the risk of bikeshedding, I'd like to mention that IMHO is<br>
the proper reference for VO data formats is DALI, section 3.1.2.<br></blockquote><div><br></div>The DALI spec applies to DAL services only, so may be applicable for the ObsTAP side.<br></div><div>But it would be TAP implements DALI (assuming it does), and ObsTAP is a specialized TAP..<br><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
*But*, frankly I don't think data models in general should say<br>
anything about the serialisation of literals, as they may be<br>
serialised into fairly different containers, which in turn may have<br>
conventions of their own.<br></blockquote><div><br></div><div>I think agree with you here.. <br></div>This bit of info is about the string representation of that datatype in an ObsTAP<br></div><div class="gmail_quote">query response. Not part of the model proper.<br></div><div class="gmail_quote"> <blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
In the particular case of obscore, these values are going to sit in a<br>
relation database system, which will almost certainly *not* store a<br>
date as a DALI-type string -- in that sense I'm fairly sure none of<br>
the existing obstap servers are compliant. Fortunately, there's no<br>
way a validator could get me, as it has no way to figure out what I'm<br>
doing behind my VOTable facade.<br>
<br></blockquote><div><br></div><div>I'm not sure I follow.<br></div><div>ObsCore:Table 7 is shows that the DB Table should store the (creation_date) element <br>in a manner which can be exposed as an adql:TIMESTAMP type.<br></div><div><br>ObsCore: Appendix B<br></div><div>I think this is not trying to define storage format, but just define the elements,<br></div><div>and (especially in the case of the dates) how to express them in the query response<br></div><div>since there hasn't been another document which defined that.<br></div><div><br></div><div>B3.5: I think uses the word 'stored' where it means 'expressed' <br></div><div>"This is a time stamp, <b>expressed</b> in ISO 8601 format,<br>using this specific format: (YYYY-MM-DDThh:mm::ss)"<br><br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Anyway, after these considerations I'd propose to remove all<br>
references to the storage format of dates, in particular in B.3.5 and<br>
B.4.5.<br></blockquote><div><br> </div><div>This would be fine, so long as an implementor knows how to express<br></div><div>the adql:TIMESTAMP elements. Maybe this is already covered from<br></div><div>the TAP document?.. Section 2.5:<br></div><div><br></div><div>"TIMESTAMP values are specified using ISO8601 format without a timezone
(as in 2.3.4 ) and are assumed to be in UTC. The xtype=”adql:TIMESTAMP”
attribute must be specified in an uploaded VOTable in order for the
values to be inserted in a column of type TIMESTAMP; without the xtype,
the values would be inserted into a CHAR(n) or VARCHAR column."<br><br></div><div>Mark<br><br></div></div></div></div></div></div></div>