[fitsbits] Keywords "explicitly declared ... long-string"? {External} {External}

[Lucio Chiappetti]

On Tue, 25 Feb 2025, Barrett, Paul via fitsbits wrote:

> My understanding of this sentence is that you cannot use long-string 
> values with mandatory or reserved keywords unless they are explicitly 
> declared as such. Currently, no mandatory or reserved keywords have such 
> a declaration.

I scanned the correspondence at the time we wrote the FITS 4.0 document 
(which was finished 7 years ago !) and I can confirm what above.

I also scanned a dictionary of mine, which lists 48 mandatory and 235 
reserved kwds. None of the currently used ones in such categories is "long 
string".

Conversely no kwd is *explicitly* defined "short string" (though all 
"string" in the Standard defaults to short string for mandatory and 
reserved kwds). The ones which de facto are implicitly defined "short 
string" are XTENSION and ZTENSION (whose values are a limited set of 
HDU types) and all DATE* DOBSn DAVGn being a datetime value. Of these only 
XTENSION is a "mandatory kwd" (all others are reserved).

Note also that most of the "mandatory kwds" are numeric or boolean valued, 
the only mandatory "string" are TFORMn ZFORMn ZCMPTYPE.

Finally note that COMMENT HISTORY blank are formally valueless kwds, not 
string kwds.

> I don't think it means that FITS plans to implement keywords having more
> than 8 characters. The Hierarch keyword covers this situation.

Please do not confuse "long strings" (long VALUE strings) with "long NAME 
kwds". "Long names" were discussed in 2020 but no conclusion was reached 
about changuing the standard (though it would not be terribly difficult 
for NEW keywords). Alternatives discussed were the HIERARCH convention, or 
the record-valued like DQ1A proposed in a draft WCS paper IV (never 
published or formalized) or possible metadata extensions,

On Tue, 25 Feb 2025, Seaman, Robert Lewis - (rseaman) via fitsbits wrote:
> general? Note that it is perfectly legal FITS to define a bintable
> extension to contain all metadata that in antediluvian days would have
> shown up in ASCII header keywords

In fact this seems a rather sensible suggestion.

On Tue, 25 Feb 2025, Tim Jenness via fitsbits wrote:

> It has just been pointed out to me that we use a TDOCn header with the
> documentation for the column (which I think is a local extension maybe?)

I can confirm that TDOCn is not listed in the Standards document neither 
as mandatory nor as reserved, so it should be local usage.

-- 
The Great Dumbening(tm) started the day smartphone internet traffic 
overtook that of desktop PCs.
(user moonbat on https://forum.palemoon.org 12 Aug 2024 04:21)