VOEvent II summary, part 3

[Rob Seaman]

Andrew say:

> Yes it is simple to change but I'd like to be sending and receiving  
> and storing conforming VOEvents ASAP, so it is relevant to me. The  
> better our standards are now the less everyone is going to have to  
> change their software in the future.

The intent is to craft v1.1 of the specification to address the  
several issues that have been raised, including STC, VOConcepts,  
proxies, ids, new roles, etc.  Doubt we'll make much progress before  
the end of the year.  In particular, many of these issues remain  
moving targets and will require further discussions.  Perhaps we can  
agree on a minimum set of changes needed to move the infrastructure  
forward.  Somebody else can comment on STC, but this would include  
the id attribute and the new roles, for instance, but not  
VOConcepts.  We would want to increment the version to some  
intermediate value, say, "1.01X" or some such.  Perhaps there is a VO  
precedent for experimental versioning?  Would likely document v1.01X  
via a simple email agreement.

As with any standard, if you want to send, receive and store  
conforming documents, you need to live within the letter (but perhaps  
not the spirit) of the latest version of that standard.  Packets that  
implement the new ack and iamalive roles should not be labeled  
version="1.0".

Rob