Coordinates model - Working draft.

[Markus Demleitner]

Hi DM,

On Fri, Nov 30, 2018 at 06:11:07PM -0500, CresitelloDittmar, Mark wrote:
> All,
> 
> I have attached an initial drop for the Coordinates data model.
> I'm taking the approach that these component models are Version 1.0 models
> extracted from and updating portions of the STC-1.33, rather than branding
> them as STC-2.0 models (the introduction explains their heritage).  I
> haven't taken a formal poll, but informal talks with several of us at the
> interops was positive, since these are not strictly limited to "Space-Time
> Coordinates"
>   + Astronomical Coordinates and Coordinate Systems - V1.0 (coords)
>   + Measurements and Errors - V1.0 (meas)
>   + WCS Transforms - V1.0 (trans)

I think that is an excellent plan.  And I like the WD a lot better
than previous versions.


[Begin side issue]
I still believe there's room for substantial simplifications without
impacting functionality and actually improving robustness; for
instance, I'd say EclipticCoord, EquatorialCoord, GalacticCoord, and
LongLatCoord should all just be LongLatCoord; the associated frame is
enough to tell them apart, and I can't see where having separate
types for them would help a client (or even a server).


[Begin main issue]
Similarly (and this is quite a bit more itchy to me right now), I'm
strongly advocating to make TimeInstant concrete and remove all its
derived types (ISOTime, JD, MJD, TimeOffset).  Instead, TimeFrame
should grow a timeorigin attribute.

The rationale here is that the concrete form of the timestamp is a
*serialisation* issue, i.e., one of VOTable, FITS, or whatever else.
If the serialisation provides for having ISO-like dates or a binary
representation of civil dates or nothing of the sort shouldn't
determine whether you can serialise STC instances into them.

Conversely, letting DM annotations determine serialisation will lead
to the same information being stored in two different places; in
VOTable you'd have something like [fantasy annotation syntax]:

  <COLUMN dmtype="domain.time.ISOType" nameref="epoch"/>

  <FIELD name="epoch" ... xtype="timestamp"/>

-- in situations like these, clients have to validate that @dmtype
and @xtype are compatible, think about what to tell the user when
they aren't, whether to trudge on (bad) or just fail (annoying to the
user when it's obvious to them what should happen).

Let's save our implementors this pain.  Let's have TimeInstant, and
TimeFrame would then just be equivalent to TIMESYS (except that in
the future annotation the direction of referencing is right).  See
also the recent thread starting at
http://mail.ivoa.net/pipermail/apps/2018-November/001306.html, where
we've been over this for TIMESYS.


Well, I give you it's not all rosy, because *some* serialisations
have implied timeorigins, and if you let people override them, it
would be extremely nasty; this is true for ISO serialised datetime
strings or fractional Julian or Besselian years ("J2000.0") (the
origins of which are all somewhere near JD 1721425.5, but it quickly
gets messy beyond "somwhere near") Other such examples might include
dates in the Islamic, Hindu, or Buddhist calendars (which we don't
have in VOTable yet, but I'd be reluctant to totally rule them out).

Lest someone defines a Gregorian calender that just is a day or two
off with @timeorigin (which would certainly be a huge
interoperability destaster, as most clients would get that wrong), I
think we need to outlaw the use of timeorigin for these.
Technically, I think there's not much we can do in the DM except
saying so; defining a separate type ("TimeInstantWithImpliedOrigin")
might seem tempting but probably doesn't help in practice.

So, our abstraction would still be just a tad leaky, but I'd argue
that's still better than having serialisation determine the class
structure in the first place.

         -- Markus