[fitsbits] Start of the 'INHERIT' Public Comment Period

[Rob Seaman]

Archie Warnock wrote:

>> No, but avoiding potential errors by not duplicating text strings  
>> is a worthy effort, as we learned long ago from relational  
>> database theory.

Like I said, well-worn principles of database normalization.

>> In current practice or not, I think the philosophy of "it's better  
>> to seek forgiveness than permission" is dangerous in this context.

I'm a little unclear what permission should have been sought and from  
whom.  INHERIT is completely legal FITS usage - the MEF format is  
legal, the dataless HDU is legal and the keyword is a legal boolean.   
This is particularly true since in the absence of a coherent data  
model, FITS is silent on issues of the semantic interconnectedness of  
extensions.

Absent a data model, software developers still need to develop.

>> If a convention breaks FITS, I believe it should be considered a  
>> private agreement and not part of the FITS standard.  That doesn't  
>> mean it can't be used in practice - just that it's not FITS.

None of the conventions are part of the FITS standard.  However, even  
nonconforming FITS cannot "break FITS" or even break FITS  
applications.  An application should do something reasonable even if  
presented with nonconforming input.  In any event, input conforming  
to the INHERIT convention also conforms to FITS.  Some applications  
may not know what to do with it, but the absence of a feature is not  
precisely the same thing as the presence of a bug.


Thierry Forveille wrote:

> One single binary table maps a lot better to a data base than  
> multiple image extensions that may or may not duplicate header  
> information.

I disagree.  A typical normalized database consists of several  
tables.  These tables may correspond to binary tables in FITS, but  
also may correspond to a hierarchy of FITS headers.  Well chosen  
image extension headers will often be better than a single flat  
binary table.

> would it perhaps be time to consider deprecating the IMAGE extension??

Obviously a rhetorical question, but no, of course not.  IMAGE  
extensions provide a mechanism for aggregating classical FITS image  
objects.  FITS exists for mere astronomical mortals, not just for  
titans of software engineering.  An MEF file of image extensions is  
vastly more accessible to our users, and likely much more robust for  
our applications.  Not all astronomical data maps well onto image  
arrays, but CCDs and other array detectors do.

On the other hand, tile compression provides a natural path for image  
extensions to map, one-to-one, onto binary tables.  The headers, of  
course, copy directly across.  Presumably by recommending the  
deprecation of the image extension, you're really suggesting  
deprecating the idea of the FITS header itself.

Rob