Re: Empty TD element wording

From: Edward J. Sabol <sabol-at-alderaan.gsfc.nasa.gov>
Date: Tue, 20 Jun 2006 14:01:35 -0400


Mark Taylor wrote:
> I've had the following misleading wording in the VOTable specification
> pointed out to me.
>
> In section 4.6 it says:
>
> In the TABLEDATA data representation, the default representation of
> a ``null'' value is an empty column (i.e. <TD></TD>); for fields
> containing arrays, individual ``null'' elements of the array can
> be specified either by the value specified in the null attribute,
> or by the "NaN" or "nan" text in place of the expected numeric value.
>
> This sentence only applies to certain datatypes; in particular it is
> not true of integer types (unsignedByte, short, int, long), which fact
> is made explicit in the relevant paragraphs of section 6.
>
> I suggest that (at such time as the next version of the VOTable
> document is released) the sentence above is withdrawn, or modified to
> make it clear that it applies only to certain datatypes.

I have actually been meaning to propose a change to the VOTable specification here that would extend the validity of "<TD></TD>" to include integers, so I am in agreement with Mark and would strongly favor withdrawing this restriction on integer nulls entirely. The only alternative method for specifying null integers is to determine some integer value that does not exist in the range of valid values for that column and specify that as the null value. This is rather impractical and makes it impossible to dump the table data a row at a time (such as when querying from a database) in a stream-like fashion. Basically, you have to read or scan the whole table (or at least just the integer columns) before being able to dump the table in VOTable format. Also, I am aware of at least two VOTable implementations that ignore this restriction, so perhaps a case could be made that the VOTable standard should reflect the reality of existing VOTable implementations. When I first came across this restriction on how to encode integer nulls in TABLEDATA respresentation some months ago, I spent some time searching the mailing list archive and wiki trying to determine why this restriction was written into the standard. I could not find any such discussion, though perhaps I just did not look hard enough. Could someone here can explain or make a positive case for it or point me to some historical dicussion of the issue?

Thanks,
Ed

-- 
Edward J. Sabol (an employee of Science Systems and Applications, Inc.)
HEASARC Database Administrator
High Energy Astrophysics Science Archive Research Center
Exploration of the Universe Division
NASA / Goddard Space Flight Center
Received on 2006-06-20Z20:44:10