features for VOEvent v2.0

[Rob Seaman]

Hi Lynne,

> One question - how is the line drawn to decide whether it is better  
> to have a param where users go look up the definition of the param  
> vs. having an official XML tag for a value? (sorry if that is a  
> silly question .. I have a feeling that is actually what all the  
> discussion is about, but I don't know what goes into weighing that  
> decision - is it how often users will need to access the value in  
> software or is it something like standardized definitions exist so  
> should be used?)

As you say, this is the art in designing such a standard.  As a  
general statement, a well defined and stable community-wide data  
structure should be expressed as a specifically crafted element, while  
params are for classes of data that vary from mission to mission,  
survey to survey, publisher to publisher.

The poll that is circulating is non-specific about the implementation,  
but I currently see a significant majority for orbital elements and a  
run-off between yes and "don't care" for ephemerides.  You might  
register your own opinion to tip the balance your way :-)

To demur from Matthew's reply: orbital elements and ephemerides are  
explicitly for targeting future observations.  As such they belong in  
<WhereWhen>, which does not support <Params>.  My reading of STC is  
that orbital elements (at least) are already legal in an  
ObsDataLocation, and thus arguably in <WhereWhen>:

	3.4) "...the <WhereWhen> element may reference an arbitrary number of  
STC [18] <ObsDataLocation> elements..."

This then raises the issue of questions 9 and 10.  Is a completely  
unbounded ObsDataLocation too complex for the VOEvent schema?

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20100407/ec4677a8/attachment-0001.html>