Proposal: Require "ref" for TIMESYS access

[François Bonnarel]

Dear all,

It's nice to see TIMESYS in VOTABle now. Thanks.

However I don't understand the beginning of this sentence syntaxically

"The TIMESYS element defines such a time system and gives itself the 
identifies itself with ID="time frame". Then
the obs time FIELD indicates that its values should be interpreted in 
that time system by referring back to the
TIMESYS element using ref="time frame".

And about the meaning : we cannot force the ID to be "time_frame". What 
happens if we have several TIMESYS.

On Tom's suggestion. I think it's too much asking. In many use cases 
there will be no ambiguity. and the single TIMESYS is valid for any 
times in the table. So we absoluty requires a ref when there is ambiguity.
I suggest
"The TIMESYS element (introduced in VOTable 1.4) defines metadata for 
temporal coordinates. To reference the time system defined by a TIMESYS 
element, FIELDs (and possibly PARAMs) MUST reference the TIMESYS giving 
their frame using the VOTable ref attribute when there is an ambiguity; 
Otherwise the TIMESYS is considered pertinent for all time-like 
quantities.. A TIMESYS element referenced via a ref attribute MUST 
appear before the element that references it."
Cheers
François
Le 04/02/2019 à 20:38, Tom Donaldson a écrit :
> Dear VOTable1.4 reviewers,
>
> The current VOTable 1.4 draft (http://www.ivoa.net/documents/VOTable/20190131/ ) makes the use of "ref" optional when a FIELD wishes to use a time system defined by a TIMESYS element.  However, I think that not requiring "ref" is confusing if there are multiple time-like FIELDs, but only one TIMESYS.
>
> If someone currently serves a VOTable with multiple time-like FIELDs, where most of them are just calendar dates (as with obs_release_date), but one FIELD needs a TIMESYS, then the likely path is to add the TIMESYS for the one FIELD.  According to the current draft, that would leave the calendar time FIELDs to be interpreted under the one TIMESYS element, which is likely not what was intended, and actually would be illegal if the TIMESYS has a timeorigin.
>
> Many VOTables will continue to have no TIMESYS elements.  For them, any time-like FIELDs will use some implicit Time System.  I think it's important for us to clarify that fact, and indeed use the same default (implied) TIMESYS for all time-like FIELDs that don't explicitly refer to a TIMESYS.
>
> VOTable readers who want to use TIMESYS must understand the "ref", and VOTable providers surely know which FIELDs are time-like quantities that should be under a particular time system, so I don't see a strong downside to requiring the "ref".  In general, I think limiting the number of optional cases is good because it limits the clients' need to do context-sensitive reasoning, and thus the chances for making mistakes.  In this case, making a client loop through all FIELDs to identify time-like quantities seems a bit too much to ask.
>
>
> So I propose the following wording change to the first paragraph section 3.5 of the VOTable 1.4 draft:
>
> Existing text:
>
> The TIMESYS element (introduced in VOTable 1.4) defines metadata for temporal coordinates. As with COOSYS, FIELDs (and possibly PARAMs) SHOULD reference the TIMESYS giving their frame using the VOTable ref attribute; absent such a ref, readers SHOULD assume the lexically first TIMESYS element in the VOTable to be pertinent for time-like quantities. A TIMESYS element referenced via a ref attribute MUST appear before the element that references it.
>
>
> Proposed text:
>
> The TIMESYS element (introduced in VOTable 1.4) defines metadata for temporal coordinates. To reference the time system defined by a TIMESYS element, FIELDs (and possibly PARAMs) MUST reference the TIMESYS using the VOTable ref attribute.
> If a FIELD or PARAM represents a time-like quantity but does not reference a TIMESYS element, then no assertion is made about its time system. A TIMESYS element referenced via a ref attribute MUST appear before the element that references it.
>
>
> Regards,
> Tom
>
>
>