VOEvent Proposed Recommendation: Request for Comments

This 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

• (1) This first comment is a sample comment

• (2) I have a comment about the content of the Description element. I agree that it will sometimes be desirable to use plain text and sometimes to use HTML, but for software which encounters the content the current proposal presents the problem of how to present it - does it assume it's HTML and attempt to format it thus (which will look wrong if it's plain) or assume it's plain text and display it raw (which will look wrong if it's HTML) or attempt to guess by looking which it is (which is hard and error-prone). Can I suggest an additional attribute format on Description which may take (at least) the values plain (the default) and html. I'd suggest that it is not limited to these values so that specialised applications can use other formatting methods if they wish to in the future (on the understanding that not all software may know what to do with exotic formatting methods).

• Thank you Mark, good call. We suggest that "Description" have a "format" attribute, and that a parser be considered compliant if it recognizes two values: text/plain and text/html, the default being text/plain.

• (3) 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.

-- PetrKubanek - 2006-08-07