On the "when" and "where"

[Rob Seaman]

Note that I removed all the cc's - we should use the mailing list for 
its intended purpose.

Alasdair replies:

>> Take a look at example B.4 from 
>> http://www.ivoa.net/Documents/PR/STC/STC-20050315.html
>
> I must admit to not reading the document fully, I flipped ahead to the 
> XML examples because I wanted to get a feel for the amount of work 
> needed to implement a parser/generator that would minimally comply 
> with the spec. It looks like a seriously large amount of work...
>
> How much of this is useful but optional? In the simplest possible case 
> if I just want to specify an RA, Dec and time of observation (UTC) 
> without quoting errors or defining frames. What's the simplest 
> document you can get away with?

As with most VO issues, the answer depends on the application and the 
data.  For some basic "astronomical telegram" type issues, only a very 
simple set of coordinates is needed.  The minimum is something like RA, 
Dec, Epoch, ISO Date/Time.  I would likely argue that this should be 
extended somewhat to allow for support for various alternate spherical 
coordinate systems, i.e., galactic coordinates as well as the various 
familiar equitorial systems.  Perhaps the precision of the numbers 
(sexigesimal or otherwise) could be implicit in the representation, but 
the zen of XML would certainly argue for explicit 
errors/resolution/precision/units/...

> If it can't be cut down to about 10 lines of XML for the simplest case 
> (including all the angle brackets) I think there is a problem here, 
> are there any assumptions made at all if things are left out of the 
> XML representation?

I'm a little unclear as to the motivation for keeping this so simple.  
One could argue that VOEvents represent the most serious requirements 
that VO will have for reliable delivery of coordinate information.  
After all, the issuer may be committing somebody else's observing 
resources to a new target list with minimal advance oversight.

As an aside, here is a related topic I'm copying from a message I just 
sent to Roy:

>> I also don't see anything in v0.3 regarding checksums, message 
>> digests or
>> maybe even full blown digital signatures to provide validation for an
>> event (or for the issuer).  I could imagine a spritely grad student 
>> issuing
>> a false event as a lark to see the VLA suddenly swivel toward Vega a 
>> la
>> Jodie Foster.  Perhaps this is (or ought to be) handled at a lower 
>> level
>> of VO transport?

If there is indeed a strong argument for providing the very simplest 
possible spatial/temporal coordinates within VOEvent, may I suggest a 
compromise?  Define fields similar to those already discussed in the 
v0.3 draft.  All issuers and consumers of VOEvents will (might?) be 
required to parse these fields - whether or not they make sense for a 
particular event.  For example, a VOEvent describing a solar flare 
would not benefit from supplying an RA and Dec that won't apply at any 
point after the event is issued due to the rotating Sun and orbiting 
Earth.  On the other hand, also allow a VOEvent to include an optional 
STC of whatever application specific complexity and subtlety is needed.

Only those VOEvent publishers that need the added capabilities of STC 
would use same.  (Personally, I suspect, most will see the utility and 
simply link to some standard STC library.)  A particular VOEvent 
subscriber would be permitted to simply skip over the STC, but would 
obviously then be limited in the events it could react to.  But then, 
all subscribers are inherently limited to understanding only certain 
events - only certain telescopes can safely point at the Sun to observe 
a flare, for instance.

Finally, note that a VOEvent is just a way to transport such 
coordinates.  The meaning of the coordinates may be completely opaque 
to the VOEvent publisher and subscriber.  Some other code further 
upstream from the publisher creates the STC and some other code further 
downstream from the subscriber parses it and decides what to do with 
the information once it has it.

Rob Seaman
NOAO