VOEvent - Param comment

[Petr Kubanek]

>> To solve that, I recomend putting UCDs in tags. So instead of the  
>> example:
>>
>> <Param name="TRIGGER_NUM" value="114299" ucd="meta.id" />
>> <Param name="RATE_SIGNIF" value="20.49"  ucd="stat.snr" />
>> <Param name="GRB_INTEN  " value="73288"  ucd="phot.count" />
>>
>> Let's have something like:
>>
>> <GRB>
>>  <trigger_num>114299</trigger_num>
>>  <rate_signif>20.49</rate_signif>
>>  <grb_inten>73288</grb_intent>
>> </GRB>
>>
>> etc. for other events (transits,..).
> 
> 
> For every type of event every imaginable?

Not imaginable, but each type of event produced. So far they are not so many - GCNs, OGLE transists, Palamor Quest transients, and cosmic ray (CR) events - that's I think all.

Left world of generalities, for schema to be solid it must be build on real word data. And choice element left plenty of space to add extra data (of course on cost of producing new version of VOEvent..that's life:()

>> In schema that will maternize as choice for different event types.
> 
> 
> That's a lot of different schema, and a new one every time you want  to 
> send an event that's even slightly different from the "standard"  types. 
> I don't think that's particularly practical, and I think it  presents a 
> massive hurdle to the users and publishers that people  won't be 
> prepared to accept.

The hurdle is only on designer side. Publishers will be happy to see possible event types, think if they fit inside and if not ask for extra parameter. And users will be more then happy to see which all possible parameters can come in.

Our experience with CR data showed that you never know which fields you need...so we are now redesigning it a bit in order to use extra informations which already comes in. But for that you must know which fields publisher will publish - and that's schema purpose to document them.

Petr