Subject: Returned mail: unknown mailer error 1

From: MAILER-DAEMON (Mail Delivery Subsystem)
Date: Tue, 8 Dec 92 15:36:40 EST

----- Transcript of session follows -----
/bin/sh: /fits/dwells/FITS/wfc.log: Permission denied
554 "|/bin/sh -c 'cat >> /fits/dwells/FITS/wfc.log'"... unknown mailer error 1

   ----- Unsent message follows -----
Date: Tue, 8 Dec 92 15:36:59 EST
From: [email-masked] (William Pence)
To: [email-masked]
Subject: Re: binary tables discussion
Sender: [email-masked]

In reply to Doug Tody's message on 7 Dec 1992:

On whether to vote now, or postpone it until the technical issues are 
resolved:

My preference would be to hold off on the vote until this character
string issue is resolved.  I think this is an important issue;  I also
think we are actually close to an agreement on how to support both
fixed and delimited strings (as has been discussed previously in the
sci.astro.fits group) so I would think we could have a new draft in a
week or 2 at the most.  The changes would only affect the appendices
and not the main body of the binary table proposal. I have lobbyed for
this change for a long time to whoever listens to astro.sci.fits, but
now that the WFC has been formed I would like to see this issue
seriously addressed.

On the other hand, if our Chairman feels that there is a need to have
a vote on the proposals immediately, then I would go along with the
decision.  But I seems to me that a couple week's delay would not
hurt much.  

Regarging the vote, I still don't really understand what it means
to vote on a document that states (in Appendix B) that "this facility
is undergoing trials and is not currently part of the main binary
table definition".  It seems to me we need to either approve or
disapprove this convention, and remove the wafflely words about it
being under trial.  The HEASARC, for one, is already using this
convention is some of it's FITS files, so we would like to see it approved
as more than just a 'trial').

On some of the technical issues:

1.  Defining the string length in a FITS table is of fundamental 
importance and is distinctly different from defining multidimensional
arrays.

In order to read or write to a character ('A') column in a binary table
it is *required* that you know how to determine the character string
length since users are almost always interested in reading or writing
strings, not individual characters.  As an example, suppose a user
asks me to write an array of character strings to a character
column which has TFORM = '40A'.  I am unable to do this however until
you also tell me how to pack the strings into the column;  should
I write one string into each 40 character field, or should I perhaps
write 4 strings, each with a maximum of 10 characters into the same
field.  Or, should I pack as many strings as possible into the field
using a delimiter code character??  The point is that defining the
string length (regardless of whether it is fixed length or variable length)
is of such fundamental importance in order to correctly interpret a 
character column that this information should be directly encoded
into the TFORM string, and not relegated to an optional TDIM keyword
which also serves a different purpose.

To just briefly follow up on this arguement, note that this problem
does not affect any other datatype column.  For instance, if I am asked
to write 50 real*4 numbers into a column that has TFORM = '20E' then
there is little ambiguity about what to do: simply write 20 numbers
into each of the first 2 rows, and the remaining 10 numbers into the
beginning of the 3rd row. (Or one could write one number into the first
element of the first 50 rows.  But this ambiguity can easily be resolved
by defining a convention within any given user interface).  At this
level of data access there is never any need to know anything about the
higher-level dimensionality of the data that is being written or read
as defined by the TDIM convention.

2.  On the issue of fixed length vs. delimited character strings.

My proposal is quite conservative in that it is only suggesting a much
more useful way of specifying the size of fixed-length strings instead
of using the TDIM convention described in Appendix A.  (Note that the
TDIM convention also doesn't provide any way to define delimited string
fields).  To raise the possibility of allowing arrays of  variable
length strings (i.e., delimited strings) in character columns is much
more controversial.  But in any case, my proposal for specifying fixed
length strings in no way prohibits or limits defining additional
conventions for variable length strings. either now, or in the future.

I have thought quite a bit about how one might support arrays of
delimited strings in FITS files through the FITSIO interface,  but it
raises a number of thorny issues, and it doesn't seem to provide much
practical benefit when dealing with fixed format structures like FITS
files.  The concept of delimited strings may be great in an environment
where you have a dynamic memory allocation capablility, but in FITS
files with fixed length fields and rows, having delimited strings is
not really very useful;  for instance you don't gain any savings in
file size, since each column has a fixed width (except for variable
length arrays, which is not at issue here).  So it seems to me that
allowing for delimited-string arrays in character columns introduces a
lot more problems than it is worth.

-Bill Pence