proposal to turn the tables

Francois Ochsenbein francois at vizir.u-strasbg.fr
Mon Apr 28 00:48:07 PDT 2003


The 'transposed' scheme proposed by Ed can be usefull in several
applications, but I see a couple of drawbacks:

-> can it work for alphabetical (string) fields ? Since only the 'character'
   is a basic data type, I don't see a solution with the current definitions.
   And strings in column contents are so common in VOTables...
-> how can it be used in streaming processing ? Isn't there a need to 
   specify the size (number of rows) ? Or just rely on the number of items
   of the first 'column' ?
-> how can NULLs (unspecified values) be specified ?

VOTable also allows arrays -- specified by the "arraysize" atwtribute
of the FIELD element -- on other terms it looks like a single-row table with
array columns would do the same thing. Or did I miss anything ?

--Francois

>
>I would like to propose an option for VOTable in which the table is 
>turned sideways so
>that the numbers within a field are adjacent.  To accomplish this I add 
>an additional
>optional element to TABLEDATA calleed TFIELD.  The TFIELD element holds an
>entire column and we introduce simpleTypes:
>bitList  eg  <TFIELD xsi:type="bitList" 
>fieldREF="ID02">101010101111</TFIELD>
>booleanList "TFTFFFT010101"
>floatList   "1.212 211.21 2121.00 3.3E7"
>longList    "1231231231 123132333 52413413"
>shortList  "12 312 300 202"
>floatComplexList "1.5E3 2.2E6 4.4E8 8.8E4"
>charList "objectID star galaxy M81"
>  ETC.
>For the complex numbers the first is a real number and the second is the 
>corresponding imaginary.
>
>I have already added all of this to the attached schema and I have an 
>example which illustrates
>the different ListTypes.
>
>The advantages of this are:
>1. Can  carry much larger tables
>    A. removing all of the <TD></TD> from each cell is a significant 
>size reduction
>    B. reducing the number of nodes greatly reduces memory size of DOM 
>or any views in which each node is another object.
>    C. Reduces parsing and validation time.
>2. Allows proper validation of the values because one can use xsi:type 
>in each TFIELD.
>    Put the example into XMLSpy and try putting values out of range of 
>type and validate to
>    see this in action.
>3. Allows straightforward ID/IDREF mechanism between FIELD and its values
>4. Reads into applications more rapidly.  Fills a variable before moving 
>onto another variable.
>The disadvantage:
> 1.  Harder for the human to check a record.  But, that is what software 
>is for.

================================================================================
Francois Ochsenbein       ------       Observatoire Astronomique de Strasbourg
   11, rue de l'Universite F-67000 STRASBOURG       Phone: +33-(0)390 24 24 29
Email: francois at astro.u-strasbg.fr   (France)         Fax: +33-(0)390 24 24 32
================================================================================



More information about the votable mailing list