Standardising units and formats (and ref frames?) in transmission

[Mark Taylor]

On Fri, 15 May 2009, Alberto Micol wrote:

> Standardising (unifying) units and formats will help a lot in that respect.
> And I'm glad you agreed on that too. Today others also agreed (though
> privately).
> 
> I really hope to hear more (public) voices on this (old) idea of standardising
> units and formats
> --if not even reference frames-- for the most common and relevant things that
> travels onto the wire
> (not what is presented to the Users).
> 
> That approach is less error prone (try parsing various types of
> ucds/utypes/names/ids),
> it makes client software more robust and performant, it simplifies the life of
> those astronomers
> that would want to write their own VO-based tools, and it makes the VO
> immediately
> "computer-ready" (e.g. if all angles are in radians --as per Francois' old
> idea-- the computer
> simply applies a cosine to it without having to scale; scaling is only useful
> --and due--
> on the frontend).
> 
> And nothing prevents our standards from carrying over also the original data
> in their original
> formats and units, if so required.
> 
> The approach here proposed (again) is just a transport mechanism, an
> infrastractural standard,
> nothing for humans to see, to interpret, or to be affectively attached to.
> 
> Raise your voice, yes I'm talking to you, you that are always struggling with
> those IVOA standards. Otherwise, well... you'll get what you deserve!

Alberto,

I was going to leave this to others with more expertise, but since
you ask so nicely ...

I agree that it would be very nice for data consumers if only a very few,
very well-defined units and formats ever appeared in data coming over
the wire.  But in some cases it will put a considerable burden on
data providers.  Since we do not have the power of obligation over
data providers, simply decreeing "time in VOTables will always be 
represented as ISO-8601 TT" (or whatever we come up with) will most
likely have the effect that many data providers simply fail to comply,
either providing VOTables for which this is not the case, or just
giving up on VOTables/VO-blessed data formats altogether.

In practice I think that this sort of rule does work,
and is a good thing, for protocols where the quantities in question
have protocol-specific semantics; for instance it's quite right
that the RA and Dec specified in Cone search, SIA and SSA queries, 
and in the RA/Dec columns which they return, must be ICRS in 
decimal degrees, rather than permitting any angular description
as long as it's described.  However, for situations in which 
the data is being passed through, e.g. rules for TAP responses,
or simply for what is allowed in any VOTable sitting on someone's 
disk, I don't think it's feasible (read: will not be obeyed) to
decree that only a small set of formats is permissible for certain
data types.

I'm all in favour of encouraging data providers to provide position/
time/whatever in certain standardised formats that we can decide on,
I just don't think that uptake will be 100% (or even 90%), whether
or not we call it a requirement.

Mark

-- 
Mark Taylor   Astronomical Programmer   Physics, Bristol University, UK
m.b.taylor at bris.ac.uk +44-117-928-8776 http://www.star.bris.ac.uk/~mbt/