Proposal: Require "ref" for TIMESYS access

[Thomas Boch]

Hi all,

I support this change as well. I like explicit definitions, data 
providers have the clearest view about how to describe their data, hence 
interpretation should not be delegated to clients which already have too 
many things to guess.

Thomas

Le 11/02/2019 à 14:57, Mark Taylor a écrit :
> I agree with Tom and some others that the ref attribute on TIMESYS
> should be mandatory and not optional.  I initially didn't think so,
> but I've been persuaded that the ambiguity becomes difficult to
> manage in many cases if the reference is not explicit.
>
> Mark
>
>
> On Mon, 4 Feb 2019, Tom Donaldson wrote:
>
>> 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
>>
>>
>>
>>
> --
> Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
> m.b.taylor at bris.ac.uk +44-117-9288776  http://www.star.bris.ac.uk/~mbt/