Subject: substring proposal

From: Bob Hanisch <[email-masked]>
Date: Mon, 12 Apr 93 11:09:19 EDT

I think Bill's proposal is a good way to handle substrings _in_principal_, but
object to this particular implementation.  In particular, this convention is
unlike any other in FITS in that it alters the list of acceptable values for a
reserved keyword in a manner that could cause a FITS reader to fail.  The
binary tables proposal gives an explicit list of accepted values (rB, rI, rJ,
rA, rE, rD, rC, rM, rP).  Allowing this to be extended to rAw/nnn could easily
cause problems for FITS readers that adhere to the standard for binary tables
but do not support the proposed add-on convention.  That is, it would not be
unreasonable for a reader simply take the value of TFORMnnn _as_is_, without
checking for the extension characters.  This would most likely cause the reader
to fail if it encountered the substring notation.

Even though the TDIM convention in Appendix B is somewhat less clever, it
does not have the problem identified above.  If the TDIM keyword is not
understood by a FITS reader, no harm is done.  Thus, I would suggest that
a similar technique be used to support the substring convention.  A new
keyword should be defined which _complements_ TFORMnnn for type rA data.
The value fields for TFORMnnn should be left unchanged.  Indeed, I would 
argue that the proposed Appendix C, should it be acceptable otherwise, forces
us to revise the main part of the binary tables proposal so that it is clear
that other characters might be appended to the "rA" string (and, presumably,
to the other data type strings).

Bob Hanisch