VOEvent working draft published: version, param

[Tony Linde]

> it's loosely typed, so yes, tis in theory would be allowed.

That was not the point I was making: I meant that the two <param>s referred
to different items.


> -----Original Message-----
> From: Alasdair Allan [mailto:aa at astro.ex.ac.uk] 
> Sent: 25 June 2005 10:50
> To: Tony Linde
> Cc: voevent at ivoa.net
> Subject: RE: VOEvent working draft published: version, param
> 
> 
> > 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,
> 
> it's loosely typed, so yes, tis in theory would be allowed.
> 
> > 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.
> 
> <Param> also have a ucd="" attribute, however that's not 
> really the point.
> 
> > 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.
> 
> That is of course it's primary purpose, so we can hardly 
> reassure you on that point!
> 
> > 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.
> 
> I've always favoured a market driven approach myself, event 
> providers that provide good events will have subscribers, 
> people who ship junk will not be trusted and won't have any 
> subscribers. What's the problem?
> 
> > 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.
> 
> Everything is open to misinterpretatio, due to the time 
> factors involved I would be willing to lay substantial 
> amounts of money that most packets will have initially at 
> least be parsed without the benefit of checking against any 
> (or all) schemas associated with teh document. There will not 
> be time to fetch them, there will nto be time to look at 
> them. We're operating in a regieme where a couple of seconds 
> is a long time, additonal steps are a bad thing. You're just 
> going to have to make some assumptions, because either you 
> know what your upstream provider is assumping when the 
> document is produced or you are subscribed via an aggregator 
> which does indepth checking (and will issue retractions for 
> bad data later).
> 
> > 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.
> 
> I really don't see the point, buy in for using VOEvent is 
> already quite high. Introducing something like this will 
> steepen the curve, perhaps to the point where a project 
> starting up (or especially a long established one with a lot 
> of investment in their own infrastructure) won't see the 
> point of using it. If the hill is too steep people will not climb it.
> 
> Al.
> 
>