|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
[fitsbits] Proposed Changes to the FITS Standard
On Tue 2007/08/21 17:56:49 -0400, William Pence wrote in a message to: FITSBITS The difference here is that I was quoting the revised definition in the new draft standard, which doesn't allow for the possibility that EXTEND = F. Given that there are existing FITS files with EXTEND = F, the definition should probably be revised to at least not prohibit this usage. The text describing EXTEND was moved from one section to another (old text in red on p34, new in blue on p36) so it is not immediately clear in differences.pdf that this change was made in FITS 3.0 nor does summary.pdf mention it explicitly. (BTW, EXTEND does not appear in the index.) In answer to Steve's question, FITS is permissive in the sense that anything that is not disallowed is allowed so Anything ever explicitly allowed can never be disallowed and Anything not explicitly disallowed must always remain allowed say the same thing, i.e. what was once allowed can never be disallowed. There are two sides to the FITS 3.0 spec: 1) How it is used by writers. In this respect it may make sense to deprecate some usage (e.g. the ill-defined CROTAn, or EXTEND=F, or EXTEND itself) typically because it's replaced by a better alternative (e.g. PCi_ja) or is now considered redundant (e.g. EXTEND). However deprecated usage must remain legal because a) FITS 2.0 & 1.0 writers might not have been updated to FITS 3.0 (and may never be) so will carry on using it, b) FITS 3.0 writers may want to help FITS 2.0 & 1.0 readers, which is why existing usage should not be deprecated without good reason. 2) How it is used by readers. In this respect what was once allowed can never be be disallowed. If the EXTEND keyword was to be deprecated (it can't be disallowed) then a FITS 3.0 reader should not expect to find it, but it if did it should know what to do with it. In order to be complete and self-contained the FITS 3.0 spec must make it clear what was allowed in FITS 2.0 and 1.0 (e.g. EXTEND=F) because a generic reader that conforms to the FITS 3.0 spec may have to parse a FITS 2.0 or 1.0 file. Likewise, the FITS 2.0 spec should have stated explicitly that it had deprecated keyrecord comments without a "/" delimiter. In concrete terms, if FITS 3.0 attempted to invalidate EXTEND=F without warning that it was valid in FITS 2.0 then a new parser written in conformance with FITS 3.0 would incorrectly conclude that files written with EXTEND=F in conformance with FITS 2.0 were invalid. The effect on their operation would be implementation-dependent. Mark Calabretta |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
[fitsbits] Proposed Changes to the FITS Standard | Rob Seaman | FITS | 3 | August 21st 07 06:43 PM |
[fitsbits] Proposed Changes to the FITS Standard | Thierry Forveille | FITS | 0 | August 20th 07 03:26 PM |
[fitsbits] Proposed Changes to the FITS Standard | Mark Calabretta | FITS | 0 | August 20th 07 03:17 AM |
[fitsbits] Proposed Changes to the FITS Standard | Mark Calabretta | FITS | 0 | August 2nd 07 09:39 AM |
[fitsbits] Proposed Changes to the FITS Standard | Mark Calabretta | FITS | 0 | August 2nd 07 01:28 AM |