VOEvent working draft published: version, param

[Tony Linde]

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

That wasn't the point I was making: the two elements had the same name but
were semantically different items.

> I've always favoured a market driven approach myself, event 

So why not allow both the <param> and the schema extension approach in the
spec. then market forces will determine which is the approach which finds
best favour with providers and consumers of VOEvent records.

> point of using it. If the hill is too steep people will not climb it.

I'm not suggesting changing the steepness of the hill but offering two ways
to climb it: using <params> whereby you hack your way through all the
brambles to the top, hoping you've not got lost along the way; or using
extension schemas where you simply take the chairlift!

Cheers,
Tony. 

> -----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.
> 
>