content, format, ctype, or xtype ?

[Tom McGlynn]

I think Francois did a great job in summarizing the situation and 
crystallizing the choices.

Here are my thoughts on this issue:

1. We should do something that is consistent with the current VOTable 
standard.  We should not define a new datatype.  We should not define a 
new attribute in FIELD.  We should only break the standard if we have 
to.  This excludes a1 and a2.

2. We could require that times be specified in a specific format (MJD?) 
but this will require that data providers modify existing tables.  So A0 
is less desirable.  This is barely feasible if we are concerned only 
with time and positions.  If we go to mandate standardization of fluxes, 
magnitudes, ... as Alberto has suggested the uptake will be nil.

3. UCDs were intended, as I recall, to define the semantics of the 
column, not it's representation.  E.g., two columns which differ only in 
that one has an ISO representation of a time and the other has an MJD 
should have exactly the same UCD.  However it's at least unlikely to 
break any existing code if we add something here.  So A4 is feasible but 
undesirable.

4. To me UTYPEs describe the usage of data in a given context, not the 
intrinsic content and certainly not the internal representation. The 
fact that there is only a single UTYPE for a given field (at least 
conveniently) suggests that UTYPEs should not be used here.  Even more 
than with UCDs the violates the idea of what the string is for.  I would 
say that STC strings should be strings
(or alas CHAR arrays) with a UCD that describes them as being a region. 
  Personally I think that the UTYPE should be more specific.  E.g., is 
it the field of view of the observation, a background region, an 
excluded region, ...  while the UCD says only that it's a region.

5. This isn't exactly a unit, but extending the Unit attribute to 
include say 'H:M:S' 'D:M:S', 'Y-M-D' and 'Y-M-DTH:M:S' as special valid 
strings  eems a change that is unlikely to break other code.  Of the 
alternatives this seems least problematic to me.  Since the units of the 
various elements of the string is implicit in these specification, the 
field is at least doing something of what it was designed to do.  If we 
include sexagesimal coordinates, then the question of the separators 
needs to be included as well as whether things like 10:20.5 are legal.

6. Using the precision attribute might be possible.  This might make 
some sense in distinguishing dates and datetimes, but it may break code
(which anticipates it ending with a number) unless we define something 
method.  E.g., precision='d1' is just a date.  precision='d2' is a 
date/time.

So to me alternatives a5, a4 and a0 seem acceptable in that order.  I 
think a1-3 would be wrong.  Only sexagesimal times and perhaps positions 
should be addressed here.

Were A5 adopted, then
   - The datatype should be char.
   - The precision should be given as if times were in days or positions 
in degrees (but normally I'd expect precision to be empty).
   - ucd,utype should be identical to what they would be if the data 
were stored in a double


Just my thoughts.
	Tom



> (a) Do we need a new attribute to specify an ISO-8601-formatted time ?
>     The possible answers are:
>     (a0) No, restrict the expression of time to JD or MJD or ... number
>     (a1) Yes, a new attribute is required (which name ? which content?)
>     (a2) No, use a new datatype (equivalent to 'char' as far as the
>              data storage is concerned, with an arraysize reflecting
> 	     the accuracy, i.e. '19' for full date YYYY-MM-DDThh:mm:ss)
>     (a3) No, use a utype related to the STC data model
>              (e.g. utype='stc:AstroCoords.Time.TimeInstant.ISOTime')
>     (a4) No, use a UCD (e.g. ucd='time.iso8601'; could be secondary
>              e.g.  ucd='time.release;time.iso8601')
>     (a5) No, use a special unit (e.g. unit='"iso8601"')
>          
> (b) Except if (a0) is decided, how should the other field attributes 
>     be filled:
>     -- which datatype: only char 
>        (remember, VOTable may convey FITS or binary data...)
>     -- which units ? must be empty ?
>     -- ucd / utype ?
>     -- precision ?
> 
> Should we envisage a vote to achieve a final decision ?
> 
> --Francois
> =======================================================================
> Francois Ochsenbein    ------   Observatoire Astronomique de Strasbourg
>    11, rue de l'Universite 67000 STRASBOURG  Phone: +33-(0)390 24 24 29
> Email: francois at astro.u-strasbg.fr (France)    Fax: +33-(0)390 24 24 17
> =======================================================================
>