VOEvent working draft published

[Tony Linde]

Hi all, I'm impressed by how much you've managed to pull together in such a
short time. A few comments on the bits that I feel able to comment on,
mostly on the use of the IVOA identifier.

Identifier
==========

I'm confused by the use of the IVOA identifier in the spec. It seems to
imply that all VOEvents will have unique identifiers of the form used to
identify Resources, and so will all have an entry in the Registry.

I would have thought it more likely that each VOEvent server/database/xxx
would be registered as a resource and the identifiers for each individual
event would be constructed from the resource identifier for the database
followed by a unique identifier within the database (using the Stop
character: see section 3.2.2).

More specific comments:

2.1 Para 1: <<These identifiers are required to begin with "ivo://", and are
meant to stand in for a particular metadata packet, obtainable from a VO
registry.>>

What is a 'metadata packet'? This is the first time I've come across the
term. But an IVOA identifier identifies a VObs *resource*, nothing else.

2.1 Para 3: <<These take the general form "ivo://authorityID/resourceKey",
and are references to metadata packets that may be found at a VO registry or
VOEvent database.>>

Again, the identifier string "ivo://authorityID/resourceKey" refers to a
resource only, the metadata for which can be returned from any full registry
or from the publishing registry (whether it is a full one or not).

2.1 Para 4: <<authorityIDs ... are like domain names on the net>>

No, they are definitely not like domain names. The registry which 'owns' an
authorityID is the one that can change the resource metadata - the authID
means nothing else.

2.1 Para 4: <<each is resolved to exactly one endpoint machine>>

Again, there is no endpoint machine for an authID.

2.1 Para 4: <<resolve the secondary part of the identifier, the
resourceKey>>

Any full registry, anywhere in the world, can return the metadata associated
with a resource identifier, regardless of the authID, and that is all the
registry does: it does not 'resolve' the identifier.

3.2 & 3.2.1: <PublisherID>ivo://uraniborg.hven</PublisherID>

That is not a resource identifier but an authorityID. You might search for
that authID in the registry and it might have a publisherID associated with
it but you'd be better off using a proper resource identifier pointing to a
publisher metadata record.

Other points
============

3.1.3 version:

Why do you need the version number of the spec? Won't that be contained in
the namespace for the metadata elements?

3.3.1 <param>:

What is the point of this element? If it contains real data, shouldn't that
data be part of the schema for the VOEvent? If it is data so specialized
that only a few applications will use it, it ought to go into an extension
schema with its own namespace so that apps can see directly whether they can
handle the data. If it is just extra information that no application will
ever use, why not just put it in as CDATA?

The param element will lead to confusion and errors in applications handling
the data (e.g. if two event source databases choose to use the same param
name for different data) as well as slowing apps down as they have to search
for and interpret text strings that ought to be represented as elements.

3.3.2 <group>:

Same problems as with the param leading to even more errors in applications.

3.7 <citations>:

Does this mean that a retraction has to have a new event ID? If you use the
same event ID as the original event, isn't that likely to lead to errors?


Hope all this helps,

Cheers,
Tony. 

________________________________

	From: owner-voevent at eso.org [mailto:owner-voevent at eso.org] On Behalf
Of Roy Williams
	Sent: 22 June 2005 00:32
	To: voevent at ivoa.net
	Subject: VOEvent working draft published
	
	
	Welcome back to the VOEvent mailing list, it has been quiet for a
while.
	
	During this time, a subset of us has been working hard on the
specification of a VOEvent protocol, and we have converged on the document
that you can find at the URL below. Thanks are due especially to Rob Seaman
of NOAO for acting as referee. We have had considerable discussion and we
really hope that this document will be acceptable (for now) as a IVOA
Working Draft, so that people can build a solid schema and code prototypes
against it.
	
	The document is at
	http://www.ivoa.net/internal/IVOA/IvoaVOEvent/VOEvent-0.94.html
	
	Please try to find time to take a look at the document, and ask
yourself if this protocol is both flexible enough to represent event
announcements and followups, and also simple enough that a computer could
parse it, understand it, and respond to the content.
	
	Send your comments, bugs, typos, ambiguities, and praise either to
this wide group (voevent at ivoa.net) or to the 12 authors of the draft
(voevent-core at us-vo.org).
	
	If we do not hear from you within two weeks (July 5), we will assume
that you are happy for this specification to be accepted at the Working
Draft level, and it will be promoted to version 1.0. 
	
	Thank you
	Roy Williams
	
	
	California Institute of Technology
	626 395 3670