VOEventRegExt

[John Swinbank]

Matthew, all,

On 30 May 2014, at 19:14 , Matthew Graham <mjg at cacr.caltech.edu> wrote:

> Thanks for taking the trouble to give the document a thorough reading. At first pass most of these look reasonable - the document was produced a few years ago and RegWG practices have changed so it's good to bring this in line with current usage.

Given these fairly extensive comments, should we aim for another draft of this document before pushing it to PR?

> Obviously your most contentious proposal is that VOEvent identifiers change from:
> 
> ivo://authori.ty/service/id#local.event.id
> 
> to
> 
> ivo://authori.ty/service/id?local.event.id
> 
> Clearly this needs further discussion within TDIG as it breaks current practice and code and requires an update to the VOEvent spec.

Broadly, I’m sympathetic to the motivations of this proposed change. That said, I’m very leery of trying to push through a VOEvent update and of breaking people’s working code unless we can demonstrate a really tangible benefit to them today: I reckon it would be hard to win much support from the folks actively producing and consuming VOEvents on the basis of the fairly abstract discussion to date.

Is it possible to sidestep the issue for the purposes of this document? The VOEvent specification describes the format of a VOEvent IVORN and describes how to break it down to get a stream IVORN: is it necessary to repeat that in VOEventRegExt? In fact, despite the text in VOERegExt, an event is not "resolved at the registry as follows”; rather, we resolve the stream, find a VOEventServer which carries it, and talk to the that server to resolve the event by some unspecified mechanism. So all this document need describe is how to resolve a stream, and defer to the VOEvent standard as to to the format and meaning of IVORNs. A future VOEvent revision may then rework that without impacting VOERegExt.

Cheers,

John