Subject: Re: FITS table version numbers.

From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Date: 1 Dec 1993 17:19 EDT

In article <2d751a$l2u at gap.cco.caltech.edu>, mcs at goblin.caltech.edu (Martin Shepherd) writes...
> 
>... one has a FITS file containing a
>number of table extensions which all have the same EXTNAME name, but
>some are represented as ASCII tables and others as binary tables.
> 
>... should the EXTVER numbers be distinct regardless of the
>representation of the table, or should the ASCII table versions follow
>a different sequence of EXTVER numbers than the binary table versions?
> 
>Until today my assumption had been that ASCII and binary table
>extensions were effectively just specific implementations of a generic
>(non-instantiable) table extension, and that regardless of the
>representation, the EXTVER numbers would be distinct if the tables had
>the same EXTNAME and EXTLEV values. 

ASCII Tables ('TABLE   ') and binary tables ('BINTABLE') are separate 
extensions, as separate from each other as from 'IMAGE   '.  So an 
ASCII table and a binary table with the same value of EXTNAME, EXTVER, 
and EXTLEV are distinct extensions.

That said, however, I don't think it's a good idea to have two
extensions in a file with the same values of EXTNAME.  It can be
confusing.  It's like having two different tables in a paper with the
same caption. 

				Barry Schlesinger
				NOST FITS Support Office

---

From: mcs at goblin.caltech.edu (Martin Shepherd)
Date: 2 Dec 1993 05:02:37 GMT

In article <1DEC199317193783 at nssdca.gsfc.nasa.gov> bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes:
>>[Original question and most of answer omitted]
>

With this in mind, would it be wise to consider extending the NOST
standard to say that the values of EXTNAME, EXTVER and EXTLEV are
sufficient to distinguish one extension from another, and that all
extensions must be distinct to this extent? I personally feel that the
particular internal representation of an extension is irrelevant for
identification purposes.

Is it too late to suggest changes to the standard?

>				NOST FITS Support Office

Martin Shepherd  (mcs at phobos.caltech.edu)

---

From: thompson at serts.gsfc.nasa.gov (William Thompson)
Date: 2 Dec 93 19:26:56 GMT

bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER) writes:

	(stuff deleted)

>confusing.  It's like having two different tables in a paper with the

I agree.  Our IDL software is able to select extensions by either EXTNAME, or
by it's position in the file (i.e. the first extension, second, etc.), which is
crude.  If one had two extensions in the file with the same EXTNAME, then there
would be no way to specify which one without resorting to the brute-force
method of using it's position.

Bill Thompson

---

From: pence at tetra.gsfc.nasa.gov (William Pence)
Date: Thu, 2 Dec 93 16:20:45 EST

> confusing.  It's like having two different tables in a paper with the

Related to this EXTNAME discussion, it is perhaps worth recalling that
the OGIP made a proposal here recently of using a hierarchy of HDUCLASn
keywords, in addition to the standard EXTNAME keyword, to provide a
more flexible and detailed way of describing the contents of a
particular extension or the primary array.  We think the HDUCLASn
keywords provide a better way for software to locate a particular
extension it is looking for instead of trying to use the ill-defined
EXTVER or EXTLEVEL keywords to distinquish between different extensions
with identical values for the EXTNAME keyword.  We have only just begun
to use these HDUCLASn keywords, but we think they offer significant
advantages in terms of clearly documenting what is in the extension and
in distinquishing each extension from all the other extensions in the
file in a way that both humans and software can easily understand.

-Bill Pence

---

From: bschlesinger at nssdca.gsfc.nasa.gov (BARRY M. SCHLESINGER)
Date: 3 Dec 1993 11:50 EDT

In article <2djste$i8e at gap.cco.caltech.edu>, mcs at goblin.caltech.edu (Martin Shepherd) writes...
>>... I don't think it's a good idea to have two
>>confusing.   

The formal answer is to say that substantive changes in the NOST 
Standard would have to be considered by a NOST Technical Panels.  

However, it should be emphasized that the NOST role in this process 
has been to codify the FITS standard as given in the FITS papers and 
other documents endorsed by the IAU, not to make the rules.  The 
question here is the interpretation of the language in the Generalized 
Extensions paper, (Grosb\o l, et. al. 1988, A&A Suppl., 73, 359), 
"...to give unique names and version numbers to individual 
extensions..."  The supporting discussion discusses distinguishing 
among  different extensions of type 'TABLE   ' and goes on to motivate
the need for EXTVER by noting that "more than one extension of the
same type and name might occur".  This language suggests that
extensions of different type (TABLE vs BINTABLE) but the same name
would not be regarded as identical.  While I cannot say conclusively
what a Technical Panel would do in this case, I would note that the 
Panel that drafted version 1 approached similar issues by taking the 
position that they should be discussed in the User's Guide.  
Particularly in light of the note by Bill Thompson that use of 
identical values of EXTNAME for two extensions of different files, 
even of the same type, can cause problems for existing software, I 
would expect to recommend against such practices in the next 
comprehensive revision (version 4) of the User's Guide.

				Barry Schlesinger
				NSSDC/NOST FITS Support Office