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