VOEvent v2.0 Proposed Recommendation: Request for Comments

This document will act as RFC center for the VOEvent V2.0 Proposed Recommendation:

• Specification at http://ivoa.net/Documents/VOEvent/20110402/PR-VOEvent-2.0-20110402.html
• or PDF at http://ivoa.net/Documents/VOEvent/20110402/PR-VOEvent-2.0-20110402.pdf
• XML Schema at http://ivoa.net/xml/VOEvent/VOEvent-v2.0.xsd

RFC Review Period: 8 Apr 2011 - 6 May 2011 (nominally 4 weeks, may extend longer)

TCG Review Period: 6 May 2011 - until concluded

Comments from the IVOA Community

WilliamOMullane

1. The first thing which caught my eye was WHO in section 3. > /Identification of scientifically responsibel Author/

apart from the spelling error for Gaia of course this may not make sense. Hence also 3.2.1. This would more likely be a helpdesk or some such for Gaia not an individual.

2. in 3.4.2 Observatory_Location You should consider adding "L2 = within 150000 KM of Earth Sun Lagrange Point 2" or something. There are enough missions going out there even if you suggest space missions can construct their own complex location later.

-- WilliamOMullane - 2011-04-08

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-24

NormanGray

I looked at the new section 3.9 on Reference. 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

---

---

Comments from the Technical Coordination Group

TCG members should add any comments under their name.

TCG Chair & Vice Chair (Christophe Arviset, Séverin Gaudet)

IVOA Chair & Vice Chair (Paolo Padovani, Ajit Kembhavi)

Applications 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:

1. Please provide details of the required two interoperable implementations and available validation tools, as per item 4 of section 2.1 of DocStd.
2. The VOEvent Schema is not part of this document. It is usual practice in IVOA standards which present and describe an XML Schema to include that schema as an Appendix. I don't know whether this practice is mandatory for IVOA standards (can Christophe advise?), but it seems like a good idea as it makes explicit what the schema text is for the declared version of the standard. The authors should either include the schema text as an Appendix, or explain why they prefer to omit it.

Some more minor items:

1. Abstract (and elsewhere): "...one or more of the who, what, where, when and how..." --- it looks to me like a Citations retraction element could appear on its own as the content of a VOEvent packet. If I've got that right, then should it read "... zero or more ..."?
2. Status of the document: "Click on the image below..." --- the single required format for IVOA standards track documents is PDF, so references to clicking should be removed (or perhaps work out how to get a PDF to do that, which is probably possible, but not implemented in the submitted PR PDF version).
3. Section 2.4: A reference is made to registry enhancements, proposed elsewhere, with the names VOEventStream and VOEventServer. I think these should be named instead VOEventStreamRegExt and VOEventServerRegExt (or similar) to follow standard practice for registry extension schemas. Perhaps somebody from the Reg WG can confirm.
4. Section 3.1.2: 'A "test"...' should read 'The value "test"...' for consistency with the rest of that list.
5. Section 3.3: Representation of tables --- This document has reinvented a lot of the content of the VOTable standard. I would welcome at least a comment in the VOEvent document comparing the VOEvent and VOTable representation of tabular data and metadata, and explaining why the decision was made to reinvent rather than re-use.
6. Section 3.3.1.5: details of floating point representation in the Param/Field dataType are referenced in the non-existent reference [666], this must be fixed. If you're looking for somewhere to pinch standards for floating point value representation from, you could try (with care) XML Schema or VOTable.
7. Explicit consideration should be given the possibility of null values described by Field or Param elements: are nulls permitted for float dataTypes? for int dataTypes? How must they be represented?
8. References: as well as the non-existent ref [666], the ref [31] in section 3.3.1.6 is incorrect, it should be [32]. I haven't checked all the other references; please can the authors do so.
9. Param and Field elements in several of the examples appear to be missing dataType attributes (cnts in sec 3.3.2, seeing, time, mag, magerr in sec 4). The examples should be corrected. Since this is clearly an easy mistake to make, consider making the dataType attribute mandatory rather than defaulting to string, so that it is at least possible at validation time to detect whether values typed as strings are so typed deliberately.
10. Section 3.6.3: It sounds like the Concept element may offer the possibility to use terms from more than one controlled vocabulary. Would it be a good idea to add an attribute defining which vocabulary is in use, to aid parsing? e.g.

       <Concept vocabulary="ucd1+">process.variation.burst;em.opt</Concept>
       

11. Section 3.7.1: in one place the attribute value "supersede" is written when it should be "supersedes". The permitted values of the cite attribute are easy to get wrong since they are not gramatically very consistent - "followup", "supercede", "retract" might be a better set.
12. Spelling: atructure, suppliediven, thos, infromation, replaement
13. Character processing: the section(?) symbol is represented wrong in the PDF, e.g. in the last sentence before the section 1.1 (it also looks wrong in my browser, but that may be my problem).

-- MarkTaylor - 28 Apr 2011

Data Access Layer Working Group (Patrick Dowler, Mike Fitzpatrick)

Data Model Working Group (Mireille Louys, Jesus Salgado)

Grid & Web Services Working Group (Matthew Graham, Paul Harrison)

Registry Working Group (Gretchen Greene, Pierre Le Sidaner)

Semantics Working Group (Sebastien Derriere, Norman Gray)

VOEvent Working Group (Rob Seaman, Roy Williams)

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-24

VOTable Working Group (Francois Ochsenbein)

Data Curation & Preservation Interest Group (Alberto Accomazzi)

Knowledge Discovery in Databases Interest Group (Giuseppe Longo)

Theory Interest Group (Herve Wozniak, Claudio Gheller)

Standards and Processes Committee (Francoise Genova)

Science Priorities (David De Young)

---