TWiki
>
IVOA Web
>
IvoaVOEvent
>
VOEventRFC
(revision 4) (raw view)
Edit
Attach
---++ VOEvent Proposed Recommendation: Request for Comments This document will act as RFC center for the VOEvent V1.1 Proposed Recommendation.<br/> <a href=http://www.ivoa.net/Documents/PR/VOE/VOEvent-20060629.html>Specification at http://www.ivoa.net/Documents/PR/VOE/VOEvent-20060629.html</a><br/> <a href=http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd>XML Schema at http://www.ivoa.net/xml/VOEvent/VOEvent-v1.1.xsd</a><br/> 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 <nop>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 -- IVOA.RoyWilliams - 2006-07-11 * (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). -- IVOA.MarkTaylor - 12 Jul 2006 * 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. -- IVOA.RoyWilliams - 2006-07-12 * (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: <pre> <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" /> </pre> Let's have something like: <pre> <GRB> <trigger_num>114299</trigger_num> <rate_signif>20.49</rate_signif> <grb_inten>73288</grb_intent> </GRB> </pre> 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. -- IVOA.PetrKubanek - 2006-08-07 <br/> <!-- * Set ALLOWTOPICRENAME = %MAINWEB%.TWikiAdminGroup -->
Edit
|
Attach
|
Watch
|
P
rint version
|
H
istory
:
r16
|
r6
<
r5
<
r4
<
r3
|
B
acklinks
|
V
iew topic
|
Raw edit
|
More topic actions...
Topic revision: r4 - 2006-08-07
-
PetrKubanek
IVOA
Log in
or
Register
IVOA.net
Wiki Home
WebChanges
WebTopicList
WebStatistics
Twiki Meta & Help
IVOA
Know
Main
Sandbox
TWiki
TWiki intro
TWiki tutorial
User registration
Notify me
Working Groups
Applications
Data Access Layer
Data Model
Distributed Services & Protocols
Registry
Semantics
Interest Groups
Data Curation
Education
Knowledge Discovery
High Energy
Operations
Radio Astronomy
Solar System
Time Domain
Committees
Stds&Procs
www.ivoa.net
Documents
Events
Members
XML Schema
Copyright © 2008-2025 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding TWiki?
Send feedback