VOEvent Proposed Recommendation: Request for CommentsThis document will act as RFC center for the VOEvent V1.1 Proposed Recommendation.Specification at http://www.ivoa.net/Documents/PR/VOE/VOEvent-20060629.html XML Schema at http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd In order to add a comment to the document, please edit this page and add your comment to the list below in the format used for the example (include your WikiName so authors can contact you for further information). When the author(s) of the document have considered the comment, they will provide a response after the comment. Discussion about any of the comments or responses should be conducted on the VOEvent mailing list, voevent@ivoa.net. Comments
| ||||||||
Added: | ||||||||
> > |
| |||||||
Added: | ||||||||
> > | 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). | |||||||
Added: | ||||||||
> > | To solve that, I recomend putting UCDs in tags. So instead of the example: | |||||||
Added: | ||||||||
> > | <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" /> | |||||||
Added: | ||||||||
> > | 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. -- PetrKubanek - 2006-08-07 | |||||||
<--
|