Bringing VOEvent v2.0 home to roost

[Roy Williams]

Mike
Thank you for your incisive comments, responses below.

The edited specification, schema, and schema picture are all available 
at the wiki:
http://www.ivoa.net/cgi-bin/twiki/bin/view/IVOA/VOEventTwoPointZero

Roy

--------------------


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

Will be fixed before REC!

>      - Would like to see a simplified view of the schema

Done

> "The results of astronomical observations using real telescopes must
>    be expressed using the IVOA VOEvent standard, be recorded and
>    transmitted via registries and ....."
 > "Each event that survives rigorous filtering can then be passed to
 >    other real (or possibly virtual) telescopes, for instance via XMPP,
 >    ASCOM, dc3.com <http://dc3.com>, or some other transport protocol,
 > ......"

New wording:
The results of astronomical observations using real telescopes will be 
expressed using the IVOA VOEvent standard and disseminated by registries 
and brokers within and outside the VO. Each event that survives rigorous 
filtering can then be passed to other telescopes to acquire follow-up 
observations that will confirm (or deny) the original hypothesis as to 
the classification of the object(s) or processes that generated that 
particular VOEvent in the first place.


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

> "... meaning that a registry exists that can resolve that identifier to
>     the full VOEvent packet."
>
>          Suggest "that a mechanism exists ...." instead.

Done

> "....These questions are addressed elsewhere."

Phrase removed

> "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".

Phrrase removed


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

This is correct in my opinion. The above is a valid packet.

> "The optional 'role' attribute accepts several possible values, including
>     these:"

Changed to
The optional role attribute accepts the enumerated options:

> Sec 3.3.1.5  dataType -- A string .......
>
>          Does this need to be camelCase,

Perhaps it should have been "datatype". However, I have written a bunch 
of code against "dataType" and would prefer not to change it. It was a 
week of great enthusiasm for camelCase, since deflated.

> "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?


-- String includes char and unicodeChar from VOTable
-- Int includes boolean, bit, unsignedByte, short, int, and long
-- Float includes float and double from VOTable

So we cover everything except the complex numbers. However, I cannot 
think of any serious use case for complex, nobody has used complex in 
VOTable in the last 10 years, and without a definite use case, I see no 
need for it.

> "There are rules of uniqueness Params and Groups in VOEvent:"
> "....of uniqueness for Params ...."

Thanks for the reminder. I have updated to include Tables and Fields as 
well:

Note also that there cannot be Groups within Groups: a Group may only 
contain Params and not Groups or Tables; a Table may only contain Params 
and Fields and not Groups or Tables. There are rules of uniqueness for 
Params, Groups, Fields and Tables in VOEvent:
-- Each Param and Field must have a name. A Group or Table without a 
name is equivalent to having a name which is the null string.
-- Names must be unique within the set of those Params that are not in a 
Group or Table.
-- Names must be unique for the set of Params and Fields within a given 
Group or Table.
-- Groups and Tables must have unique names: this means that only one 
Group or Table can be nameless.

>
>          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)?

Updated the type definition to:
type -- A string that can be used to build data structures, for example 
a Group with type "complex" might have Params called "real" and "imag" 
for the two components of a complex number.

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

Any data object can be linked as a Reference, including Tables. The 
Reference can point to a VOTable or a FITS table or a text table. You 
can have *either* <Table> to include it in the packet, *or* <Reference> 
to point to an external data object. Anyway, I just removed the sentence 
"It should be noted ..." as it is obviously confusing.

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

Hows this:
The <ObservationLocation> defines the location of the event; the 
<ObservatoryLocation> specifies the location of the observatory for 
which that location is valid.

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

Changed to:
The id here indicates the name of the observatory,

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

Sorry.