VOEvent v2.0 moving to proposed recommendation stage...

[Robert Seaman]

Hi Matthew,

>> In the absence of comments on the v2.0 working draft, the VOEvent chair can only presume that the draft has been approved by acclamation of the working group.  In that case, the next step is to move it to the proposed recommendation stage.
> 
> Where are your two reference implementations? Anyhow I have some comments on the WD:

You have uncovered my (not very well hidden) agenda to provoke comments from the WG.  Thanks for enumerating various hurdles to moving this forward.  The first and biggest hurdle is to demonstrate consensus on the content of the draft.

Roy has been working on one VOEvent v2.0 reference implementation in Python.  Who has another?

> - You need to bring the specification in line with the latest IVOA spec guidelines: there needs to be a status section at the start, the version number needs to fit the new syntax (WD-VOEvent-2.0-2010mmdd.pdf). You also now need a section at the start stating how it fits in with the overall IVOA architecture.
> 
> - A Table of Contents at the start would be very useful

Gratefully noted.  In return, note that as a coauthor, "you" includes you.  Consensus among the coauthors would be a good place to start :-)

> - I find the use of may and might vague and ambiguous: it's hard to figure what it required and not. Can we have a couple of capitalized SHOULDs and MUSTs were necessary.

We'll try to tighten up the subjunctive, but I'm personally skeptical of overemphasizing words even (or especially) in a normative document.

> Maybe a compliance table in the appendix showing what needs to be in a minimal VOEvent. Is there a validator?

A validator would be cool.  A minimal VOEvent message is quite minimal - for instance, just a citation.

> - Why are some element names just initially capitalized and others all upper case, e.g. <Field> in <Table> and <FIELD> in <SimpleTimeSeries>. Can we be consistent throughout?

Yes, we certainly should be.  Glad to see the word "we".

> - Is the new element called simpleTimeSeries or SimpleTimeSeries - there are references to both in the document

Preference for usage here?

> - Why does <Param> use dataType but SimpleTimeSeries uses datatype?

Should be the same if the intent is the same.  Names should be very different otherwise.

> - The references are all out-of-sync between the reference list and the body of the document, e.g. RTML [15] - [15] is the IVORN reference, VOEvent Transport Note [21] - [21] is VOTable, etc., etc., etc.

We'll need to fix this before promoting the draft.

> Specific:
> 
> - p2, para.5: Missing period at the end of the paragraph
> 
> - p3, para.2: VOEvents that cannot benefit from immediate follow-up are not good candidates - immediate follow-up for a SN might not be much use, a program of sustained follow-up is of much greater benefit

I don't think "immediate" and "sustained" are antonyms here.  The intent is certainly to support the construction of lengthy chains of empirical investigation.  In astronomical usage, immediate would tend to focus on meanings like:

	5. without intervening medium or agent; direct: an immediate cause.
	6. having a direct bearing: immediate consideration.
	7. very close in relationship: my immediate family.
	8. Philosophy . directly intuited.

Otherwise, "immediately afterwards" might be a millennia hence.

> - p3, sec.1.1: We have a new schema that is completely within the VOEvent schema - I'm confused - can you do this within XML Schema?

Needs to be better described.  In coordination with v2.0 we also want a robust schema requiring minimal external entanglements.

> - p3, sec.1.1: "element is clarified: section 3.7" - maybe "see section 3.7" is better
> 
> - p3, sec.2.1: "Publishers will register..." and "Public repositories will register..." - what is the meaning of "will" here? Should they register? Must they register?

The IVOA cannot force registration.  This is a bigger issue than VOEvent.  Registration is, however, implicit in the IVORNs.

> - p4, sec.2.2: "There are several types of metadata schema that the registry can hold" - this seems to imply that registries have to understand the VOEvent schema - have we told the registry WG this?
> 
> - p4, sec.2.2: VOEventStream and VOEventServer "the metadata packet..." - is this the same sort of metadata packet as VOEvent defines and is it sent around? Packet just seems the wrong word

I would say that VOEvent is eager to benefit from registry technology.  Those members of the VOEvent WG who are also members of the Registry WG are encouraged to take the lead.

> -p4, sec.2.2: How are VOEvent identifiers overloaded? The bit before the pound sign identifies the stream, the bit after the event within that stream. If this is overloading then my postal address is overloaded - the letters identify the road and the number the house within that road.

Perhaps this can be reworded.

> - p4, sec.2.2: The first example - "ivo://nvo.caltech/voeventnet/catot. However, this IVORN will not resolve" - which IVORN - there are two in the current context. Actually the event IVORN should resolve in the registry but return the appropriate VOEventStream record.

Glad to see that the Registry WG is already on the job.

> - p5, sec.2.2: "remain under debate in the VOEvent Working Group" - there is an internal working draft for this and we can promote it to a proper Working Draft - reference this
> 

> - p5, sec.2.3: "These questions are addressed elsewhere" - good, where?
> 
> - p5, sec.2.4: "(proposed elsewhere)" - reference them - there is at least something on the IVOA VOEvent group web pages

Volunteers?

> - p5, sec.2.4.1: "Creating a Stream...publish am event" - "an event"
> 
> - p5, sec.2.4.2: "when it becomes an IVOA recommendation" - remove this and just reference the document
> 
> - p5, sec.2.4.2: "an informal query capability" - really? What is this? It's the first I've heard about it and is not defined in the VOEvent registry extension document.
> 
> - p6, sec.3: "Multiple <VOEvent> elements may be jointly contained within a larger XML document" - how does this work - what is the global root element?
> 
> - p6, sec.3: Why can a VOEvent only contain at most one <Reference> - what if I want more?

Will need to compare against v1.1.

> - p6, sec.3.1.1: "It is anticipated that" - after 5 years of this, we should not be anticipating

It takes as longs as it takes.  I anticipate anticipating things indefinitely.

> - p8, sec.3.3.1: How many <Description>s and <Reference>s can a <Param> contain?

How many do you think?

> - p8, sec.3.3.1: "the attribute takes precedence ofv the element" - over?
> 
> - p8, sec.3.3.1: "normalization [**]" - missing reference
> 
> - p9, sec.3.3.3: Why are you reinventing VOTable? If you are going to do this, you need to at least justify it

Your name is on the draft.  What are your thoughts here?  This is the beginning of the process, not the end.

> - p10, sec.3.3.4: "and so it is possible to simply reference it using the <WhereWhenRef> element" - how does this work? There is nothing in the WhereWhen section saying that <WhereWhen> has an ID attribute.

Thanks for spotting that.

> - p11, sec.3.3.4: Can a SimpleTimeSeries contain a Reference element? Or would it have to be a <REFERENCE> element?

It should be integrated with usage elsewhere in the packet.

> - p11, sec.3.4: Where is the simpler STC schema? If it is just the same elements and attributes but without the STC namespace then state this? What happens if I include full STC as in VOEvent 1.15 - is this still allowed?

Roy?

> - p15, sec.3.6.3: "still in development" - there is an IVOA Note on the Object Type ontology

Thanks!

Rob