|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
Please post any comments, suggestions, or concerns regarding these
proposals (or any other suggestions for improving the Standard document) Good job. Time well spent. Thanks to all involved. Comments indexed to the summary: 1.4) Extensions ARE special records from the point of view of classic FITS readers. Rather than deprecating or attempting to ban them, perhaps just explicitly state that new uses for special records require IAUFWG approval. (But see 1.10 below.) 1.5) Unenforceable in the absence of some explicit mechanism tagged to the DATE keyword (for instance). On the other hand, such a mechanism would be equivalent to explicitly versioning each file. This would be a change to the basic philosophy of FITS. I think of opening old Word files with new editions of MS Office - or worse - trying to do the reverse. 1.6) Harmless, but also unenforceable. Not just an attempted constraint on software, but also on humans editing headers manually using IRAF hedit, for instance. 1.7) No, but there are many headers that unintentionally repeat keywords. They should not therefore be rendered unconforming FITS. 1.9) Few users will choose 64 bits when 16 will do. Those that do may well have a good reason. 1.10) This is a requirement placed by the IAU, not FITS per se. Might such policies better be concentrated in a common section? On the other hand, it is eminently practical to manipulate unknown but conforming extensions. In particular, software we write today can skip and list and otherwise manhandle conforming extensions from tomorrow. 3.1) Italicizing these words may be distracting. Must it be done? I should not recommend it. Shall it be optional? In general, as with the previous comment about the EXTEND keyword, we should be careful what we attempt to require regarding new data since it may place unfunded mandates on old software. Deprecation of a feature is not equivalent to requiring its converse. A couple of other general comments: Any chance of blessing checksums on this go-around? Then we could fret about using "one's-complement" versus "one's complement", too. There is a very real possibility that UTC will be turned into something other than a flavor of Universal Time, i.e., other than an approximation to Greenwich Mean Time. Perhaps we should consider how best to deal with such a situation. A generic "UT"? Use raw UT1? Define a UTA (Astronomical) retaining IAU mediated leap seconds? This is a broader issue than FITS, but we would have to start somewhere. Rob |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Proposed Changes to the FITS Standard | William Pence | FITS | 2 | July 24th 07 04:57 AM |
FITS long integer support (was [fitsbits] ADASS FITS BoF onSunday) | Eric Greisen | FITS | 10 | October 26th 04 08:14 AM |
FITS long integer support (was [fitsbits] ADASS FITS BoFon Sunday) | William Pence | FITS | 6 | October 22nd 04 08:23 PM |
[fitsbits] proposed FITS MIME types Internet Draft | Steve Allen | FITS | 0 | October 1st 03 05:49 AM |