A Space & astronomy forum. SpaceBanter.com

Go Back   Home » SpaceBanter.com forum » Astronomy and Astrophysics » FITS
Site Map Home Authors List Search Today's Posts Mark Forums Read Web Partners

[fitsbits] Proposed Changes to the FITS Standard



 
 
Thread Tools Display Modes
  #1  
Old August 22nd 07, 03:41 AM posted to sci.astro.fits
Mark Calabretta
external usenet poster
 
Posts: 42
Default [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

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump

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


All times are GMT +1. The time now is 12:24 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 SpaceBanter.com.
The comments are property of their posters.