VOEvent working draft published

[Tony Linde]

Hi, Rob. I'll incorporate replies to your comments into the one to Roy's
message.

Cheers,
Tony. 

> -----Original Message-----
> From: Rob Seaman [mailto:seaman at noao.edu] 
> Sent: 23 June 2005 21:57
> To: Tony Linde
> Cc: Rob Seaman; voevent at ivoa.net
> Subject: Re: VOEvent working draft published
> 
> Hi Tony,
> 
> 
> > I'm confused by the use of the IVOA identifier in the spec. 
> It seems 
> > to imply that all VOEvents will have unique identifiers of the form 
> > used to identify Resources, and so will all have an entry in the 
> > Registry.
> >
> 
> I'll let others reply to your ID comments in more detail - 
> I'm sure I'll learn a lot from the discussion.  Some of the 
> confused description arises, I'm sure, from my not very deep 
> current understanding of VO Registry issues.  On the other 
> hand, words like "resolve" and "metadata packet" were used in 
> v0.3 of the specification before I had a chance to muddy the 
> waters.  I'm left wondering whether a consensus view of 
> Registry, Resources and such actually exists yet among the 
> IVOA cognoscenti.  That said, I would welcome suggestions for 
> alternate wording to what is in v0.94 for each of the issues 
> you raise.
> 
> 
> > 3.1.3 version:
> >
> > Why do you need the version number of the spec? Won't that be 
> > contained in the namespace for the metadata elements?
> >
> 
> I would have thought it obvious that the operational system will  
> contain packets conforming to several versions of the specification  
> and we need a simple way to distinguish the schema that will be used  
> to interpret those packets.  I've been wrong about "obvious" things  
> before.  Please expand on your comment.  An example of 
> proposed usage  
> would be greatly appreciated.
> 
> 
> > 3.3.1 <param>:
> >
> > What is the point of this element? If it contains real data,  
> > shouldn't that data be part of the schema for the VOEvent?  If it  
> > is data so specialized that only a few applications will 
> use it, it  
> > ought to go into an extension schema with its own namespace 
> so that  
> > apps can see directly whether they can handle the data.
> >
> 
> I think the words "extension schema" just raised the aggregate blood  
> pressure of the group.  A VOEvent packet needs to be kept as simple  
> as possible.  The process needed to create such a packet must 
> be kept  
> simple.  And the process to commission a new "flavor" of 
> VOEvent must  
> be kept to a minimum.  As the specification says:  "<Param> elements  
> may be used to represent the values of arbitrarily named 
> quantities.   
> [...]  Thus a publisher need not establish a fixed schema for all  
> events they issue."  A natural result of this is that an application  
> listening for new events is presumed to have some prior knowledge of  
> the types of packets it is interested in receiving.  This is not  
> likely to be an impediment for the prototype systems being planned  
> for v1.0.  Given the real-world investment that is needed to 
> attach a  
> robotic telescope to an event stream, it is not clear that 
> this would  
> ever be a practical issue for this class of VOEvent application.
> 
> That said, what you suggest is certainly desirable as a view of the  
> Platonic ideal of an event description.  If a solid case could be  
> made that such instrument/application dependent schema would 
> simplify  
> VOEvent usage or make handling more efficient or reduce the cost of  
> project buy-in then this could be a significant improvement to  
> consider for a future version of the specification.  Given the real  
> world constraints on VOEvent (the project), it would be hard 
> to argue  
> for delaying VOEvent v1.0 (the specification) for such a purpose.
> 
> 
> > 3.7 <citations>:
> >
> > Does this mean that a retraction has to have a new event 
> ID? If you  
> > use the same event ID as the original event, isn't that likely to  
> > lead to errors?
> >
> 
> I was operating on the assumption that such a retraction 
> would indeed  
> require its own unique and new event ID.  I see that the document  
> does not currently make this evident.  The only example of 
> reusing an  
> ID is to issue an indirection packet that points to the remote  
> location of a packet with the same ID.
> 
> 
> > Hope all this helps,
> >
> 
> Indeed so!  Many thanks!
> 
> Rob Seaman
> 
> 
>