Difference: STCInVOTable (22 vs. 23)

Revision 232010-05-19 - ArnoldRots

 

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.

Added:
>
>

Comments

I have a few residual comments:
 
Added:
>
>
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

 
<--  
-->

META FILEATTACHMENT attr="" comment="STC Utype re-used in Obs Core Data Model" date="1272572455" name="STC-UsedinObservation" path="STC-UsedinObservation" size="3331" user="MireilleLouys" version="1.1"
 
This site is powered by the TWiki collaboration platform Powered by Perl This site is powered by the TWiki collaboration platformCopyright © 2008-2024 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki? Send feedback