On the "when" and "where"

[Alasdair Allan]

Rob Seaman wrote:
> Alasdair Allan wrote:
>> 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...?
>
> Your argument isn't with me, it isn't with STC - your argument is with 
> the notion of VO having any coordinate/time standard at all.

I don't think that's the case at all.

> If VO has a standard way of representing coordinates, why wouldn't 
> VOEvent make use of it?

Certainly!

> If that standard is inappropriate for VOEvent, it likely is 
> inappropriate for other purposes and should be improved.

I would tend to agree. If developers need to construct (or parse) a 
document as complicated as the STC examples I've seen simply to pass 
the RA, Dec, epoch and equinox of an observation then I think the VO 
has a real problem.

You need simple interfaces for simple tasks, or better yet simple 
interfaces for common tasks. Passing an RA and Dec is a commonly done 
task, I agree there are added levels of subtly underlying this common 
task, but it is done so often the software dealing with an RA and Dec 
must make assumptions, a user/developer should not be forced to 
generate or parse an extremely complicated XML document to pass a 
simple RA and Dec.

Obviously, you need the complicated bits so that if the user isn't 
doing a common task then they can make use of it...

>> 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...
>
> I'd omit the word "absolute", but I agree.  VOEvent needs to support 
> the simplest possible coordinate and time format.  I would argue that 
> the way to do this is to make a VOEvent a vessel (to avoid the loaded 
> word "container") for a separate coordinate/time data structure.  I 
> would further argue that STC is that data structure, but perhaps the 
> convened big domes will deem that VOEvent has to support something 
> else simpler *in addition to* STC.

Fine, if you want to do it that way I'm happy enough with that. At that 
stage STC is entirely optional and those of us that need to do the 
common task of passing an RA, Dec and date stamp can get on with it 
without worrying about the more baroque elements involved in generating 
an STC structure.

> 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.

Fine, allow an STC structure as one *possible* way to represent the 
co-ordinate/time structure, although I'm still totally unconvinced that 
the link between co-ordinate and time structures is necessary or even 
desirable. However there *must* be a simpler way to do this, I'm happy 
for this simpler way to make some assumptions because in general you 
just won't need to specify everything. It'd be nice if this simpler way 
to represent things was a cut down version of STC, but if that isn't 
possible I think an alternative very (very) simple XML block should 
replace it.

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