<HTML><BODY style="word-wrap: break-word; -khtml-nbsp-mode: space; -khtml-line-break: after-white-space; "><DIV><DIV>William Pence wrote:</DIV><BR class="Apple-interchange-newline"><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Maybe I'm missing your point, but I don't see how that paper can be interpreted as an endorsement of the inherit convention.</DIV></BLOCKQUOTE><DIV><BR class="khtml-block-placeholder"></DIV>It can't. The fact that the paper attempted to force a particular outcome - that primary HDUs not be empty - and that empty primary HDUs have instead become widespread, respected usage was my (admittedly obscure) point.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>A FITS file is either conforming or it isn't. Nothing requires that HDUs not be empty, for whatever purpose. Users are also permitted to define new keywords with new interpretations.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>In this case, fundamental goals of DB normalization drive the existence of a primary header to contain keywords that apply to all other extensions in a file. There are reasons more basic than not consuming an additional N*80 bytes (1.2 KB for each Mosaic keyword) for not duplicating redundant keywords.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV><BLOCKQUOTE type="cite"><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Some might suggest that with the abundance of low cost disk space that is now available, the inherit convention is trying to fix a non-problem.</DIV></BLOCKQUOTE><BR></DIV><DIV>The diskspace may be a non-problem (although this is a quirky opinion coming from a FITS compression stalwart :–), but the underlying question is about the purpose of registering conventions in the first place.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>I would have thought that the key goal was to collect descriptions of local usage, not to vet long-established usage against esthetic criteria. By insisting on the latter, the danger is that conventions will go unregistered, perhaps undocumented. Is this a preferred outcome?</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV>If the warning:</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><SPAN class="Apple-tab-span" style="white-space:pre"> </SPAN><I>"These conventions are not necessarily endorsed by the IAU FITS Working Group."</I></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">is not deemed strong enough, how about labeling *all* of the conventions with something snarkier? There is nothing demonstrably less conforming to the standard about INHERIT than any other convention.</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><I><BR class="khtml-block-placeholder"></I></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">I also suggest deleting the entire section "Practical Considerations" from <A href="http://fits.gsfc.nasa.gov/registry/inherit/fits_inheritance.txt">http://fits.gsfc.nasa.gov/registry/inherit/fits_inheritance.txt</A>. It amounts to nothing more than stating that unusual things might happen if files are run through software that doesn't know about the particular convention. This applies to all conventions (and all software), and it seems to this observer that INHERIT is rather more user friendly in such a case than most.</DIV><DIV><BR class="khtml-block-placeholder"></DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; ">Rob</DIV><DIV style="margin-top: 0px; margin-right: 0px; margin-bottom: 0px; margin-left: 0px; "><BR class="khtml-block-placeholder"></DIV></BODY></HTML>