On the "when" and "where"

[Alasdair Allan]

Rob Seaman wrote:
> Alasdair Allan wrote:
>> Why add the burden of having to implement a parser for a full blown 
>> STC spec, a lot of which is irrelevant to your telescope. My ground 
>> based optical telescope doesn't need to know how work out the 
>> co-ordinate frame translations to observe a solar flare, so why 
>> should I be forced to implement this?
>
> Why would VOEvent, per se, have to implement this parser at either end?

Err, it's not VOEvent that has to implement a parser for STC. It's me, 
the poor downtrodden developer, who has to implement one because I want 
my code to be able to send or interpret  VOEvent documents. If you 
create a VOEvent document which embeds an STC document you have to have 
a parser for STC to be able to do so, err, I'm really not sure what 
you're on about here...

> One could make the case that VOEvent doesn't need to know anything 
> about coordinates or time, at all - beyond the utility of a transport 
> timestamp perhaps.

Pardon? If you embed an STC structure inside an VOEvent document, a 
parser developed to read and write VOEvent documents also has to 
understand STC documents. If you want to handle a VOEvent document you 
need a parser, I don't understand what your argument is here...?

> The users of VOEvent will need to understand enough about this issue 
> for the purposes of their class of events.  Perhaps a simple RA, Dec, 
> Frame (with implicit epoch), and UTC (with real civil time issues 
> brewing) would be enough for a particular project.  Another project 
> might require highly precise and esoteric coordinates.  It seems to me 
> that an abstraction like STC is precisely how you support such a range 
> of users.

Possibly, but if it makes too many demands on the developers it won't 
get used. People won't implement it fully, you'll end up with 
conflicting partial implementations  of VOEvent that dont't 
interoperate and it won't get taken up. We need an absolute minimal buy 
in here...

Al.