VOEvent working draft published: version, param

[Alasdair Allan]

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