From: [email-masked] (Jonathan McDowell)
Date: Wed, 21 Apr 93 13:41:59 -0400

Response to Ian, Clive and Barry:

1)   I think the correct 1-d analog of pixel is probably 'bin', but I
agree in practice we have to accept 'pixel' and live with the 
ambiguity. 

2) W m**(-2)

  I don't think we need to worry so much about simplifying the parser,
so I would not suggest the parens should be required for simpler cases
like cm**2. 

Clive's point is well taken about the conciseness of the / form.  Again,
I'm happy to code my parser to be able to read either form. I stand
by my preference for the **(-n) form in complex cases. I think the
argument about software dropping parts of the string is bogus;
we should be able to use the full FITS character header card
space; but the argument about the difficulty of displaying it
has more force. For me, though, the deciding factor is that
our string should clearly and unambiguously define the units
used in the file. Displaying that string easily is less important
since your software can parse and reformat it as it likes.

3) keV vs 10**(3) eV.

I strongly agree with Clive and disagree with Ian on this point. It sort
of revolves on whether we think it is mainly software or mainly humans
who are going to read these strings. I think in practice they are often
going to be passed directly to humans for simple applications, so let's
use the SI prefixes we know and love. In particular if we mandate
10**(3) eV and forbid keV, no X-ray astronomer is actually going to obey
our standard.

By the way, the prefix range defined in SI is now 10**-24 to 10**+24
with the new y,z,Y,Z prefixes.

4) 10*44 erg/s

I think Barry's point about the TSCALn keyword solves this issue
elegantly, and hope all will agree that this removes the need for 
numerical prefixes in the unit strings themselves.

   - Jonathan