VOEvent working draft published

[Rob Seaman]

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