Coordinates model - Working draft.

[Arnold Rots]

Don't allow Z at the end of the ISO 8601 string.
It implies a time scale that may conflict with the time coordinate frame
specification.
It's nonsensical anyway since no one should use time zones.

On Thu, Jan 10, 2019, 04:11 Markus Demleitner <
msdemlei at ari.uni-heidelberg.de wrote:

> Hi DM,
>
> On Wed, Jan 09, 2019 at 11:15:11AM -0500, CresitelloDittmar, Mark wrote:
> > I'd like to hear other opinions on this.. otherwise the discussion will
> > remain rather circular.
>
> Yes, folks, please speak up!  STC annotation is important for so many
> use cases (including in all likelihood yours), and we really can't
> afford a re-run of the, to put it friendly, lackluster takeup of
> STC1.  Please have a look at things *now* and think about how your
> data would be annotated with this model.  And then perhaps consider
> if there's a simpler way to effect the same thing[1].
>
>
> > On Tue, Jan 8, 2019 at 7:44 AM Markus Demleitner <
> > msdemlei at ari.uni-heidelberg.de> wrote:
> > > Hence, fixing time origin to a float (which certainly can be
> > > represented in all conceivable serialisations) with a bespoke
> > > interpretation (as a JD) doesn't hurt the generality of the model at
> > > all but saves quite a bit of code (and hence bugs) in the clients.
> > >
> >
> > I really don't think we want to fix the offset to a JD for all of VO.
>
> But what kind of scenario do you envision where annotators can't just
> write a JD with zero or negligible effort?
>
> > > The cyclicity (that you actually don't get rid of as is, you just
> > > hide it a bit better) is another indication of the unnecessary
> > > complexity inflation I'm hinting at above.
> >
> > Where is the cycle? I think I've hidden it from myself!
>
> Ok -- I stand corrected.  The split of TimeInstant and TimeStamp does
> indeed prevent a cycle in the graph.  But that in itself is a
> significant complication of the model, which seems a high price to
> pay for being able to write a piece of metadata in several different
> forms.
>
> > 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.
>
> No.  Generally, an xtype says "Dear VOTable parser -- in case you
> have special code, you can interpret this field in a special way; if
> you don't, just treat it as the normal datatype/arraysize you're
> seeing and nothing bad happens even if you round-trip and keep the
> xtype".
>
> In the concrete case, what DALI says is: "If you know the xtype
> timestamp, then parse the string using a pattern like
> YYYY-MM-DD['T'hh:mm:ss[.SSS]['Z']] and return a native timestamp
> object to your caller."
>
> > If I'm reading DALI (pg 17) correctly, this applies to all 'flavors'..
> ISO,
> > MJD, JD.  Presumably, a client then interprets the value:
> >   if (string) => ISO
> >   else if (real)
> >      if (> 2,400,000.5) => JD
> >      else => MJD
>
> No, this is *not* the intention, and if the DALI text leads people to
> believe it is, it needs to be fixed.
>
> > So the xtype="timestamp" maps more directly to the model "TimeInstant"
> > type.. which is fine.
>
> No.  It would be conflated with your ISOTime, just with a somewhat
> more precise syntax definition.
>
> > 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
> > 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" )
> >
> > I agree this is a possibility.
> > 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.
>
> Why would such a model even want to say what serialisations should be
> available?  And if you think you should say something about
> serialisations, then what about times given as years?  Or the
> perennial favourite J2015.5?  Am I not going to be allowed to
> annotate these with STC2 even if my serialisation supports it (which
> VOTable so far by and large doesn't, but others may)?
>
> Everything will be simpler if you just leave serialisation alone.
> VOTable has a well-established way to define how literals are
> serialised and what their unit is, and presumably essentially all
> other relevant formats have very similar capabilities.  It would be
> highly unwise (not to mention restricting) to repeat these
> definitions in the data model; it yields no additional information
> but multiplies the ways in which inconsistencies can be introduced.
>
> So, again, let's only add annotation that VOTable and comparable
> formats don't have (well, yes, there's COOSYS, and there'll hopefully
> be TIMESYS soon, but they'll hopefully die when there's widespread
> adoption of STC2+VOTable).
>
> Specifically, that extra metadata in the time domain is what you now
> have in TimeFrame plus the time offset (e.g., JD, MJD, or one of a
> myriad others).  If you just absorb that time offset into your
> TimeFrame, there's no need for extra time modelling at all.  Which
> will increase the chances for the adoption of the model.  Which is a
> good thing.
>
>           -- Markus
>
>
> [1] Because simplicity helps adoption by Demleitner's conjecture:
> Each box in your UML diagram reduces the likelihood of the adoption
> of the model by 1%.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.ivoa.net/pipermail/dm/attachments/20190110/6651766c/attachment.html>