<div dir="auto">Don't allow Z at the end of the ISO 8601 string. <div dir="auto">It implies a time scale that may conflict with the time coordinate frame specification.</div><div dir="auto">It's nonsensical anyway since no one should use time zones. </div></div><br><div class="gmail_quote"><div dir="ltr">On Thu, Jan 10, 2019, 04:11 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:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi DM,<br>
<br>
On Wed, Jan 09, 2019 at 11:15:11AM -0500, CresitelloDittmar, Mark wrote:<br>
> I'd like to hear other opinions on this.. otherwise the discussion will<br>
> remain rather circular.<br>
<br>
Yes, folks, please speak up! STC annotation is important for so many<br>
use cases (including in all likelihood yours), and we really can't<br>
afford a re-run of the, to put it friendly, lackluster takeup of<br>
STC1. Please have a look at things *now* and think about how your<br>
data would be annotated with this model. And then perhaps consider<br>
if there's a simpler way to effect the same thing[1]. <br>
<br>
<br>
> On Tue, Jan 8, 2019 at 7:44 AM Markus Demleitner <<br>
> <a href="mailto:msdemlei@ari.uni-heidelberg.de" target="_blank" rel="noreferrer">msdemlei@ari.uni-heidelberg.de</a>> wrote:<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>
> ><br>
> <br>
> I really don't think we want to fix the offset to a JD for all of VO.<br>
<br>
But what kind of scenario do you envision where annotators can't just<br>
write a JD with zero or negligible effort?<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>
> <br>
> Where is the cycle? I think I've hidden it from myself!<br>
<br>
Ok -- I stand corrected. The split of TimeInstant and TimeStamp does<br>
indeed prevent a cycle in the graph. But that in itself is a<br>
significant complication of the model, which seems a high price to<br>
pay for being able to write a piece of metadata in several different<br>
forms.<br>
<br>
> I get concerned about discussion based on 'xtype'.. as I understand it,<br>
> this is more or less an alternate annotation to identify that the<br>
> field/param is a time rather than basic string/real.<br>
<br>
No. Generally, an xtype says "Dear VOTable parser -- in case you<br>
have special code, you can interpret this field in a special way; if<br>
you don't, just treat it as the normal datatype/arraysize you're<br>
seeing and nothing bad happens even if you round-trip and keep the<br>
xtype".<br>
<br>
In the concrete case, what DALI says is: "If you know the xtype<br>
timestamp, then parse the string using a pattern like<br>
YYYY-MM-DD['T'hh:mm:ss[.SSS]['Z']] and return a native timestamp<br>
object to your caller."<br>
<br>
> If I'm reading DALI (pg 17) correctly, this applies to all 'flavors'.. ISO,<br>
> MJD, JD. Presumably, a client then interprets the value:<br>
> if (string) => ISO<br>
> else if (real)<br>
> if (> 2,400,000.5) => JD<br>
> else => MJD<br>
<br>
No, this is *not* the intention, and if the DALI text leads people to<br>
believe it is, it needs to be fixed.<br>
<br>
> So the xtype="timestamp" maps more directly to the model "TimeInstant"<br>
> type.. which is fine.<br>
<br>
No. It would be conflated with your ISOTime, just with a somewhat<br>
more precise syntax definition.<br>
<br>
> Your argument seems to be that since VOTable already has an annotation<br>
> scheme for these time types (ISO,MJD,JD), that we shouldn't model them more<br>
> specifically because a provider may include<br>
> both annotations, and there is a possibility that they are inconsistent. (<br>
> ie: votable xtype="timestamp" value="2000-01-02T15:20:30Z" with vo-dml<br>
> dmtype="coords:domain.time.MJD" )<br>
><br>
> I agree this is a possibility.<br>
> I disagree that this is a model problem. The model supports the xtype<br>
> usage, but has an additional level of detail showing exactly what<br>
> implementations of TimeInstant should support.<br>
<br>
Why would such a model even want to say what serialisations should be<br>
available? And if you think you should say something about<br>
serialisations, then what about times given as years? Or the<br>
perennial favourite J2015.5? Am I not going to be allowed to<br>
annotate these with STC2 even if my serialisation supports it (which<br>
VOTable so far by and large doesn't, but others may)?<br>
<br>
Everything will be simpler if you just leave serialisation alone.<br>
VOTable has a well-established way to define how literals are<br>
serialised and what their unit is, and presumably essentially all<br>
other relevant formats have very similar capabilities. It would be<br>
highly unwise (not to mention restricting) to repeat these<br>
definitions in the data model; it yields no additional information<br>
but multiplies the ways in which inconsistencies can be introduced.<br>
<br>
So, again, let's only add annotation that VOTable and comparable<br>
formats don't have (well, yes, there's COOSYS, and there'll hopefully<br>
be TIMESYS soon, but they'll hopefully die when there's widespread<br>
adoption of STC2+VOTable). <br>
<br>
Specifically, that extra metadata in the time domain is what you now<br>
have in TimeFrame plus the time offset (e.g., JD, MJD, or one of a<br>
myriad others). If you just absorb that time offset into your<br>
TimeFrame, there's no need for extra time modelling at all. Which<br>
will increase the chances for the adoption of the model. Which is a<br>
good thing.<br>
<br>
-- Markus<br>
<br>
<br>
[1] Because simplicity helps adoption by Demleitner's conjecture:<br>
Each box in your UML diagram reduces the likelihood of the adoption<br>
of the model by 1%.<br>
</blockquote></div>