On the "when" and "where"

[Alasdair Allan]

Rob Seaman wrote:
> Alasdair Allan wrote:
>> 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.

Ease of implementation and keeping the learning curve as shallow as 
possible...

Large and all encompassing specifications are all well and good but if 
nobody uses them because it's too much effort to implement them then 
you have a problem. If you can code up a partial implementation that 
covers 90% of the common cases simply for about 5% of the effort, then 
you're likely to use the specification. If you need everything 
including the kitchen sink form the word go, that's a different matter 
and people are just likely to ignore the entire thing.

The web (and especially grid) service world is riddled with 
specifications that people ignore totally because it's just too much 
effort to code the thing up correctly. Lets try and not make that 
mistake.

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

Perhaps, but that's why it needs to have a simple case where things are 
assumed if absent. If we make sensible assumptions we can fill in the 
holes from poorly implemented libraries, we need to be able to make 
"good enough" and "best guess" pointings.

This is pretty much how the web works, almost no web pages actually 
parse correctly using a strict HTML parser, yet the browsers render 
them pretty much okay because they make assumptions about what was 
meant.

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

This should be handled elsewhere. It isn't part of VOEvent and is 
covered by the VO's SSO implementation (see the current discussions 
ongoing on the IVOA Grid Mailing List).

> If there is indeed a strong argument for providing the very simplest 
> possible spatial/temporal coordinates within VOEvent, may I suggest a 
> compromise?

Compromises are good...

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

Sorry, I don't understand the above.

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

Yes, so you (obviously) don't supply an RA or Dec. This is a case where 
defining the original frame of an observation is necessary. In most 
cases (non-solar) you'll probably just want to publish and RA, Dec and 
time stamp, at least initially.

> On the other hand, also allow a VOEvent to include an optional STC of 
> whatever application specific complexity and subtlety is needed.

I don't really have a problem with this...

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

Are there any? I know Dave Berry is implementing STC inside the 
Starlink AST library, is anyone else working on reference 
implementations? What languages will STC be available for out of the 
box?

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

Right, my point exactly...

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?

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

Possibly, possibly not. I don't see how this would work in practice.

In practice the person "publishing" the VOEvent document will almost 
certainly be the observing facility, in which case they have to 
generate it. Anyone consuming the document will want to know where and 
when the event is, if not, why bother looking at it? Unless you're just 
archiving it of course, but that's a very specific special case.

Al.