proposal to turn the tables
edward.j.shaya.1 at gsfc.nasa.gov
Mon Apr 28 10:25:40 PDT 2003
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
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.
More information about the votable