Dear All,
A couple of comments/questions regarding the three proposed solutions to support STC in a votable.
From a human point of view, it is nice to see grouped together all the "characterisation" information as in Arnold's option 3.
But I think we should think of the usage of such a VOTable; the main aspect is not philosophical or aesthetic satisfaction, but a more pragmatic "how the heck will my parser understand what is written there"? :-)
It is a pity that the examples 2 and 3 do not show UCDs. Is that done on purpose? That is, a VOTable parse should really rely on the utypes to get to know what a field is?
That, I think, would be particularly bad. Not only too many ucd-based parsers are already around, but it will be particularly difficult to put together a parser based merely on utypes.
Let me comment on the three options, in reverse order.
OPTION 3:
How would a parser know that Field Err2:
<FIELD ID="Err2" name="DEC_Error" datatype="float" unit="arcsec" utype="stc:AstroCoords.Position2D.Error2.C2" ref="TT-ICRS-WAVELENGTH- TOPO"/> refers to the Group utype="stc:AstroCoordSystem.SpaceFrame" and not to the Group utype="stc:AstroCoordSystem.TimeFrame" ?
An STC aware parse might be able to find that out, but I'm not sure that we need to have STC-aware parsers to just make sense of a simple VOTable.
OPTION 2:
Option 2 makes clearer (read: easier to parse) which field relates
to which STC group.
Still, UCDs are missing. We need them, at least for backward
compatibility.
I find nice the reference from the FIELD to the GROUP.
OPTION 1:
Here there are UCDs; good.
The Observing Time field is not mentioned in the GROUP (typo?).
I find quite nice (read: esay to parse) the FIELDref mechanism; I guess a parser will keep this in memory, and will easily recognise the fields later, and without extra effort will be able to manage them.
Other options?
Why the double reference was not proposed?
That is, to have both FIELDrefs in the group, and the refs in the
FIELDs?
I think that would be useful, and leave more freedom to the parser
implementors.
Suppose that I do a cross match of two catalogs: I will end up with 2 coordinate systems in my votable. In this case option 3 does not allow much flexibility:
if the spectral frame is different but not the spatial one, one will have anyway to duplicate the spatial frame info.
My preference would go for option 1, because of the FIELDref, and of
the UCDs.
Option 2 could do too, but with UCDs please.
Double reference possible/useful?
Thanks,
Alberto Received on 2006-09-20Z15:01:37