Wide or Narrow Schema for VOEvent?

[Alasdair Allan]

Rob Seaman wrote:
> First (and I suspect Arnold would agree), the positional information 
> is integrally tied to the temporal and spectral information and to 
> derivatives of same.

I fundamentally disagree.

While in many cases the information will be provided together there is 
nothing to say that an event must contain a time, or any spectral 
information as well as a position. Or conversely it needs to contain 
any spacial information in addition to a time. None of these things are 
fundamentally tied together for event notification.

> This is the message of STC, but is also the message of VOEvent, as 
> well, precisely because a single event exists to tie together the 
> what, where and when (as well as the who and how).  We don't have the 
> freedom to make the positional information narrow or wide 
> independently from the the temporal or spectral/bandpass information.

Yes, we do.

>  It is most certainly true that creators of astronomical events might 
> want to:  "use galactic coordinates, or Jovicentric coordinates, or 
> coordinates in equinox B1870.0, or Martian longitude/latitude" and 
> many other options besides.

Certainly, but they should not be forced to have to parse or generate 
overly complex messages just because some people want to do the above.

> 1) The VOEvent standard is required to support a "wide" range of 
> coordinate types.  STC is a good place to begin to sort this out.

Depending on what you mean by "support" I would agree. However I would 
suggest that STC is one of several possible starting places, and 
wouldn't have been my initial choice.

> 2) A particular VOEvent is required to be straightforward to construct 
> and interpret (assuming we actually want the standard to be 
> implemented and used in operational systems).

This I would certainly agree with!

> The distinction between these two perceived extremes is only that any 
> standard must be just flexible enough to support the actual needs of 
> its users.  To achieve this, I assert that a VOEvent should be a 
> delivery vehicle for some payload similar enough to STC for the 
> distinction not to matter.  The delivery vehicle will attend to 
> identification, authorization, classification and other administrative 
> needs.  The payload will deliver the science.  It may *also* be true 
> that the vehicle might directly convey a simplified (to the point of 
> non-utility in some cases) representation of the payload (such as RA, 
> Dec, Equinox, Epoch with coordinate frame and timescale defaults) - 
> but the requirement for this has not been made clear (to me, anyway).

It is certainly clear to me, and to several other people, the way 
around this is obviously to make things optional. For instance VOTable 
has several different mechanisms for encoding tabular data, a simple 
TABLE element, Base 64 encoded data and pointers to FITS Binary Table 
data.

Why don't we do something similar for VOEvent. The schema can support 
encoding of co-ordinate information via several methods. One of these 
could be STC if that is deemed necessary by everyone. However I feel 
very strongly that some simpler representation will also be necessary.

> In any event, I imagine Roy's intent with casting the choice between 
> the extremes of "very narrow" and "very wide" was to suggest that we 
> seek a compromise one-size-fits-all, sans-a-belt solution (with a 
> "skosh more room" :-)

See above.

Al.