STC in VOTable: Time utypes

[Arnold Rots]

I don't think there is any reason not to allow multiple
AstroCoordSystems, AstroCoords, and AstroCoordAreas in the container.
I would favor shaping the container like an ObsDataLocation or
CatalogEntryLocation element.

Cheers,

  - Arnold

Francois Bonnarel wrote:
[ Charset UTF-8 unsupported, converting... ]
> Markus Demleitner a ?crit :
> > Dear VOTable and DM folks,
> >
> > On the issue of a common container I've received only positive
> > feedback, so I'll go ahead and have the next draft include that.
> >   
> Oops, I forgot to comment that point this morning.
> I am not really a fan.
> It is OK if you have only one coordinate "block" per Coord System.
> But if you have several ? What you have is all the GROUPS for the
> different "blocks" (ethen tables) accumulating at the beginning of the 
> document...
> And then you have to repeat several times the same AstroCoordSystem.
> I was happy with only a reference to the coord system in the AstroCoords
> group, which is semantically the same and let each of the AstroCoords GROUP
> in the corresponding TABLE or GROUP of FIELDS.
> 
> but if I am the only one to object I can live with this.
> 
> > Meanwhile, another issue has come up that I'd like to hear opinions
> > on: The time utypes.  Currently, they look like this:
> >
> > stc:AstroCoords.Time.TimeInstant.ISOTime or
> > stc:AstroCoords.Time.TimeInstant.JDTime.
> >
> > I've just put the following diatribe on this on the wiki page
> > (http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/STCInVOTable):
> >
> > """
> > That is bad for at least three reasons:
> >
> >    1. clients have a hard time figuring out what column a time or a time 
> >       error or whatever is (since they need to check at least three utypes)
> >    2. we have xtype in VOTable for this purpose, and having both utype 
> >       and xtype specify something then requires some rules on what to 
> >       do when the attribute contradict or if there is some inference 
> >       between them
> >    3. data models should IMHO not be concernded with serializations
> >
> > So -- what's to be done?
> >
> >    1. Keep everything as is (ugly, but probably workable; declare 
> >       clashes between utype and xtype as undefined)
> >    2. Elide ISO/JD/MJDTime by special rule (but that's yet another 
> >       special rule, and you cannot build an STC-X tree from utypes any more)
> >    3. Change STC-X (would probably take a while and might be used 
> >       to clean up some other ugly spots we have here, but it's a
> >       major undertaking that would seriously delay STC-in-VOTable)
> >    4. ???
> > """
> >
> > (at the very bottom).  Emboldend by the feedback to my last question,
> > I thought I'd ask around again for opinions and suggestions --
> > preferably on the wiki.
> >
> > Thanks,
> >
> >           Markus
> >
> >   
> 
> 
> -- 
> =====================================================================
> Fran?ois   Bonnarel           Observatoire Astronomique de Strasbourg
> CDS (Centre de donn?es        11, rue de l'Universit?
> astronomiques de Strasbourg)  F--67000 Strasbourg (France)
> 
> Tel: +33-(0)3 68 85 24 11     WWW: http://cdsweb.u-strasbg.fr/people/fb.html
> Fax: +33-(0)3 68 85 24 25     E-mail: francois.bonnarel at astro.unistra.fr
> ---------------------------------------------------------------------
> 
--------------------------------------------------------------------------
Arnold H. Rots                                Chandra X-ray Science Center
Smithsonian Astrophysical Observatory                tel:  +1 617 496 7701
60 Garden Street, MS 67                              fax:  +1 617 495 7356
Cambridge, MA 02138                             arots at head.cfa.harvard.edu
USA                                     http://hea-www.harvard.edu/~arots/
--------------------------------------------------------------------------