VOTable session @ Interop.Moscow

[Alberto Micol]

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