STCInVOTable < IVOA

---+ Embedding STC in VOTable

At the Garching Interop, [[http://www.ivoa.net/internal/IVOA/InterOpNov2009DM/stcvotable-demleitner.pdf][Markus has uttered some gripes]] with [[http://www.ivoa.net/Documents/Notes/VOTableSTC/NOTE-VOTableSTC-1.1-20090612.pdf][version 1.1-20090612 of the STC in VOTable Note]] specifying how to embed STC in VOTables.

There's been quite a bit of work going on since then; older items have been 
moved to STCInVOTableArchive, which doesn't necessarily mean the issues are
settled; if something discussed there still bugs you, feel free to resurrect 
it here.

---++ Draft of 2010-04-20

I've put up a new draft at 
http://vo.ari.uni-heidelberg.de/docs/note_stc_20100420.pdf.  This is basically
a rewrite (while, I believe, maintaining the spirit of the old note).  Below,
I've opened up Level 3 discussion spaces for what I believe a the most 
sweeping changes against the ''previous draft'' (not the current version
of the note; see STCInVOTableArchive for the other changes).

-- IVOA.MarkusDemleitner - 20 Apr 2010

---+++ Change: One group

MD: Rather than having one !AstroCoordSystem and one !AstroCoord group per 
system, all utypes dealing with one coordinate system is now contained in one 
group of (typically) utype stc:ObservationLocation.  While this means you
can no longer re-use coordinate system definitions within a VOTable, I believe
the advantages in implementation simplicity far outweigh this drawback.

---+++ Change: !AbsoluteTime substitution group gets yet another special treatment

MD: STC-X unfortunately has the !AbsoluteTime substituion group that gives
what in VOTable is xtype's job (and even if that weren't so, having
serialization details in utypes is a pain anyway).  So, a new special rule
was inserted into the utype generation algorithm to divert ISOTime, JDTime and 
MJDTime into some special utype, and there's a recommendation to drop that
particular utype.  Nasty special-casing all over the place, but all
alternatives (some of which are discussed in STCInVOTableArchive, search
for xtype) seemed worse to me.

---+++ Change: !DataModel.URI

MD: Many people want some versioning of the data models, preferably
connecting data models to URLs.  After some consultation with Mireille,
I propose to transmit this URL in !DataModel.URI.  It doesn't help to
make instance documents much prettier but is IMHO a rather non-invasive
method of making explicit what data model was used.

---+++ Comments
I have a few residual comments:

p. 6, table 3:<br>
LSR, LSRD, LSRK should only be allowed in spectral and redshift frames.

p. 8, table 5:<br>
I could grumble about the IDs, but they can be reconstructed when taking the utypes and turning them into a proper STC-X document.<br>
However, the units are a bit more problematic. I'll grant you that there could be conflicts arising, but banning them makes it very hard to reconstruct the STC-X version.

p. 10, top:<br>
I just want to register my disagreement, for the record, with this definition of epoch.

p. 10, sec. 4.1:<br>
I am not clear how that region is going to be represented in the table; wouldn't it need center and radius columns?<br>
However, it raises another issue that we probably should have addressed: how to represent STC-S strings. The nice thing about them is that they are fully self-contained. Should they be string columns that have an xtype="stc:STCS", for instance?

p. 11, end of sec. 4.2:<br>
I'm not enamored of the name "Ephem"; why not Time or ISOTime?
And I would suggest that xtype="stc:ISOTime" might be more fitting.

-- IVOA.ArnoldRots - 19 May 2010 

<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Attachments
Topic attachments
I	Attachment	History	Action	Size	Date	Who	Comment
ext	STC-UsedinObservation	r1	manage	3.3 K	2010-04-29 - 20:20	MireilleLouys	STC Utype re-used in Obs Core Data Model
This topic: IVOA > STCInVOTable
Topic revision: r23 - 2010-05-19 - ArnoldRots