STC in VOTable"> Embedding STC in VOTable
At the Garching Interop,
Markus has uttered some gripes with
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).
--
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:
LSR, LSRD, LSRK should only be allowed in spectral and redshift frames.
p. 8, table 5:
I could grumble about the IDs, but they can be reconstructed when taking the utypes and turning them into a proper
STC-X document.
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:
I just want to register my disagreement, for the record, with this definition of epoch.
p. 10, sec. 4.1:
I am not clear how that region is going to be represented in the table; wouldn't it need center and radius columns?
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:
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.
--
ArnoldRots - 19 May 2010