The State of VOEvent

[Roy Williams]

Bob

Thank you for your insightful and caring comments about VOEvent. Just a 
couple of responses about STC and about addition of new schema, from the 
Emeritus Chair.

Roy


>> 2) to permit VOEvent usage that benefits from modern, evolving, XML tools. 
>> [...] Intervening links in the workflow may well reformat the XML, making the
>>  packet different than the one originally signed.  How then do we deal with 
>> this as simply and reliably as possible?
>>     
> Why? What tools?
>   

One example has come already in trying to make an event portal. When 
annotations (eg 2MASS cutouts) are added to an event, how can they be 
linked to the event? Either make a container to hold all, or (and this 
is easier) modify the VOEvent.xml by adding to the <What> section a new 
PARAM like 2mass_j_cutout = "/data/blabla/73627.fits". I think we can be 
sure that people (not me tho!) will be altering events. OK fine, so it 
invalidates the signature. Is anyone surprised at that? No -- I think we 
can assume that people will understand this intuitively.


> Are we setting ourselves up for a world of hurt by straying from the K.I.S.S.
> principle? I see a disconnect between theory and practice already:
>
> (1) VOEvent 1.1 includes STC. No one has implemented STC. What is
> implemented/used is based on informal gentlemens' agreements and is a tiny
> subset of it. Also I strongly suspect that there is some of VOEvent (the outer
> schema) that is not implemented/used in reality.
>   

My hope and belief is that STC is being used in VOEvent in a specific 
and limited way to specify position of target and observer. The XML 
looks complicated, but as far as VOEvent is concerned, that is ALL from 
STC that is allowed. This was always the intention with STC, it is a 
"toolbox" so that different VO standards can take precisely what they 
need and no more.

> (2) Item (1) notwithstanding, there are multiple violations of the VOEvent 1.1
> schema in the actual messages (that use the squishy subset). 

Yes I know. It was the same with all the VO services. Somebody has to be 
using a lot of different kinds of events, and then that person will send 
messages to producers of uncompliant events asking them to straighten up.

> Instead, if I were on point, I'd say that we need to define a schema that
> reflects what's actually being used today (minus the errors in (2)), then work
> to get everyone to conform at least to that (again ref (2)). This would mean
> disconnecting VOEvent from STC, which is probably politically incorrect but I
> think engineering correct.
>   

The VOEvent specification expresses the ONLY elements allowed from STC. 
If you want to know how to deal with STC in the context of VOEvent, you 
do not need to read the whole STC document, it is very complex! Please 
read only section 3.4 of the VOEvent spec, it is all the STC that is 
allowed, and it is only 2 pages. So, if you like, we are detached already.

> Starting with that, someone (one person, not a committee!) with thick skin
> should be tasked with brokering the additions to the schema going forward. 

The question in my mind is how to stop the "new schema" people from 
upsetting those who are content with the old schema. If software has 
already been written to handle ordinary events, will it also be able to 
handle the "boutique" events?  Another question is balancing the special 
requirements of the "new schema" people against the possible breakdown 
of interoperability through balkanization.


> When more than one organization
> really needs something, and they can show a CLEAR and PRESENT use-case, 

Excellent. The nice thing about use cases is that not only is a good 
start for the work ahead, but also we can find out about somebody else's 
science.

Roy




-- 

California Institute of Technology
626 395 3670