Timesys note review

[Markus Demleitner]

Hi Apps,

On Tue, Nov 27, 2018 at 02:14:16PM +0000, Mark Taylor wrote:
> logic in the definition and parsing, but how about just defining
> "MJD" and "JD" (any others?) as aliases for "2400000.5" and "0"
> respectively.  Of course this means you have to redefine the type

Well, I'm not enthusiastic about it -- I'd still say it introduces an
extra bug surface, but then...

> of the timeorigin attribute from "xs:double" to "xs:token" or
> similar, which weakens the checking that XSD validation can do
> here, but my guess is that it's likely to be more than outweighed
> by avoiding validation-proof typos like timeorigin="240000.5",
> not to mention the convenience and readability.

...that's an argument placating at least me, as yes, this type of
typo worries me, too.  

It wouldn't be too hard to define an extra XSD type that would keep
an eye on timeorigin's content despite the introduction of the two
aliases, so the damage is limited, and there's clearly some benefit.

So...

> If clients come across something which is neither a double nor
> one of the known aliases in the timeorigin attribute, they just
> have to treat it as an error.
> 
> So then the examples in the document would become
> 
>    <TIMESYS ID="gaia_frame" refposition="BARYCENTER" timeorigin="JD"
>             timescale="TCB"/>

[this shouldn't be called gaia_frame, when we're using Gaia data
below to illustrate custom timeorigins]

> and
> 
>    <TIMESYS refposition="TOPOCENTER" timescale="TT" timeorigin="MJD"
>             ID="_MJD"/>
> 
> while e.g. the Gaia epoch photometry available from
> http://geadata.esac.esa.int/data-server/data?RETRIEVAL_TYPE=epoch_photometry
> could write:
> 
>    <TIMESYS refposition="BARYCENTER" timescale="TCB" timeorigin="2455197.5"
>             ID="whatever"/>

...in sum I'm neutral-negative on this proposal (meaning: If I don't
hear from anyone else, I won't put it in).

If there's enthusiastic support for the idea (bonus points for a
working XSD definition for the type of timeorigin), I'll put it in
[just a +1 to me privately would already count, no need to come out
publicly if you don't want to].  If this is disgusting to you, it
would be great if you could say on on-list.

> Somewhat related: I think the discussion of the timeorigin attribute
> in section 2 should be tightened up a little bit, so it's clear that
> a value MUST be present for non-year-like time values as well as
> saying that it MUST NOT be present for calendar-year-like values.

Hm, I see.  The trouble is that I don't think we can write

>    [...]
>    which MUST be present when the time value being annotated represents
>    an interval elapsed from an origin, such as MJD.

You see, any time specification represents an "interval elapsed from
an origin", be it the Christian epoch, the mythical foundation of
Rome, the Hijra, the launch of a space probe or (since I belong to
the Church of Unix, my favourite) 1970-01-01T00.00:00Z.  So, I don't
think this language works.  But I see the requirement level needs to
be made clearer.

What about (svn rev. 5245):
  
  The timeorigin attribute MUST be given unless the time's representation
  contains a year of a calendar era, in which case it MUST NOT be present.

(to see it in context: http://docs.g-vo.org/timesysnote.pdf, p. 4
bottom; this doesn't have any language on the aliases yet)?

         -- Markus