<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div>I'd like to hear other opinions on this.. otherwise the discussion will remain rather circular.<br></div><div><br>more in-line<br></div><br><div class="gmail_quote"><div dir="ltr">On Tue, Jan 8, 2019 at 7:44 AM 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">Dear DM,<br>
<br>
On Fri, Dec 21, 2018 at 04:41:09PM -0500, CresitelloDittmar, Mark wrote:<br>
> > Similarly (and this is quite a bit more itchy to me right now), I'm<br>
> > strongly advocating to make TimeInstant concrete and remove all its<br>
> > derived types (ISOTime, JD, MJD, TimeOffset). Instead, TimeFrame<br>
> > should grow a timeorigin attribute.<br>
> ><br>
> <br>
> Full disclosure, I haven't read the apps thread re: TIMESYS, but as I<br>
> recall, it works only because it requires that timeorigin is expressed in<br>
> JD specifically.<br>
<br>
Which is fine because it's metadata. In annotation, flexibility is<br>
what we need on the *data* side -- in general you don't want to force<br>
data providers into rigid conventions because that would typically<br>
force them to change their data in non-trivial ways. That's why we<br>
allow all kinds of time scales, reference positions, and (indirectly)<br>
serialisation formats.<br>
<br>
For *metadata*, that's a different thing -- this is part of the<br>
annotation itself and is largely controlled by "us"; it is being<br>
written at publication time by people looking at the VO. Flexibility<br>
there only complicates both model and implementations without buying<br>
anything (except possibly a tiny bit of conversion work for very few<br>
numbers external to the data itself). <br>
<br>
Hence, fixing time origin to a float (which certainly can be<br>
represented in all conceivable serialisations) with a bespoke<br>
interpretation (as a JD) doesn't hurt the generality of the model at<br>
all but saves quite a bit of code (and hence bugs) in the clients.<br></blockquote><div><br></div><div>I really don't think we want to fix the offset to a JD for all of VO.<br></div><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> This is not OK for general usage, and without the restriction you get a<br>
> cyclical problem in the model.<br>
<br>
The cyclicity (that you actually don't get rid of as is, you just<br>
hide it a bit better) is another indication of the unnecessary<br>
complexity inflation I'm hinting at above. <br></blockquote><div><br></div><div>Where is the cycle? I think I've hidden it from myself!<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">
As soon as you attach time metadata to the time offset (which is<br>
itself metadata), you have meta-metadata. There are situations when<br>
you *have* to have extra levels, but these kinds of cycles<br>
("reification") always are potentical code bomb (i.e., apparently<br>
inoccuous features that explode into many code lines in<br>
implementations). Let's not do it unless we must, and as I argue<br>
above, I'm sure we can do without meta-metadata here just fine.<br>
<br>
<br>
> > The rationale here is that the concrete form of the timestamp is a<br>
> > *serialisation* issue, i.e., one of VOTable, FITS, or whatever else.<br>
> > If the serialisation provides for having ISO-like dates or a binary<br>
> > representation of civil dates or nothing of the sort shouldn't<br>
> > determine whether you can serialise STC instances into them.<br>
> ><br>
> <br>
> Not sure I would call it a serialization issue, but yes.. its related. The<br>
> thing is, when we have time data, we need to convey how to interpret that<br>
> value (which on its face is just a 'real' ).<br>
<br>
Well, the trouble is that at least VOTable already has a distinction<br>
between ISO string and floating point representations, and I'd expect<br>
any format powerful enough to carray VODML annotation will have<br>
similar mechanisms (e.g., relational database tables). So, if you<br>
put that distinction into the model, too, you have an immediate<br>
conflict of responsibilities. <br></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Which is bad for many reasons, the most urgent of which is that<br>
client writers have to decide what should happen if a <FIELD<br>
xtype="timestamp"/> is annotated as MJDDate (say).<br></blockquote><div><br></div><div>I get concerned about discussion based on 'xtype'.. as I understand it, this is more or less an alternate annotation to identify that the field/param is a time rather than basic string/real.<br></div><div>If I'm reading DALI (pg 17) correctly, this applies to all 'flavors'.. ISO, MJD, JD. Presumably, a client then interprets the value:<br></div><div> if (string) => ISO<br></div><div> else if (real)<br> if (> <span class="gmail-ILfuVd">2,400,000.5) => JD<br></span></div><div><span class="gmail-ILfuVd"> else => MJD<br></span></div><div><br>(I don't see a means for the client to distinguish between JD and MJD other than the range)<br></div><div>So the xtype="timestamp" maps more directly to the model "TimeInstant" type.. which is fine.<br></div><div>Now, if the table also has VODML annotation, the field would be identified as the particular sub-class (coords:domain.time.MJD), which removes the need for interpreting the value.<br><br></div><div>Your argument seems to be that since VOTable already has an annotation scheme for these time types (ISO,MJD,JD), that we shouldn't model them more specifically because a provider may include<br></div><div>both annotations, and there is a possibility that they are inconsistent. ( ie: votable xtype="timestamp" value="2000-01-02T15:20:30Z" with vo-dml dmtype="coords:domain.time.MJD" )<br></div><div><br></div><div>I agree this is a possibility.<br></div><div>I disagree that this is a model problem. The model supports the xtype usage, but has an additional level of detail showing exactly what implementations of TimeInstant should support.<br><br></div><div>This argument holds true for both the TIMESYS and COOSYS elements as well.<br></div><div>If a provider includes those, and vo-dml annotation for the time frame and space frame, they had better be consistent.<br></div><div><br></div><div>Mark<br><br></div><div><br><br></div></div></div></div></div></div>