Wide or Narrow Schema for VOEvent?

[Rob Seaman]

Alasdair Allan says:

> I would suggest that STC is one of several possible starting places, 
> and wouldn't have been my initial choice.

Ok - I'll cheerfully admit my ignorance of these several alternatives.  
What would your initial choice have been?

> your current schema doesn't allow such information to be "assumed", 
> you've specifically said that your XML representation doesn't let you 
> make things optional.

Time or spectrum or even positional metadata are (each and severally) 
optional.  It is, of course, always an option to omit the entire STC...

...however, if you choose to use a TimeFrame, for instance, you have to 
include both a ReferencePosition and a TimeScale.  Why?  Because 
neither makes coherent sense without the other.  Further, there is no 
default ReferencePosition because none makes sense for more than a 
small fraction of useful specifications.  (I'm sure Arnold will correct 
me if I misspeak.)

Whether or not STC is used, these seem like fundamental statements 
about accurately specifying astronomical events.

Note an alternate strategy (again, independent of STC) to the notion of 
relying on allowing different classes of information to be optional for 
types of events that don't require same:  construct and maintain an 
explicit list of supported event types.  Each type would be tightly 
constrained with specifically required fields.  A non-moving point 
source would require celestial coordinates (+ frame) together with a 
time (+timescale), but even then we'd likely have a robust discussion 
about observatory coordinates.  This might, however, be a good 
conversation to have since it would point out the complexities inherent 
in even the overtly simple examples.

Without more analysis, it isn't clear (to me) whether to prefer a 
single, relatively more complex, event specification over a list of 
separate, relatively more simple, type-specific events.

Rob Seaman
NOAO