VOEvent v2.0 Proposed Recommendation: Request for CommentsThis document will act as RFC center for the VOEvent V2.0 Proposed Recommendation:
Interoperable ImplementationsSkyalert and Dakota are active projects that read and write VOEvents and have transitioned (or ready to transition) from VOEvent 1.1 to 2.0. A VOEvent2 library in Python is available at VOEventLib, and another in dotNet called Dakota. Many projects produce VOEvent: IAU CBAT, NASA GCN, AAVSO. It is expected that Astronomers Telegram will make the transition, also the gravitational wave alert system LVAlert will move to VOEvent once it is REC.RFC Review Period: 8 Apr 2011 - 6 May 2011 (Completed)TCG Review Period: 9 May 2011 - until concludedComments from the IVOA Community during RFC periodWilliamOMullane1. The first thing which caught my eye was WHO in section 3.Reply:1) This appears to reference an old version of the PR. The current wording is "The Author IVORN element contains the identifier of the organization responsible for making the VOEvent available." Spelling must have been previously corrected 2) There has been some discussion of this point on the VOEvent WG mailing list. Not obvious if any change is required to the v2.0 PR as long as the schema supports this feature. -- RobSeaman - 2011-04-24NormanGrayI looked at the new section 3.9 onReference . I can see the change to requiring @meaning to be a full URI, but the new text might still be a little thin on detail, which could easily lead to variant implementations
In particular:
3.9.2 meaning — The nature of the document referenced (anyURI). This attribute is optional.
I'd have hoped to see a little more of an explanation of what this URI should be, beyond "It is anticipated that a Note will be written" about them.
3.9.3 mimetype — An optional MIME type [36] for the referenced document.
Similarly, this MIME type could be a variety of things, and since the MIME type given here could potentially differ from the MIME type of the document received, it'd be good to note which has priority (the MIME type declared by the document beinr received). It'd also be good to note what this is for, naly a hit rather than something you'd necessarily expect to work with.
I included some text for this section in my message of 2011 March 24 00:37:03 GMT. That may have been too prolix (and I admit a tendency to run to the formal in these contexts), but I thought a fair proportion of that text was at least useful.
We wouldn't want the VOEvent document to be full of legalese, but if it's too vague and suggestive, people will implement things based on what they guess the meaning to be, which could cause problems later.
(I originally posted this as a VOEvent list message, but it was more appropriate as an RFC comment, since it concentrates on language rather than technical content)
-- NormanGray -- 2011-05-04
Reply:Expanded description in section 3.9. -- RobSeaman - 2011-05-09Applications Working Group (Tom Mcglynn, Mark Taylor)This document looks mostly good to me (Mark), but there are some issues I'd like the authors to address. Two major points:
Reply:1. Examples of Independent Implementations:see new content at the top of the this page. 2. The schema can go in the appendix if the TCG requires it. 1. Text changed to indicate zero occurences of any of these are allowed. However the meaning of such minimalist VOEvents is not defined. 2. Document no longer talks of clicking. 4. Fixed 5. This element is intended for a short and simple table, and re-uses the ideas and syntax of the IVOA VOTable, but simplified and streamlined: this is appropriate because complex tables can be written as full VOTable and linked from the VOEvent. Specifically, these simplifications are: no support for hierarchy of tables (RESOURCE); no internal references (FieldRef and ParamRef); no provision for binary data, only XML; table cells can only be string, float, or int, in place of the arrays of 12 possible types and extensions; no formatting information contained in the Table, nor domain of the data (VALUES); no referencing between cells; there is no INFO element. 6. and 7. VOEvent supports IEEE 754-2008 floats, including signed zero, signed zeros, infinities, and special "not a number" values (NaNs). That standard also covers integers. Note that a null string cannot be converted to a float or int and will raise an error. http://en.wikipedia.org/wiki/IEEE_754-2008 8. Corrected these references 9. Fixed 10. Following the Reference element on this, the content of the examples showing the Concept element has been changed to a URI syntax. Thus, stars.supernova.Ia becomes http://ivoat.ivoa.net/stars.supernova.Ia. 11. and 12. Corrected spelling -- RoyWilliams - 09 May 2011Registry Working Group (Gretchen Greene, Pierre Le Sidaner)3. In agreement with the recommendation for the VOEventStreamRegExt and VOEventServerRegExt registry extension specification naming convention - would like to see this specification effort included in the TCG roadmap -- GretchenGreene - 10 May 2011 We think VOEvent v2.0 is ready for prime time. In the absence of substantive disagreement with this assertion, the PR will move to TCG review on 6 May 2011. -- RobSeaman - 2011-04-24TCG Review Period: 9 May 2011 - until concludedTCG members should add any comments under their name.TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)Following recent discussions, in particular at the TCG meeting in Naples, it would be good to address the following points : 1. Update the IVOA Architecture diagram for VOEvent and ensure that the introductory text makes explicit reference to adne explain the interdependencies with all of the IVOA standards mentioned on the diagram 2. Clarify / update sections 2.4.1 and 2.4.2 wrt VOEvent*RegExt registry standards related to VOEvent (to be discussed in Naples sessions) 3. Make a more explicit reference to the VOEvent schema, probably within the introdution as well, and be making a clear independent referene (currently it is kind of hidden in reference 20 4. It would be very useful to have page number and a TOC Given that these points are addressed adequately, I'm happy to approve VOEvent 2.0 -- ChristopheArviset on 2011-05-17 Thanks for having implemented these changes into the 20110613 version, hence I approve VOEvent 2.0 -- ChristopheArviset on 2011-06-17Reply:(1) Text added above the Architecture figue, explaining connections. It says "VOEvent is an IVOA standard, which means that it fits into a rich matrix of other IVOA standards: the image below shows where VOEvent fits into the broader IVOA architecture. VOEvents inherit much of the structure and semantics of VOTable, including the UCD scheme for semantics of quantities. VOEvent takes space-time coordinates from the STC, and it uses the URI semantics of the IVOA Vocabulary effort. IVOA Identifiers are used for events and their parent streams and servers, and both these latter will be described by IVOA Resource Metadata and stored in the registry. " (2) The RegExt suffix has been added (3) The VOEvent schema has been included as a section 7. (4) Sorry about the page numbers. We wrote in HTML, so this is the responsibility of the browser or other pagination device. -- RoyWilliams - 28 May 2011IVOA Chair & Vice Chair (Paolo Padovani, Ajit Kembhavi)Applications Working Group (Tom Mcglynn, Mark Taylor)As noted to Rob in person at Naples, I do not consider that my points 6 and 7 have been adequately answered. I'm talking here about representation of numeric values in the text of the XML document, i.e. how you write them down as a sequence of Unicode characters. As far as I can see(?) IEEE754 does not address that question, it only talks about how you serialize them as bit sequences. You may think this is obvious, but misunderstandings about whether, for example, "1e3" and "1d3" and "+1.00000000000000000000E+03" are valid representations of one thousand can and do cause interoperability problems. Concerning null values: if VOEvent really wants to disallow null entries in tables, the Apps WG will not veto it, but I strongly suspect that potential users of the VOEvent standard will sometimes wish to include blank entries as part of Table data. If this is disallowed, it should at least be mentioned explicitly in the same place you talk about numeric representation. My item 13 has apparently not been addressed. You could just replace the character in question with the text "Section" if it's proving hard to fix. -- MarkTaylor - 25 May 2011 (on the 20110509 version) Thanks Mark. I had a slide on open issues at the plenary and VOEvent sessions. I was going to make a conversation of it at the TCG meeting, but that exercise turned into something else. Your issues will be addressed in the next draft and the TCG will be able to review the changes. We appreciate your attentive reading of the document. -- RobSeaman - 2011-05-25 Here are the proposed definitions, including defaults, copied from Python docs (cited). For dataType=float, the value must contain a possibly signed decimal or floating point number, possibly embedded in whitespace; it may also be [+|-]nan or [+|-]inf. If the value cannot be parsed this way, for example null string, it may return zero or NaN, but no exception should be thrown. For dataType=int, the value must contain a possibly signed decimal number, possibly embedded in whitespace. Conversion of floating point numbers to integers truncates (towards zero). If the value cannot be parsed this way, for example null string, it will return zero, and no exception should be thrown. Also the section symbols are now the proper html code. -- RoyWilliams - 28 May 2011 Thanks to the authors for addressing my comments in the 2011-06-13 version. Apps WG now approves this document. -- MarkTaylor - 20 Jun 2011Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)A few minor comments and suggested readability changes: 1) P. 1 Abstract, para 3: The sentence "Subscribers, human or machine, receive immediate...." should be removed since it described the behavior of a particular type of client or use-case (two sentences later it says the standard does not address design issues like this). Alternatively, "...might receive...." would mitigate the declarative tone. 2) P. 7 Sec 2.2: Last sentence, suggest "remain under discussion...." rather than "debate" 3) P. 10 Sec 3.3.2: Suggest moving the last paragraph discussing the uniqueness of names to its own section (3.3.4) at the end of Sec 3.3 This would put the discussion after the | ||||||||
Added: | ||||||||
> > |
Document approved, congratulations to the authors for the effort on clarity. I really appreciated the overall clarity, Rob/Roy's subtle references and the VOEvent2 in a nutshell summary.
Minor typos in the last document version:
| |||||||
VOEvent Working Group (Rob Seaman, Roy Williams)We approve this doc. -- RobSeaman - 2011-05-10Data Curation & Preservation Interest Group (Alberto Accomazzi)Knowledge Discovery in Databases Interest Group (Giuseppe Longo)Theory Interest Group (Herve Wozniak, Claudio Gheller)Approved. -- HerveWozniak - 17 May 2011Standards and Processes Committee (Francoise Genova)<--
|