[fitsbits] TDIMn

[William Thompson]

The NASA/ESA SOHO project has been using TDIMn since 1995.  I strongly support 
adopting TDIMn officially.

The IDL software I wrote many years ago for binary tables does support variable 
length arrays, but I'm not aware of any projects within the solar community 
actually using it.  I can ask around.

I'm not aware of any projects using the substring array convention, and am not 
sure how well it's supported.  My own software does not explicitely support it, 
but wouldn't be confused by its presence.

Bill Thompson


Eric Greisen wrote:
> I share much of Preben's uncertainties about adopting the appendices.
> 
> The TDIMn (B.2) is absolutely needed and is or soon will be used.  It
> is also a convention that can be ignored by general readers that do
> not need to know the internal details of a table column's data.  It
> uses a previously non-standard keyword and so has been ignored by
> general readers.
> 
> The substring convention (B.3) is also relatively harmless in that a
> general routine may ignore all the substring notation.  However, that
> notation appears as part of the data value of a standard keyword and
> so may (should??) confuse a general reader that does not support the
> extension.  Has this been used by anyone?
> 
> The heap convention however does worry me.  It changes the data
> structure in the FITS file and I expect that general FITS readers will
> not normally support the convention internally.  In fact, I have
> always regarded this convention with the worry that it encourages a
> lack of discipline in designing the data tables in the first place.
> Thus an over-worked designer may decide to dump all sorts of data into
> a single table piling most of the "table" data into an unstructured
> heap, rather than building two or more cleanly structured tables
> separating unlike data into separate columns/tables.
> 
> I do not doubt that the heap may be an excellent choice for an
> internal format in a data system geared to handle it.  But as a
> communication-of-data choice I expect that it will not be implemented
> generally and hence stand in the way of communication.
> 
> Eric Greisen