STC in VOTable"> Embedding STC in VOTable

At 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 References

Instead 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:

• 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

Change 2: Flat systems

Just 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

• 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

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:

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

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

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.

<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

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

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