VOEvent working draft published: version, param

[Tony Linde]

Sorry - hyperbole overdrive was engaged... 

> even has a chance to live. To produce an approach which 
> guarantees that receiving applications will fail is not going 

I meant that applications will almost certainly fail at some indeterminate
point.

> The only way you can avoid the guarantee of failure is by 

That is, the guarantee of failure 'at some point'.

T.

> -----Original Message-----
> From: owner-voevent at eso.org [mailto:owner-voevent at eso.org] On 
> Behalf Of Tony Linde
> Sent: 24 June 2005 21:48
> To: voevent at ivoa.net
> Subject: RE: VOEvent working draft published: version, param
> 
> 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 ...
> 
>