VOEvent - Param comment

[Rob Seaman]

Hi Petr,

Your points are well taken and as Roy and Tony allude, have been  
raised before.

> You are making in my point-of-view classical XML-designers mistake.

I disagree - we are making avant garde XML choices, not classical XML  
mistakes :-)  An explicit architectural trade-off was made between  
supporting general purpose params versus elements custom tailored for  
each alert type.  VOEvent happens to be realized using XML, but it  
isn't an XML technology per se.  Just as XML itself has a broader  
range of applicability than just as a delivery mechanism for the zen  
of schema.

Perhaps someone can comment on why VOTable itself has <params>.   
Shouldn't each table be tailored to match its content?

> <GRB>
>  <trigger_num>114299</trigger_num>
>  <rate_signif>20.49</rate_signif>
>  <grb_inten>73288</grb_intent>
> </GRB>

In an ideal world, your suggestion is superior.  We have known this  
from the beginning.  Note that nothing about VOEvent should be taken  
as forbidding such usage in a future version, say v2.0.  We would  
need to be clear on the VOEvent ground rules (not just the XML rules)  
for including additional alert-specific schema.  The success or  
failure of these hand-tailored schema would be driven by market  
pressures, just like VOEvent itself.

The current state of the VOEvent community is different.  We are  
attempting to bootstrap VOEvent from today's complex world of many  
non-interoperable, non-XML, astronomical alert systems.  The choices  
made under such circumstances may be quite distinct from some  
idealized vision.  We should all be gratified at the success that  
VOEvent has demonstrated to date.  Success speaks for itself.

> Mayby that's right for scientics, but for computer programmer it's  
> a nightmare. And for robotic telescope operation it is nearly useless.

Well, actually, it is the robotic telescope community who have  
adopted VOEvent most enthusiastically.  VOEvent compliant code is  
already driving nightly robotic operations.

It has certainly been entertaining to watch the recurring debates  
between the astronomy side and the computer science side of the  
Virtual Observatory efforts.  I've yet to see a single issue where  
one side is entirely right or entirely wrong.  The more genuine  
disagreements tend to come between the scientific programmers and the  
computer science programmers - the folks who need to make it work.   
Whatever else is true of all of the many fascinating VO projects - at  
the end of the day, a pragmatic real world solution must exist and  
must be proven to be sustainably operable.

> You really need to define possible content, most probably starting  
> from what we know and use currently (e.g. GCN format is well  
> established) and going to more difficult areas, where GCN example  
> is not available.

VOEvent is the same type of effort as GCN was originally.  GCN-2 will  
be VOEvent compliant.  We are precisely in the business of defining  
formats, just as GCN has been before us.  To require a full formal  
data-modeling effort in advance of permitting new alert types to be  
issued, would be to cut the legs out from under the entire concept of  
issuing alerts for transient astronomical phenomena.

It is precisely the poorly characterized phenomena whose alerts are  
the most valuable.  We could do a wonderful job of crafting a fully  
specified, semantically rich, content-complete alert for eclipsing  
binary stars.  Few would bother to either author or subscribe to such  
alerts.

A certain frisson of the unknown must pertain to any scientifically  
useful alert.

Rob

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ivoa.net/pipermail/voevent/attachments/20060807/d7bf7bba/attachment-0001.html>