Bringing VOEvent v2.0 home to roost

[Rob Seaman]

Mike says:

> I've had a first pass through the document and I'm generally much
> happier and willing to implement the final form.

Bless you and all your descendants!

> A few specific comments follow.

Replies interpolated.  I have updated the document and have passed the pen to Roy to address the remaining issues.  He will post the next version for comment - I suspect with great rapidity.  Successive versions should be regarded as "candidate proposed recs".  Using the popcorn rule, when the in-WG comments settle down to a few burnt kernels, I will promote it to proposed rec.  I gather the IVOA rules then provide for a two week comment period before it moves to the official RFC.  I'm sure the mistakes in this paragraph and in the format of the document will be expeditiously brought to my attention.  Please comment as rapidly and thoroughly on substantive issues regarding the VOEvent standard and schema themselves :-)

> General Comments:
> 
>     - Reference citations almost all wrong, references > 4 are off by one
>         (e.g. [21] should be [20] and so on).

I have updated.  I'm sure mistakes still exist.  Certainly missing references as well.

>     - Would like to see a simplified view of the schema as in Sec 7 of
>         the VOTable rec.  When implementing, there are a lot of words to
>         sort through to find element hierarchies, attributes etc.

Over to Roy.

> Sec 1: Introduction
> 
>   2nd to last paragraph:
> 
>   "The results of astronomical observations using real telescopes must
>   be expressed using the IVOA VOEvent standard, be recorded and
>   transmitted via registries and ....."
> 
>         Isn't recording and transmitting a repository/transport responsibility,
>         certainly not registries?

Updated the wording.

>   "Each event that survives rigorous filtering can then be passed to
>   other real (or possibly virtual) telescopes, for instance via XMPP,
>   ASCOM, dc3.com, or some other transport protocol, ......"
> 
>         Need references if these are meant to be actual transports, otherwise
>         suggest more general language about passing events on through the
>         e.g. "VOEvent transport network" or somesuch.

Over to Roy.

> Sec 2.1: Publishing VOEvent Packets
> 
>   "In addition to Publisher and Subscriber, the following roles define..."
> 
>         Suggest you open with just "The following roles define ...."  The
>         concepts of Publisher/Subscriber haven't been introduced yet.

Done.

> Sec 2.2: VO Identifiers (IVORNs) and Publishers
> 
>   "... meaning that a registry exists that can resolve that identifier to
>    the full VOEvent packet."
> 
>         Suggest "that a mechanism exists ...." instead.

Done.

>         The whole issue of how this mechanism should work, exactly what
>         gets put into the Registry for service discovery, metadata, etc is
>         still very vague.  I assume docs describing those details are in
>         the works?  The VOEventStream WD should also be referenced, it has
>         some of the info needed to define the "principal schemata" listed.

Wonderful suggestions.  Roy?

> Sec 2.3:  Authentication and Authorization
> 
>   "....These questions are addressed elsewhere."
> 
>         Where exactly?  As used generally w/in IVOA or specifically w/in
>         VOEvent, i.e. with SSO certs be passed to authorize my event packet
>         if I'm a Publisher or will you lookup my <Who> to see if I'm a
>         good guy?

I'll leave it to Roy to remove the sentence or otherwise point Bob Denny's note.  What is the best reference for the original work done by Steve Allen?

> Sec 2.4.2: VOEventServer in the VO Registry
> 
>   "Three kinds of capability that we can mention are subscription, formal
>    query, and informal query."
> 
>         No mention is made of what constitutes and "informal query".

Roy's to clarify.

> Sec 3.:  VOEvent Semantics
> 
>   "A VOEvent element may contain at most one of each of the following
>    optional sub-elements: ...."
> 
>         A strict interpretation would suggest a packet such as
> 
>           <VOEvent>
>             <Description>Bright star left of the moon at
>                 Mar 7 15:31:46MST as seen from my backyard</DESCRIPTION>
>           </VOEvent>
> 
>         is a compliant packet, although not terribly useful.  I think
>         most people expect event packets to be either the simple reference/
>         citation type, or "complete" packets with the whole Who/What/....
>         structure.  The line break in the grouping of elements suggests
>         this as well, but is some more formal language needed to prevent the
>         above sort of abuse?

This is a legal packet.  The utility may be unclear, but I wouldn't call it abuse.  A FITS file can be very minimal, too.

> Sec 3.1.2 role -- .....
> 
>   "The optional 'role' attribute accepts several possible values, including
>    these:"
> 
>         Does this mean the value of the attribute is/can be several values?
>         Is this a free-form value or does the list of 4 roles given comprise
>         the list of acceptable values?  Is there a need for having compound
>         roles?

Have clarified.

> Sec 3.3.1.5  dataType -- A string .......
> 
>         Does this need to be camelCase, I don't think that is generally used
>         in other specs?

Roy?

>   "Allowed values are "string", "int",or "float", with the default being
>    "string".
> 
>         Why can't this be the same set of primitive types allowed in a
>         VOTable <PARAM>??  Do 'int' and 'float' assume 32-bit values and
>         precision limits?

Roy?

> Sec 3.2.2  Group -- collection of related Params
> 
>   "There are rules of uniqueness Params and Groups in VOEvent:"
> 
>         "....of uniqueness for Params ...."
> 
>         Also, the 'type' attr is not requied to be unique...Are there
>         examples of why this might be useful (e.g. multiple groups defining
>         photometry params as distinct from the groups defining spectral
>         params)?

Roy?

> Sec 3.3.3 <Table> -- simple tabular data
> 
>   "It should be noted that longer tables, or any table, can be linked using a
>    <Reference> element"
> 
>         How do I interpret a <Reference> link to a longer table if the <Table>
>         goes on to define <Field> and <Data> elements?  Should <Reference> be
>         exclusive to link to longer tables, seems to me to be a clearer case
>         than a <Reference> meant to further document the table unless this
>         can be distinguished by the uri/type attributes of the <Reference>

A reference is a general purpose construct.  I think it unwise to attempt to limit it.  Perhaps Roy might comment on the inner/outer zen of tables.

> Sec 3.4.1  ObservationLocation
> 
>         Suggest there be a simple, declarative openeing sentence saying what
>         this is meant to define, similar to <ObservatoryLocation> in the
>         following section.

The goal was not to modify section 3.4.  We're doing pretty well if you only came up with two comments carried over from v1.11.

> Sec 3.4.2  ObservatoryLocation
> 
>   "The id here indicates a specific registered observatory, other examples
>    being: Keck, KPNO, JCMT, MMTO, VLA, <i>etc.</i> , ...."
> 
>         Registered where?  Does this assume 'Keck' will be a Registry
>         resource giving it's position or maybe that the author's <Who>
>         information will have it somehow?

Registry folks?  Anything new here to take into account in the last few years?

> Sec 3.3.3.6  dataType -- A string .......
> 
>         Again with the camelCase ....

Again over to Roy.

Thanks!

Rob