(r5) STCInVOTable < IVOA

IVOA Web>STCInVOTable (revision 5) (raw view)~~EditAttach~~
---+ 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 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 References

Instead of having utype and ref on FIELD, put groups into the !AstroCoords group:

<verbatim>
<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>
</verbatim>

(or use FIELDrefs that, I'm told, can now take utypes as well).

---++++ Rationale:

   * Keep STC information confined to STC groups (helps libraries)
   * Don't clobber utype and ref on FIELDs to preserve them for other, 
     less generic purposes

---++++ Impact on Functionality:

As far as I can see, None.  You need one !AstroCoords group per what
set of coordinates either way. -- MD

---+++ Comment

I 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.

-- IVOA.ArnoldRots - 01 Dec 2009

---+++ Change 2: Flat systems

Just have all utype/value (belonging to one coordinate system definition)
params as direct children of the !AstroCoordSystem group.

<verbatim>
<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>
</verbatim>

---++++ Rationale

   * Flat is better than nested (try python -c 'import this').
   * The additional nesting adds no information, probably don't really 
     help implementations or humans
     on parsing and complicate writing.

---++++ Impact on Functionality

None that I can see.  Were these groups meant a service for humans? -- MD

---+++ Comment

I 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. 

-- IVOA.ArnoldRots - 01 Dec 2009

Uh -- I notice I was not particularly clear.  There is one group each for every
!AstroCoordSystem, of course.  I'm just suggesting to drop the subgroups
within (XFrame).  For the CSC example, I can't see where that would fail, and
actually, it should not in any setting, by virtue of the data model requriring
zero or one of each XFrame and the frame name being a part of the utype already.  -- MD
2009-12-02

---+++ Change 3a: Do not abuse xml namespace declarations

Don't pretend the stc: in the utype has anything to do with an XML namespace.

So, strike the xmlns:stc declaration on VOTABLE:

<verbatim>
<VOTABLE version="1.2" xmlns:xsi="http://www.w3.org/2
 xmlns="http://www.ivoa.net/xml/VOTable/v1.2">
</verbatim>

---++++ Rationale

   * While syntactically legal,  declaring namespaces that are not used within
     the document is a dangerous practice -- XML tools can and do discard 
     these.  Also, the stc in the namespace declaration has, from an XML
     point of view, nothing to do with the stc in the utype attribute value
     since that value is not declared as to hold a QName.
   * The "package name" is supposed to be the fixed thing (to keep utypes
     opaque).  This is incompatible with XML namespaces.

---++++ Impact on Functionality

The 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

---+++ Comment

I have no(t yet an) opinion on this. It does sound reasonable.

-- IVOA.ArnoldRots - 01 Dec 2009


---+++ Change 3b: Define DM Version using UCDs

In 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.

<verbatim>
<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" />
</verbatim>

---++++ Rationale

   * This provides a link to exact data model used to define the utypes
     used.
   * Some mechanism like this will be employed by the utype group.

---++++ Impact on Functionality

   * We/someone should maintain explanations for all the utypes at the
     URLs resulting from glueing together the model URI and the de-packaged
     utype.

---+++ Comment

Sounds reasonable; but you need a name and a datatype as well.

-- IVOA.ArnoldRots - 01 Dec 2009

---+++ Change 4: Only allow string values

Define that all STC PARAMs are =datatype="char" arraysize="*"=.

---++++ Rationale

   * As far as I can see, there are no very reliable serialization rules
     for param values in VOTable anyway -- MD
   * Provides the easiest way to unambiguously define the utype serialization 
     by pointing to the STC-X schema. -- MD
   * Without this, libraries have to keep a mapping from "known utypes" to 
     their types.  This is not hard, but not very nice either.  We'd
     have to derive the type/serialization rules from STC-X either way. -- MD

---++++ Impact on Functionality

   * It's much easier to pass STC info through correctly, e.g., if a tool
     only understands a subset of STC.
   * For tools knowing a certain utype, probably none; they'll have some
     custom way of de-/serializing their internal values anyway.  -- MD

---+++ Comment

I 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.

-- IVOA.ArnoldRots - 01 Dec 2009

---+++ CSC Cone Serch Examples

As 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 [[http://hea-www.cfa.harvard.edu/~arots/nvometa/STC/CSCVOTable.xml Version 1.1]] and the [[http://hea-www.cfa.harvard.edu/~arots/nvometa/STC/CSCVOTable2.xml MD-modified Version]] of the example.

-- IVOA.ArnoldRots - 01 Dec 2009

<br/>

---+++ Revision, Draft 1

I have prepared a revision of the note, and while doing so I realized that
things become quite a bit simpler if the utype-value pairs are serialized into
INFOs rather than PARAMs.  Otherwise, it more or less reflects the changes 
proposed here.  You check out the document from svn at http://svn.ari.uni-heidelberg.de/svn/gavo/stcvotable/trunk/ (read-only).  For commit privileges, contact me.

-- IVOA.MarkusDemleitner - 21 Jan 2009

<!--
      * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup
-->
Topic revision: r5 - 2010-01-21 - MarkusDemleitner
IVOA
Log in or Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Interest Groups
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema