back to work

[Rob Seaman]

Howdy,

With the VOEvent II workshop approaching (http://ivoa.net/twiki/bin/ 
view/IVOA/VoeventWorkshop2), I propose we revisit some of the open  
questions with the goal of reaching a consensus position that can be  
confirmed at the workshop.  Here are my opinions on a few issues.   
I'm confident you will make divergent opinions known, and will toss  
out your own views of other pressing VOEvent questions.  Roughly in  
descending priority:

1) <WhereWhen>
     I like STCLite and suggest we simply adopt it as it stands.

2) VOConcepts (for <What> and <Why>)
     The UCD specification states:  "The use of namespaces, indicated  
by the presence of a colon in the word, is possible..."  Use of such  
is dissuaded, but I think the list of VOConcepts originally motivated  
by Rick is a good example of why one might want to use namespaces.  I  
propose we move this effort forward under either a "voevent:"  
namespace or perhaps a more general "voconcept:" namespace.  My own  
preference is for the former.

3) Complex event types
     We need an inventory of event types that are currently being  
used in GCN, CBAT, ATEL, MPC, etc.  We can't pretend to be responsive  
to the community's needs until this is available.  Am refraining from  
calling this the VOEvent "data model".

4) Authentication
     A method of signing VO XML packets was prototyped by Steve Allen  
at the NVO summer school as part of the larger VOEvent Demo.  XML  
signatures can be realized as wrappers around XML elements or as  
subelements if the schema supports such.  In general, a digital  
signature (a cryptographic message digest) cannot be embedded in a  
document because such a one-way hash function changes the document  
itself.  This is avoided by using an XSL transformation to excise the  
signature.  Really quite a clever hack.  Suggest that the v1.1 schema  
allow signatures in some format or formats, but that this not be made  
a formal part of the specification before VOEvent v1.2.  Signatures  
would be optional.

5) Data rich packets
     We put a lot of effort into providing mechanisms for embedding  
reference pointers within packets.  I would like to explore options  
for supporting the opposite strategy of embedding data directly  
within packets.  Obviously this would be optional.

I suspect that will suffice to get a spirited discussion going :-)

Rob