TAP RFC [xtype]

[Francois Ochsenbein]

Hi Pat,

Oh no, you can't call the stc production a 'datatype' --
or we don't share the same vocabulary ! Everything could
then be called a 'datatype' ! What's the difference with
e.g. the characterisation definitions ?

I would definitvely prefer, as far as datatypes are
concerned, simple names without a 'stc:' or 'adql:' or
whatever prefix; after all, such definitions are also
knwon to PQL, and 'TIMESTAMP' datatype is present everywhere.
What matters however for POINT and REGION, is that these
refer to the trigo sphere, and not to a usual (cartesian)
2-D plane.

It becomes urgent to finalize this point.

--Francois

>
>On Friday 18 September 2009 06:43:13 Francois Ochsenbein wrote:
>> Hi Pat,
>>
>> I'm afraid that you see the 'xtype' as a duplication of the 'utype'.
>> The introduction of the 'xtype' at the Interop this spring was
>> motivated by the necessity of qualifying the datatypes existing
>> in DBMS and necessary to TAP but which are not known in VOTable's
>> 'datatype'; the 'utype' already makes the connection with stc,
>> as Markus pointed out.
>
>I do not think utype makes this connection. If my database is contains 
>metadata for observations (eg the obs-tap project) then the utypes will be 
>from the obs model, not STC. IMO, the whole problem with STC is that people 
>talk about it as a data model when it is really a data type system that can be 
>used in a model. It would be trivial to have a model with multiple uses of the 
>same STC data types, making the model utypes meaningful and the stc utypes 
>ambiguous. Anyway, that's treading into religious data modelling philosophy 
>:-)
>
>OK, let's forget about stc as usable data types in this context.
>
>> The 'xtype' is therefore here to qualify the pieces which may
>> be used in a table or in an ADQL query and are not described by
>> a 'datatype' (datatype cannot be changed being tighthened to FITS).
>> For such an 'extended' datatype, the VOTable 'datatype' would
>> quite generally be 'char'.
>
>My intent is to specify an unambigiuous mapping from VOTable <-> database 
>table, meaning in this case data type as used in the VOTable <-> ADQL 
>datatype. ADQL provides 3 types that are not covered by datatype in FIELD: 
>TIMESTAMP, POINT, REGION. So, clearly we need 3 xtype values. My examples were 
>intended to show how other standard FIELD attributes fall into place to 
>describe the content of table cells more clearly.
>
>Current spec says these 3 are adql:TIMESTAMP, adql:POINT, adql:REGION and 
>VODataService specifically allows these as column types when describing a 
>table. I personally am happy with this usage and consistency and I don't think 
>VOTable 1.2 spec is saying I cannot make up such xtypes.
>
> I was trying to explore whether one could use datatypes from STC instead as 
>this may mean that VOTables from footprint services, for example, could be 
>uploaded to TAP. It sounds like that is not worth it at this point.
>
>So, the way I see using xtypes in TAP is as follows:
>
>TIMESTAMP: datatype="char" arraysize="*" xtype="adql:TIMESTAMP" and content is 
>in the iso8601 format, UTC only. The arraysize above is the lazy way; one 
>could specify fixed values if that was applicable (eg all had only dates or all 
>had dates and times to same precision).
>
>POINT: datatype="double" arraysize="2" xtype="adql:POINT" and content is a 
>pair of numeric values. The coordinate system is specified via a ref attribute.
>
>REGION: datatype="char" arraysize="*" xtype="adql:REGION" and content is an 
>STC-S string.
>
>If we go this way for POINT, we also have to require a ref attribute to 
>specify a (common) coordinate system (since, iirc the coordsys attribute was 
>deprecated/removed). REGION does not technically need that as the coordinate 
>system is embedded (repeated) in the STC-S strings. It would be nice to have 
>one and make the STC-S strings shorter, but STC-S specifies default values that 
>are explicit so I don't think that is actually legal... so a ref attribute 
>with REGION would be optional/redundant.
>
>> We agreed at the meeting that date/time would be named 'iso8601'
>> and 'STC-S'. That's what I reported in VOTable1.2-PR, but then
>
>We (well, I was in GWS but my understanding is) that these convenient 
>constants could be globally useful, but it does not limit a specific app's use 
>of VOTable to only those values. TAP needs 3 values and thuis has to specify 
>it's own. Is that not correct? Does the VOTable 1.2 schema actually restrict 
>the values? I have made a comment about this on the VOTable RFC page.
>
>I think the whole concept of "external type" implies that other apps/specs 
>define the allowed values.
>
>OK?
>
>-- 
>
>Patrick Dowler
>Tel/Tél: (250) 363-0044
>Canadian Astronomy Data Centre
>National Research Council Canada
>5071 West Saanich Road
>Victoria, BC V9E 2M7
>
>Centre canadien de donnees astronomiques
>Conseil national de recherches Canada
>5071, chemin West Saanich
>Victoria (C.-B.) V9E 2M7
=======================================================================
Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
   11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)368 85 24 29
Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)368 85 24 17
=======================================================================