ASCII table tricks

[Steve Allen]

In article <509h5b$4np at cnn.princeton.edu>,
Edward J. Groth   609-258-4361 <groth at pupgg.princeton.edu> wrote:

>Are you prepared to deal with the following?
>
>PC user ftp's table, messes around with it, uploads a new version
>and all of a sudden your software croaks because there are now
>carriage returns as well as line feeds where they used to be only
>line feeds and all the positions of the fields are off????

Using a good editor the file is just as trivial to return to FITS
conformance as it was for a bad editor to break it.  There are far
worse things that can happen when accepting files from a careless or
disreputable PC user.

The casual inspection and modification of FITS tables using generic
text editors rather than FITS-specific ones opens many possibilities.
ASCII tables could be subjected to powerful regular expression
matching, substituting, and sorting tools which do not otherwise exist
for FITS.  The similarity with database inload/outload functions can
permit FITS tables to be used as a state-saving and transfer device
for the contents of relational databases.  FITS ASCII tables are
much more robust and self-documenting than most such RDB tools.

I see this as a way of putting FITS capabilities into the hands of
people who would otherwise not have it because of the bother of
constructing programs that do FITS I/O.  I doubt that there can be any
FITS ASCII table reader which would be unable to read such files.

Whether intentional or not the standards documents seem to have
permitted a format which could make the data in ASCII tables much more
accessible to everyone.  Is this a bad thing that must be squelched
or a good thing that should be pursued?
--
Steve Allen          UCO/Lick Observatory       Santa Cruz, CA 95064
sla at ucolick.org      Voice: +1 408 459 3046     FAX: +1 408 454 9863
WWW: http://www.ucolick.org/~sla                PGP public keys:  see WWW