Subject: BINTABLE and unsigned integers

From: "BARRY M. SCHLESINGER" <[email-masked]>
Date: Thu, 21 Apr 1994 9:02:38 -0400 (EDT)

Dear IAU-FWG members,
	My first answer was made using REPLY and so apparently went to 
the REQUEST branch.  So if it shows up later, now you'll know why.

> For BINTABLE, I ask you for your opinion on two additional issues:

>  a) The possible scaling of values pointed to by a P-format field
>    was mentioned on the news-group. To make that possible through
>    a conversion later the authors of the BINTABLE proposal suggest
>    to change the sentence page 4 point 6:
>       'Note: TSCALnnn and TZEROnnn are not defined for A, L, P,
>        or X format fields'
>    to:
>       'Note: TSCALnnn and TZEROnnn are not defined for A, L, or
>        X format fields.  The anticipated meaning of TSCALnnn and
>        TZEROnnn for P fields is described in Appendix A.'

	I suggested the approach of having TSCALn and TZEROn for P
fields apply to the heap data designated by the array descriptor in
response to a posting from Fermilab that there was no way to scale
heap data. Bill Pence concurred that the inability to scale heap data
was probably an oversight.  This wording, along with appropriate
revisions to Appendix A (which, I understand, is not a subject of the
vote) should provide for scaling of heap data. 

> b) ... unsigned integer types. 
>   ... Such a change would be significant and call for a re-approval
>    of a modified BINTABLE proposal by the local FITS groups! Thus,
>    two approaches can be made:
>     b1) We can regard the suggestion for unsigned integer types
>         not justified and go ahead with the formal approval of the
>         BINTABLE proposal with the minor clarifications,
>    or
>     b2) Postpone a vote in the IAU FITS WG until the local FITS
>         Committees have had time to consider and approve a revised
>         version of the BINTABLE proposal. (This may well take more
>         than one year.)

	I would propose an alternative b3), (or perhaps b1')).  That
approach would be to proceed now with approval of BINTABLE as it 
stands without prejudice as to the future addition of unsigned 
integers.  The idea would be that since there is no community 
consensus at present in favor of unsigned integers, it would clearly
be inappropriate to include them now, but, should the community so
decide at a later time, they could then be added to BINTABLE as one or
more additional data types.  Approval of such an addition would follow
the regular procedure. 
	There is a precedent for adding new data types to an existing 
format: the Floating Point Agreement.  If it were decided to 
incorporate any unsigned integer data types, they would be additions 
to BINTABLE as it is and not change the extension rules in such a way 
as to cause any violation of the rules by existing files.
	This approach allows us to formally approve the widely used 
and much needed BINTABLE now, at the same time not forcing an 
immediate decision on unsigned integers.

			Best regards,
			Barry Schlesinger