Empty TD element wording

[Rob Seaman]

Hi Clive,

> Since the set-theory basis of RDBMS actually becomes inconsistent  
> in the face of even one type of null, there are many who think that  
> they are all evil.

It's issues like this that bring computer science into conflict with  
the various communities (not just astronomy) that use computers.  If  
the real world (or virtual, for that matter) reveals requirements for  
special values such as null, it should be computer science that  
adjusts to suit.  (Seems to me I've had this discussion regarding  
timekeeping :-)

Or perhaps there is already some standard answer for how an RDBMS  
should support missing or overflow data values?

> In practice, as Mark said astronomers have long managed with just  
> one type of null in FITS files.

Poorly, I think - and only IEEE floating point.  For image arrays,  
for instance, the only coherent way to handle special valued pixels  
is to carry around a separate mask marking those pixels.  For a  
table, this is equivalent to instantiating an arbitrary number of  
flags attached to each row or even each field in each row.  Maybe the  
answer is just that you have to punt by preceding each per-pixel or  
per-field mathematical operation with several boolean conditionality  
checks.

> I think it would be more productive to work on a standard way of  
> expressing the notion of upper (or lower) limits - something which  
> is so far missing from most astronomical formats.

Seems like a separate issue - overlimit/underlimit versus NaN versus  
no-data.  Absence of evidence is not evidence of absence is not a  
handling error (such as a "mathematical" exception - really a failure  
of an algorithm or data representation in most cases).

Rob