proposal to turn the tables

[Ed Shaya]

Technically one can shove columns into TD elements, but it does not 
carry the same semantic meaning.  Arrays placed into TD do not 
necessarily have a relation between all of the Nth elements.  If a table 
has a column with a spectrum and another column with a list of URLs, 
there is no implicit relation between the 23 pixel of the spectrum and 
the 23 URL.   That is why I suggest that we add a new element TFIELD to 
explicitly state that these are still the table's fields and record 
relationships between the fields still holds.  Using TDs to do both 
creates a case of ambiguous overriding.

As to the size,  using the FIELD/@arraysize attribute is reasonable. 
 When the application sees that there are TFIELDS instead of TR/TD it 
can safely assume the arraysize pertains to them.

I am confused by the char/string situation in VOTABLE.  Is char a single 
char, or does it mean character data in general (string), or is it 
character data without a space?  If you say you need string data in 
addition to char data, then the existing VOTABLE spec is missing 
something.  
Perhaps Francois is asking what to do about spaces in string lists. 
 Schema listTypes in XML are delimited by spaces.  So if an atom of data 
has a string in it you need to do something about that.  Up to now most 
of us have just put "_" underscores between words to hold them in a 
nmtoken.  But, we can do better than that.  One can use any specal 
character and simply have a FIELD/@spaceChar to indicate it.  But the 
best way is to use the   entity which means "no break space" which 
is what it is!  It is then necessary that the   character be 
defined at least in the schema.  For non-validating browsers (Mozilla) 
it needs to be defined at the top of the document.

The nil would require a noData attribute as I believe that, in elements, 
double spaces get normalized to a single space.  Since bit data takes 
only 0  and  1 one would not have a nil there.  One could change bitList 
to takes -1,0,1 and use -1 for nil.  But, I don't think that bit data 
needs this much.  Perhaps we could have an additional type: bitsyType.

Remember that this would all be optional.  If for certain types of data 
or uses of data it is better to use td cells then one still could.

Finally, I am making this suggestions only after being told that 
suggestions are being taken for the next version of VOTABLE.  Presumably 
some day there will be changes made to VOTABLE and certainly that will 
require some effort on the part of the implementors.  

Ed