[fitsbits] The CONTINUE and HIERARCH Conventions Public CommentPeriods

On 9/10/07 12:45 PM, "William Pence" 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/h...h_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