[fitsbits] The CONTINUE and HIERARCH Conventions Public Comment Periods

[Robert Hanisch]

On 9/10/07 12:45 PM, "William Pence" <pence at milkyway.gsfc.nasa.gov> wrote:

> Robert Hanisch wrote:
>> The description of the HIERARCH convention is inconsistent, I think,
>> regarding the length of the component tokens.
>> 
>> At the top of p. 2 it says
>> 
>> "Under the ESO implementation of this convention, each token string which
>> precede[s] the equals sign conforms to the requirements for a FITS
>> keyword..."
>> 
>> But in Section 2, this rule is abandoned and the same scheme is used for
>> defining long and non-conforming keyword names.  So, as written it is not
>> really clear whether it is the ESO implementation that is being discussed,
>> or the more general thing.  That is, would the following conform to the
>> convention?
>> 
>>     HIERARCH HST-ADVANCED-CAMERA APERTURE$Setting = 2
> 
> No, this does not conform this convention. The 2 tokens
> ("HST-ADVANCED-CAMERA" and "APERTURE$Setting") are not legal FITS
> keyword names, so this does not conform to the ESO use of the convention
> (although ESO bends the rules slightly, and does allow tokens longer
> than 8 characters).  The more general HIERARCH convention that is
> described in the last half of the document disallows spaces in the
> "effective keyword name", so this example does not conform to that.

But it does NOT disallow spaces, it just says they should be avoided in
order to avoid confusion, and this was exactly the reason for my example.
And if ESO bends their own rule and has tokens longer than 8 characters,
then the definition of the convention is pretty sloppy.  It would mean that

    HIERARCH DOMAINNAME SUBDOMAIN LONGKEYNAME = 2

both conforms and does not conform to the convention.

To clarify things it seems this needs text that says that if a long keyword
name is being specified, only one token after HIERARCH is allowed prior to
the " = value ".  But this then probably invalidates all those ESO files
that use tokens longer than 8 characters.

Despite my misgivings I am not really objecting to the convention itself,
but rather noting that the description is confusing and inconsistent.

Bob

> If 
> you replaced the space between the 2 tokens with an underscore, then it
> would conform to the more general convention:
> 
>       HIERARCH HST-ADVANCED-CAMERA_APERTURE$Setting = 2
> 
>> Finally, on p. 3 it says "This convention should not be used if the
>> effective keyword name can be represented as a standard FITS keyword...".  I
>> think it can be argued that one can always find a standard FITS keyword
>> representation, as has been done 1000s of times in FITS headers.
> 
> The statement you quote is intended to disallow usage like this:
> 
>     HIERARCH  USERNAME = "John"
> 
> In this case, "USERNAME" is a legal FITS keyword name, so there is no
> need to use the more complicated HIERARCH convention.

>> I believe I share some responsibility for the invention of HIERARCH (I
>> think I first suggested it at a FITS WCS meeting in Charlottesville, ca.
>> 1989).  I have regretted it at various times ever since.
> 
> I initially shared your dislike of the HIERARCH convention, but have
> changed my mind after seeing how well it has worked in the ESO FITS
> files.  If you look at the sample FITS header listing from ESO  given at
> http://fits.gsfc.nasa.gov/registry/hierarch_keyword.html (the fors.txt
> link) there are hundreds of keywords that use this convention in each
> file.  It would be difficult to come up with clear and informative
> 8-character names for this many keywords.  I think ESO has done a pretty
> good job of defining a self consistent set of hierarchical keyword names
> for all its dozens of telescope and instrument data systems.  I agree
> however that it probably would not make sense to use the HIERARCH
> convention for just a couple keywords in a file.
> 
> I don't particularly like the more generalized use of the HIERARCH
> convention to create keyword names that are longer than 8 characters or
> contain non-standard characters (even though I added support for this in
> the CFITSIO library).  If we really want to extend FITS to allow longer
> keyword names, then I think a much simpler way to do this is to just
> allow free-format keyword records in which the "=" can appear anywhere
> after byte 9 of the record, such as:
> 
> MY_LONG_KEYWORD = 17 / comment string
> 
> Note that this keyword is perfectly legal under the current FITS
> Standard: existing FITS readers should interpret this as a
> commentary-type keyword, with the 8-character name "MY_LONG_" and the
> rest of the record treated as a comment string.
> 
> Bill