STC in VOTable"> Embedding STC in VOTableAt the Garching Interop, Markus has uttered some gripes with version 1.1-20090612 of the Note specifying how to embed STC in VOTables. He's volunteered to work on the note to fix what he thinks is broken. This page is intended as a discussion space for the proposed changes (and possibly others as well). Please give every suggested change a level-3 heading.Change 1: Reverse ReferencesInstead of having utype and ref on FIELD, put groups into the AstroCoords group:<GROUP ID="lltoush_coo" ref="lltoush" utype="stc:AstroCoords"> <GROUP ref="alpha" utype="stc:AstroCoords.Position2D.Value2.C1" /> <GROUP ref="rv" utype="stc:AstroCoords.Redshift.Value" /> </GROUP>(or use FIELDrefs that, I'm told, can now take utypes as well). Rationale:
Impact on Functionality:As far as I can see, None. You need one AstroCoords group per what set of coordinates either way. -- MD | ||||||||
Added: | ||||||||
> > | CommentI agree with this proposed change. As a matter of fact, it is the way STC was intended to function in VOTable (albeit as an imported schema, not through utypes). See the examples I post at the bottom of the page. -- ArnoldRots - 01 Dec 2009 | |||||||
Change 2: Flat systemsJust have all utype/value params as direct children of the AstroCoordSystem group.<GROUP ID="lltoush" utype="stc:AstroCoordSystem"> <PARAM arraysize="*" datatype="char" value="VELOCITY" utype="stc:AstroCoordSystem.RedshiftFrame.value_type" /> <PARAM arraysize="*" datatype="char" value="ICRS" utype="stc:AstroCoordSystem.SpaceFrame.CoordRefFrame" /> </GROUP> Rationale
Impact on FunctionalityNone that I can see. Were these groups meant a service for humans? -- MD | ||||||||
Added: | ||||||||
> > | CommentI don't think this will work, except for the simplest tables.It does not allow for multiple coordinate systems, reusing coordinate systems, or using elements that contain AstroCoordSystem elements. See the CSC example that I will be posting at the bottom of the page. -- ArnoldRots - 01 Dec 2009 | |||||||
Change 3a: Do not abuse xml namespace declarationsDon't pretend the stc: in the utype has anything to do with an XML namespace. So, strike the xmlns:stc declaration on VOTABLE:<VOTABLE version="1.2" xmlns:xsi="http://www.w3.org/2 xmlns="http://www.ivoa.net/xml/VOTable/v1.2"> Rationale
Impact on FunctionalityThe VOTable has no way to define which version of the STC data model the utypes refer to. I would say this is desirable since versioned meanings will lead to hell either way, but see Change 3b for a fix. -- MD | ||||||||
Added: | ||||||||
> > | CommentI have no(t yet an) opinion on this. It does sound reasonable. -- ArnoldRots - 01 Dec 2009 | |||||||
Change 3b: Define DM Version using UCDsIn every AstroCoordSystem group, declare what version of the DM you are using. We may make that optional or a strong recommendation or something like that. The version of the AstroCoords group would be implied via its ref.<GROUP ID="lltoush" utype="stc:AstroCoordSystem"> <PARAM utype="stc:" value="http://.../stc-v1.30#"/> <PARAM arraysize="*" datatype="char" value="VELOCITY" utype="stc:AstroCoordSystem.RedshiftFrame.value_type" /> Rationale
Impact on Functionality
| ||||||||
Added: | ||||||||
> > | Comment | |||||||
Added: | ||||||||
> > | Sounds reasonable; but you need a name and a datatype as well. -- ArnoldRots - 01 Dec 2009 | |||||||
Change 4: Only allow string valuesDefine that all STC PARAMs aredatatype="char" arraysize="*" .
Rationale
Impact on Functionality | ||||||||
Added: | ||||||||
> > | CommentI haven't thought about the repercussions of this, yet. On the face of it, it sounds not unreasonable, but on the other hand, since the data type has to be given as a parameter, I don't see allowing more data types as much of a complication. I only wish that PARAM were more reasonable in the types it allows - particularly 'string' would be useful - and, of course, ISO-8601. -- ArnoldRots - 01 Dec 2009CSC Cone Serch ExamplesAs it so happened, I had recently prepared the STC-specific stuff for a VOTable 1.1/1.2 that presents data returned by a simple cone search query to the Chandra Source Catalog. Then I modified that one to comply with Changes 1 and 3 above. There is nothing like a real life example to bring out the problems I think it shows what is problematic about Change 2. Here are the Version 1.1 and the MD-modified Version of the example. -- ArnoldRots - 01 Dec 2009 | |||||||
<--
|