[fitsbits] Start of the CONTINUE keyword Public Comment Period

This is to announce the start of the 30-day Public Comment Period on
the CONTINUE keyword convention that has been submitted for inclusion in
the 'Registry of FITS Conventions' which is maintained by the IAU FITS
Working Group. This is the 9th in a growing series of conventions
submitted for inclusion in the Registry.

Detailed information about this convention and a sample FITS file that
uses it are available for public review and comment from the FITS
registry web page at

http://fits.gsfc.nasa.gov/fits_registry.html

The CONTINUE keyword allows long character string keyword values to be
continued on the next keyword(s) in the FITS header. This convention
supports string keyword values that are longer than the 68-character
maximum that can be represented in a single FITS keyword. A trivial
example of this convention is shown below:

SVALUE = 'This is a long string value that is &' / Any comments
CONTINUE 'continued over three keywords& ' / may be appended
CONTINUE ' in the FITS header.' / after the quoted value.

Under this convention, the last character of each string that is to be
continued must be the `&' character, and the continuation string is
contained in a sequence of 1 or more CONTINUE keywords (which do not
have a `=' character in column 9 and hence have no formal value).

Comments may be posted here on the FITSBITS mail exploder or the
sci.astro.fits newsgroup. Minor typographical issues may be sent
directly to the authors of the convention.

Bill Pence
(on behalf of the IAU FITS Working Group)
--
__________________________________________________ __________________
Dr. William Pence
NASA/GSFC Code 662 HEASARC +1-301-286-4599 (voice)
Greenbelt MD 20771 +1-301-286-1684 (fax)

Before I disappear, I give some brief comments :

I think the material supplied to document the convention is clear enough
(and the convention is sound and simple, although I remind everybody
that inclusion in the Registry should NOT imply a discussion on the
merit of a convention, but only on completeness of documentation,
usefulness and actual use at one or more institution).

I do not think the issue of keyword ordering and repetition of a keyword
with same name is an issue, considering the proposed modifications to
the Standard, and the nature of "commentary" keyword of CONTINUE.

I am also pleased by the fact that this convention can be clearly
spotted by a reader because of the presence of the "magic" string
LONGSTRN= 'OGIP 1.0'

So my only request for change is very formal. The explanatory document
http://fits.gsfc.nasa.gov/registry/c...e_keyword.html is
correctly titled "CONTINUE *Long String* Keyword Convention"

I suggest this title (including the words *Long String*) be used even in
higher level pages in the Registry instead of the shorter "CONTINUE
Keyword Convention".

The convention is clearly documented to deal with long STRINGS "only"
(not numeric valued keywords which somebody mentioned), and is not
characterized *just by the presence* of the CONTINUE keywords.

But the specific ways it uses the CONTINUE keywords are flagged by
LONGSTRN= 'OGIP 1.0'.

So the proper name would be "CONTINUE *Long String* Keyword Convention"
or "OGIP 1.0 *Long String* Keyword Convention"

(assuming one could develop e.g. a LONGSTRN= 'Erewhon University 7.3'
which uses a different continuation mechanism)


Lucio Chiappetti - INAF IASF Milano

--
----------------------------------------------------------------------
is a newsreading account used by more persons to
avoid unwanted spam. Any mail returning to this address will be rejected.
Users can disclose their e-mail address in the article if they wish so.

On Jul 14, 2007, at 6:46 PM, Craig Markwardt wrote:

Bill, could the convention be clarified to indicate that CONTINUE
should not be used for keyword values that could fit in a single
FITS card?

I'm not sure how one ensures this given that a continued keyword
might later be edited.

And/or, that CONTINUE should be avoided for standard FITS keywords?

Which are the "standard" keywords - the ones mentioned in the
standard? My example was a keyword from another convention.

On Jul 13, 2007, at 2:28 AM, LC's NoSpam Newsreading account wrote:

I remind everybody that inclusion in the Registry should NOT imply
a discussion on the merit of a convention, but only on completeness
of documentation, usefulness and actual use at one or more
institution).

Well, every previous convention has also generated a rousing
discussion of the merits of the proposal. This seems rather
healthy. I'm also not sure what the distinction is between "merit"
and "usefulness".

Presumably we are in a period of capturing and documenting as many
local conventions as possible. The bigger question is what comes
next. Some (I'll timidly suggest the checksum convention) seem
mature enough to become part of the standard. Others, as with this
current discussion, appear to have some real issues with broad
adoption. Still others, like foreign encapsulation perhaps, might
simply appear as some sort of appendix since a particular HDU either
expresses such an object or does not.

I guess I'm also wondering whether the point of the registry is to
capture legacy conventions or to encourage new conventions.
Personally, I would prefer that the staid, but reliable, FITS
standard process remain the primary focus of FITS development
efforts. We don't need novelty for its own sake.

I do not think the issue of keyword ordering and repetition of a
keyword with same name is an issue, considering the proposed
modifications to the Standard,

I'm getting lost with this discussion. What proposed modifications
are we talking about?

So the proper name would be "CONTINUE *Long String* Keyword
Convention" or "OGIP 1.0 *Long String* Keyword Convention"

I disagree. Continuation is only one possible way to implement a
long string capability. To be truly useful, a general facility for
representing long strings needs to be applicable to any string valued
keyword. On the other hand, continuing a keyword appears to have
some real complications - some esoteric, like the need to preserve 32-
bit alignment within ASCII encoded checksum strings - others more
fundamental, such as ambiguous keyword ordering restrictions.

But, if we're not to discuss merit, that drops us to two criteria for
registration: documentation and prior use. Like all the other
conventions to date, this one appears to have been actually used in
some large or small number of files. The documentation seems too
minimal and unconstraining, however, as expressed in the previous
messages in this thread.

Rob