VOEvent - Param comment

[Tony Linde]

Good luck, Petr. I argued against the param tag as ambiguous and error-prone
a long time ago and got nowhere.

T.

> -----Original Message-----
> From: owner-voevent at eso.org [mailto:owner-voevent at eso.org] On 
> Behalf Of Petr Kubanek
> Sent: 07 August 2006 14:54
> To: voevent at ivoa.net
> Subject: VOEvent - Param comment
> 
> I have a comment about Param tag. Did you ever try to write 
> XML parser? Do you know how big pain is it when you have 
> attributes and you need to search for value of particular one?
> 
> You are making in my point-of-view classical XML-designers 
> mistake. XML was designed to transport well organized data, 
> so they can be machine readable. Param fields with UCDs are 
> not well organized - because you cannot validate document for 
> UCD validity, and you cannot reasonably parse it and store in 
> target language (you can save it to collection holding 
> parameters and then search in parameters..think how much 
> overhead you will create by such decision, and how many tests 
> will you need to perform - and XML was created to remove from 
> you burden of such tests, and you just put them the different 
> way inside).
> 
> 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,..).
> 
> In schema that will maternize as choice for different event types.
> 
> By letting free UCDs parameters you actually say: we don't 
> care about researching which ever possible events can be 
> transported by VOEvent, so we left submiters freedom to 
> create mess of different parameters, so as results no machine 
> will be able to use VOEvent entry and it will be again human, 
> who have to read it and understood what was author intention. 
> Mayby that's right for scientics, but for computer programmer 
> it's a nightmare. And for robotic telescope operation it is 
> nearly useless.
> 
> You really need to define possible content, most probably 
> starting from what we know and use currently (e.g. GCN format 
> is well established) and going to more difficult areas, where 
> GCN example is not available.
> 
> --
> Petr Kubanek
> 
> Integral Science Data Center           Astronomical Institute 
> Chemin d'Ecogia 16                     Fricova
> CH-1290 Versoix, Geneva, Switzerland   251 56 Ondrejov, Czech Republic
> Office +41 22 379 2198                 pkubanek at asu.cas.cz
> Petr.Kubanek at obs.unige.ch
>