On the "when" and "where"

[Alasdair Allan]

Paul Price wrote:
> Rob Seaman wrote:
>> Again, either VOEvent supports a rich enough set of coordinate/time
>> representations to convey all possible astronomical events - or 
>> VOEvent
>> should be explicitly limited to only a pre-specified list of event
>> types.  We can't have it both ways.
>
> I agree that VOEvent needs to support a variety of coordinate/time
> representations in order to cover all foreseeable events.  However, at
> the same time, if the standard is too complex, you increase the
> probability that implementations will be incorrect (e.g., a user
> specifying UTC when he really meant UT1 or TAI; or J2000 instead of 
> ICRS
> --- the list of such subtle differences is near endless, and not every
> astronomer knows what they all are).  Furthermore, the greater the
> complexity, the greater will be the unwillingness of event providers to
> invest in VOEvent when they can quite easily make up their own standard
> that suits their own needs.

Absolutely!

> Might I suggest that the balance between these two philosophies
> (maximalist/minimalist) could be reached by clearly specifying a set of
> general default values.  For example, if a provider has RA, DEC and
> DATE-OBS and wants to construct a VOEvent without mucking around, he
> could stick them in, and everyone would understand that he's talking,
> say, an ICRS position and a UTC time.  Then, if another provider wants
> to refer to an event occurring at some latitude and longitude on Io at
> some particular Solar System barycentric time, he still has the
> capability with which to do so.
>
> Forgive me if I'm naively wading in where you've been before.

Again, I'm perfectly happy with this, if the simple version of the 
co-ordinate representation can be a cut-down STC that would be good. 
That means less development, as those of us without and STC parser can 
construct a simple one, and add in the complicated bits in stages, 
while those of you with existing STC parsers can add in some logic to 
parse the cut-down documents and insert the assumed knowledge.

Neither of these things is as hard as having to write and STC parser 
from scratch...

Please bear in mind that you CAN NOT assume that people will use the 
reference implementation of the STC parser as we have to operate in a 
language neutral way.

You can't assume people are using C or Java, and you can't assume a 
willingness of VO (or external) developers to implement such a major 
chunk of  code as an STC parser looks to be just to use VOEvent. Sorry, 
I think that this is an unacceptably high buy-in.

Could you post a link to the reference implementation by the way? I'd 
like to start pushing around STC documents and see how hard this is 
really going to be...

Al.
-- 
Dr. A. Allan, School of Physics, University of Exeter