Summary: features for VOEvent v2.0

[Rob Seaman]

Howdy,

We have received 13 responses (see below) to the straw poll for  
features for v2.0.  Not a bad response rate as such things go.

A few expressed concern that the intent of the exercise was design by  
committee.  Rather, I was interested in a reality check versus  
features we have long been discussing.  This was meant to be an  
exploration of the problem-space, not trading possible solutions back- 
and-forth.  I was, however, very glad to see the side discussions that  
have been triggered.

Here is what I get out of this exercise in consensus.  I viewed the  
questions as residing in a half-a-dozen bins as grouped at the bottom:

	A) Is there a project at all?  Consensus: Yes.  That being the case,  
the WG needs to push through to the finish.

	B) Will support be added for series data?  Yes.  Note that time- 
series was the only question for which nobody claimed to "not care".   
I believe that some of the four "no" votes are rather "yes" votes with  
the intent that time-series be represented as general tables.  I have  
suggested that support include both simple time-series per  
dotastro.org and a separate (simple) table format.  Undoubtedly we  
will have rousing discussions.  Both/either of these will be added as  
subelements to <What>.

	C) Orbital elements and/or ephemerides are needed to support moving  
object workflows in the looming synoptic surveys, as well as general  
MPC-compliant usage.  These provide targeting coordinates for follow- 
up observations and thus belong in <WhereWhen>.  Not every project  
needs these features.  Those that do, need them a lot.  VOEvent client  
applications that are unrelated to moving objects (or time series/ 
tables, for that matter) should simply omit these elements.

	D) Tweaks to the VOEvent schema.  The general goal is to retain  
backwards compatibility to v1.1.  There appears to be significant  
confusion about what these features are and why they may be needed.   
The first step is for advocates to explain the intent.

	E) Making VOEvent more robust.  A top priority of v2.0 is a battle- 
hardened schema.  This may or may not require simplifying the way  
STC's ObsDataLocation is used in <WhereWhen>.  It is my reading of the  
STC recommendation, for instance, that ObsDataLocation already  
supports orbital elements and ephemerides.  VOEvent v1.1 referencing  
STC most certainly does not in practice.  In general, many legal  
variations of ObsDataLocation are not supported.  What to do?  Well,  
first we decide to do *something*.  Then we decide what it is.  (Also,  
recall the elementFormDefault="unqualified" issue.)  Suggestions?

	F) Providing a system for managing diverse types of VOEvent packets.   
In the VO that is accomplished through resource discovery in the  
registry.  The lack of consensus with this question likely indicates  
that it is not directly connected to v2.0.  It has been suggested that  
this may be addressed via VOEventStream definition files that are  
legal VOEvent packets (or as with schema definition files, may be  
something else).  There are other non-v2.0 projects, with SEAP being  
perhaps the most notable.  Let's press forward on all fronts, but v2.0  
is the top priority.

Rob
--

(View with fixed width font):

1) VOEvent v2.0:       (10) yes  ( ) no  (3) don't care  ( ) don't  
understand
	1a) called v1.2:(4) yes  (1) no  (7) don't care  (1) don't understand

2) time-series:         (9) yes  (4) no  ( ) don't care  ( ) don't  
understand
3) simple tables:       (6) yes  (6) no  (1) don't care  ( ) don't  
understand

4) orbital elements:    (6) yes  (2) no  (4) don't care  (1) don't  
understand
	4a) ephemerides:(4) yes  (1) no  (7) don't care  (1) don't understand

5) <reference> typing:  (3) yes  ( ) no  (9) don't care  (1) don't  
understand
6) <param> typing:      (5) yes  ( ) no  (8) don't care  ( ) don't  
understand
7) non-empty params:    (7) yes  (2) no  (3) don't care  (1) don't  
understand
	7a) references: (7) yes  (2) no  (2) don't care  (2) don't understand
	7b) descripts:  (7) yes  (2) no  (2) don't care  (2) don't understand
	7c) multi-line: (3) yes  (3) no  (4) don't care  (3) don't understand
8) physical inferences  (6) yes  ( ) no  (5) don't care  (2) don't  
understand

9) simple STC:          (7) yes  ( ) no  (4) don't care  (2) don't  
understand
10) robust schema:     (12) yes  ( ) no  (1) don't care  ( ) don't  
understand

11) Stream template:    (5) yes  (2) no  (4) don't care  (2) don't  
understand

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