VOEvent working draft published: version, param

[Tony Linde]

Hi Rob,

> Providing a general purpose mechanism for grouping and typing 
> keyword=value pairs using <Param> is precisely the key 
> compromise that will bring VOEvent to life.  Other VO 

It is the use of <param> that will kill VOEvent before it even has a chance
to live. To produce an approach which guarantees that receiving applications
will fail is not going to engender any confidence in the IVOA's ability to
produce standards that are consistent with the real world.

The only way you can avoid the guarantee of failure is by wrapping the
definition of the <param> in so many ifs and buts about who can create names
and what they must look like that the spec will make the EU constitution
look simple and easy to use.

> facility suggested for VOConcept.  And in particular, we do 
> not have the time to wait for schemata to be developed for 
> all possible instrumentation and observing modes that may 
> generate sky transient alerts.  I fear that you underestimate 
> the sheer terror of the thought of trying to fully 
> characterize the behavior of even a simple astronomical 
> instrument.  And each new instrument becomes more-and-more 
> clever and more-and-more complex.

I've no idea what VOConcept is. And you do not have to wait for schemata of
any sort. It takes less time to create a private schema and use it in your
own VOEvent record than it does to code up all the name-value string pairs
in your transmitting applications. And hugely less time for the receiving
applications.

No-one is asking for the whole behaviour of the instrument to be
characterized. In the same time it takes a person to dream up the names for
the name-value pairs, you can create a schema the same way. And then you
save a lot more time coding up your sending application.

> experienced "writers of transmitting server software and 
> receiving applications" who I expect would be least receptive 
> at this point of backpedaling toward a VOEvent specification 
> that requires an explicit new extension schema be written for 
> each instrument supported.

Are you really telling me that your highly experienced developers, who have
probably spent years creating complex software, are incapable of stringing
together a few elements into an xml schema? Even I can do that! I would
think they'd be more frustrated at the likelihood of their data being
misread and misinterpreted because we've taken a short-cut to the distant
past and embedded xml-ised CSVs into the spec they're forced to adhere to.

> The issue is precisely how to balance elegance of expression (words  
> like "cleanest") with elegance of process (words like "quickest").   

There is no issue of balance. With schema extensions you get both, with
<param> you get neither.


Roy referred to the fact that <param> appears in the VOTable spec. I'm happy
to admit that VOTable has worked under the initial circumstances of the
early VObs efforts. It works simply because it is always at the end of a
chain: all the interpreting is done by people. But VOTable always fails when
it is sent from one application to another. We've hit just that problem with
the workflows in AstroGrid: since none of the information (like <param>
name-value pairs) is formally defined, it cannot be formally interpreted by
an application - it always takes a human to do the interpreting.

If you are saying that VOEvent records are *never* going to be sent to
applications for interpreting and actioning and that they will only ever be
sent to humans (or to tools which will only be used directly by humans like
the VOTable tools) then <param> might be used (but will still take more work
than extension schemas). But if you expect a VOEvent record to ever be
interpreted by software which will kick off another action, like directing a
telescope or running a data search, without direct human intervention, then
<param> is simply not suitable.

Cheers,
Tony. 

> -----Original Message-----
> From: Rob Seaman [mailto:seaman at noao.edu] 
> Sent: 24 June 2005 20:57
> To: Tony Linde
> Cc: voevent at ivoa.net
> Subject: Re: VOEvent working draft published: version, param
> ...