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 October 17th 07, 05:02 AM posted to sci.astro.fits
Don Wells
external usenet poster
 
Posts: 8
Default [fitsbits] Proposed Changes to the FITS Standard

Dear Friends-of-FITS,

William Pence wrote:
..1. A short (9 page) summary of the main recommendations..


I have examined the 'Recommended Changes' document dated 07-18, and find
that the recommendations are acceptable. My compliments to the chefs!

-=-=- On escape hatches -=-=-

As I read the document, one big issue caused me to pause and think.
That is the concept of 'escape hatches' in FITS. This feature has been
essential for the success of FITS over the past 28 years. We have a
long history of leaving certain 'holes' in the specifications, precisely
to permit clever people to create new designs. This recommendation
document appears to be closing some of those escape hatches, and that
makes me nervous.

Item 4 of section 1 recommends that we deprecate the special records
convention. The justification given is appropriate. The special
records rule was the biggest single escape hatch in the original FITS
Agreement of 1979; it was the basis for the Generalized Extensions
Agreement of 1984, which led to TABLE, BINTABLE and IMAGE extensions. I
agree that the Generalized Extensions Agreement "appears to be
sufficient to meet most future needs". Indeed, I would go further and
say that the burden of proof is on anybody who claims that the 1984
Agreement is not able to satisfy some astronomical data structure
requirement. The variety of conventions that have been built on top of
BINTABLE show that it alone has enough versatility and functionality to
solve an enormous range of problems. Also, if we encounter something
that BINTABLE cannot do, it is always possible for us to encapsulate
*any* other data format within FITS, if the other format solves a
problem that FITS can't solve, by creating extensions with
XTENSION='other_format' and the other file in an NAXIS=1 byte array.
Therefore, although this item makes me nervous, I have decided to accept
deprecation of special records.

Item 10 says XTENSION type names *must* be registered. I would prefer
a strong urging accompanied by the usual justification rather than a
'must', precisely because XTENSION is our most important escape hatch,
and I don't want to inhibit experimentation unnecessarily. However, I
won't insist on this matter.

Item 21 recommends changes to section 7.3.3.2 that would "remove the
option to use the heap and the PCOUNT keyword in ways other than
described in the variable length array section 7.3.5". This wording
makes me nervous because tricks with the heap and the gap area are an
obvious potential escape hatch that we left in the Binary Tables
Agreement in 1991. I decided to examine the color-coded differences
document (very nice!). I see changes marked that seem to be related to
this item, but I am unsure which changes accomplish the goal of the
item. Perhaps this item in the Recommended Changes document should
have some text added to clarify this point, or maybe the differences
document is missing some color-coding.

While examining the differences document, I encountered two sentences in
7.3.5 that seem to me to be inconsistent. The first is "The meaning of
a negative value for either of these integers [in the array descriptor]
is not defned by this standard." The second is "The storage referenced
by an array descriptor must lie entirely within the heap area; negative
offsets are not permitted." The first sentence leaves open the option of
a negative offset (and that is an obvious escape hatch, because the
integers are definitely *signed*), but the second sentence closes off
the option. (The text of the second sentence is present in v2.1, so
this isn't the change made for item 21; I don't remember when this
prohibition was introduced; certainly the IAU-FWG could remove it if
they wish.) Apparently the second sentence overules the first sentence,
but the situation makes me nervous. Negative offsets would address the
gap area, and this might be the basis for some clever design that I
cannot imagine at this moment. However, I see nothing to stop a
designer from using simple integer fields in the binary table to contain
pointers that her software would construe as data descriptors for the
gap area. I have decided not to request removal of the negative offset
prohibition, but I do suggest that the apparent conflict of the two
sentences be reviewed.

-Don Wells

 




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 0 August 20th 07 05:53 AM
[fitsbits] Proposed Changes to the FITS Standard Steve Allen FITS 0 August 20th 07 04:47 AM
[fitsbits] Proposed Changes to the FITS Standard Doug Tody FITS 0 August 20th 07 03:40 AM
[fitsbits] Proposed Changes to the FITS Standard Mark Calabretta FITS 0 August 20th 07 03:17 AM
[fitsbits] Proposed Changes to the FITS Standard Preben Grosbol FITS 0 August 16th 07 04:11 PM


All times are GMT +1. The time now is 11:17 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.