Make COOSYS and TIMESYS more consistent

[tomdonaldson]

COOSYS and TIMESYS are very similar, so their inconsistencies can lead to confusion for implementors. These changes should be made to make them more consistent:

• State that COOSYS and TIMESYS elements MUST be defined prior to their first reference. Currently COOSYS is only a SHOULD, and only for that case of a reference via "ref".

• State that references to COOSYS and TIMESYS must be explicit via a ref attribute. Currently references to COOSYS are allowed to be implicit.

These changes likely need to wait for version 2.0 to maintain backward compatibility. This issue could become moot if the nature of the COOSYS and TIMESYS elements changes in other major ways.

[tomdonaldson]

Also ensure that COOSYS and TIMESYS are consistent with respect to which attributes are mandatory. For example, the system attribute in COOSYS is optional, while the timescale attribute in TIMESYS is mandatory. Also, refposition is mandatory in TIMESYS but optional in COOSYS. Should those be made consistent or are they different for a reason other than that they were created at different times?

[msdemlei]

On Thu, Nov 09, 2023 at 12:11:34AM -0800, Tom wrote: `TIMESYS` but optional in `COOSYS`. Should those be made consistent or are they different for a reason other than that they were created at different times?

The only reason is that they were created at different times (and perhaps by different people). Unsurprisingly (given that I'm a co-author), I'd argue that the TIMESYS pattern is what we should follow. But the question is: how do we do that? Making previously optional attributes mandatory will make previously valid VOTables invalid, which is something we're not allowed to do in a minor update according to current rules. Me... I'd say we should follow common practices and allow such moves with sufficient warning. I think python is a good model. They give deprecation warnings for two or three minor versions and then drop things that somehow went bad. Trouble is: I don't think we can push out deprecation warnings from the normative material of VOTables. Or is there some XSD hack to do something equivalent? Would it be a sufficient substitute if we made sure TOPCAT and astropy gave deprecation warnings?

[mbtaylor]

Regarding deprecation warnings from topcat, I could do it but it would likely appear in the logging system at INFO level, which most people would never see. However I could add a WARNING for deprecated features to stilts votlint (hence also taplint) which would be a more appropriate place for this.