Controlled/dictated by some sort of schema (either XML or otherwise). Peter was already doing this so we can't let ourselves regress in this; see also NIHTS, DeVeny, and LMI.
Include a data checksum for quick/easy verification, in addition to the other verifications one should do.
See also: astropy.io.fits verification options.
Discourage/depreciate the duplication of keywords. The switch from LOIS -> LOCUS will undoubtedly ruffle feathers, and I'm ok with telling people that it's time for them to update their side to let us rebuild. Writing DATE, DATE-OBS, UT, UTSTART, all with various bits of the same information is kinda silly and can lead to confusion, especially if a new design bug causes them to differ slightly.
The schema (or whatever) needs a way of specifying/changing where the values originate, too, and all the error handling therein. It gets complicated quickly, but by keeping everything on the broker we have a shot of some uniformity of design.
In an ideal world, the FITS header should be:
Controlled/dictated by some sort of schema (either XML or otherwise). Peter was already doing this so we can't let ourselves regress in this; see also NIHTS, DeVeny, and LMI.
Include a data checksum for quick/easy verification, in addition to the other verifications one should do. See also: astropy.io.fits verification options.
Discourage/depreciate the duplication of keywords. The switch from LOIS -> LOCUS will undoubtedly ruffle feathers, and I'm ok with telling people that it's time for them to update their side to let us rebuild. Writing DATE, DATE-OBS, UT, UTSTART, all with various bits of the same information is kinda silly and can lead to confusion, especially if a new design bug causes them to differ slightly.
The schema (or whatever) needs a way of specifying/changing where the values originate, too, and all the error handling therein. It gets complicated quickly, but by keeping everything on the broker we have a shot of some uniformity of design.