VOEvent working draft published: version, param

[Tony Linde]

You still haven't given any reason why a standard which allowed schema
extensions is not workable, nor any mechanism for how providers and
consumers of VOEvent records can ensure that data in <param> elements is
unambiguously what they expect it to be. 

In fact, I've not seen anyone here demonstrate how the spec tells downstream
app writers how to handle the receipt of:

   <Param name="GCN_INTEN_CNTS" value="17467"/>
and
   <Param name="GCN_INTEN_CNTS" value="fred bloggs"/>

from different providers, 
or how, upon receiving

   <Param name="GCN_INTEN_CNTS" value="17467"/>
and
   <Param name="GCN_INTEN_CNTS" value="123456"/>

allows them to be sure that the name 'GCN_INTEN_CNTS' has not been used for
two totally different purposes by two providers.

Again, if someone can assure me that the data in the <param> elements is not
supposed to be used by downstream apps to initiate any action and is only
there for human consumers then I'll withdraw my objections. Likewise if
anyone can show how data in the <param> elements is to be verified as being
what the downstream apps are expecting data associated with some 'name' is
supposed to be, then I'll also withdraw my objections.

But afaics, no-one has done so and so I conclude that any data included in
<param> elements is therefore prone to errors of ambiguity and
misinterpretation leading to failures or mistaken actions by downstream
applications.

And, as I said before, I still would accept the <param> element if the spec
explicitly allowed the alternative approach using extension schemas and
explained the pros and cons of both approaches.

Cheers,
Tony. 

> -----Original Message-----
> From: Alasdair Allan [mailto:aa at astro.ex.ac.uk] 
> Sent: 25 June 2005 03:21
> To: Alasdair Allan
> Cc: Tony Linde; voevent at ivoa.net; Rob Seaman
> Subject: Re: VOEvent working draft published: version, param
> 
> 
> Alasdair Allan wrote:
> > Rob Seaman wrote:
> >> It is precisely the highly 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.
> >
> > Yup, the current standard "as is" is fairly slim line, adding 
> > something like new extension schema on a per instrument 
> basis would be 
> > a total nightmare. No way...
> 
> Actually lets be blunt. I would be totally unable to justify 
> lending my support to such as standard.
> 
> Al.
> 
>