Are different versions of the same event unique?

Rob Seaman seaman at noao.edu
Thu Mar 29 13:51:42 PDT 2012


Hi Al,

What do you deem broken?  That a single alert payload would have different serializations (or in general differing expressions of any sort)?

Regarding the meaning of "packet", if it is unclear we should address the phrasing in the next version.  While I am personally sympathetic to the notion that the sequence of bytes in two different realizations of a transported alert should be identical, this raises the question of what identical means.  There's the canonicalization issue for signing.  And intervening brokers might perform XSL transformations, etc.  We don't even require that they use the same character set.  In short, we chose XML to use it like XML.  At best identical means isomorphically similar.

One could imagine two different identifiers, one for the content and one for the envelope.  This isn't what we have and I suspect such a proposal would not be quickly embraced.  That being the case, the identifier we have clearly must designate the content whether or not the envelope is constrained to remain unchanged.

So the question is whether publication under v1.1 inhibits republication under v2.0 (or vice versa, or for future version updates).  We already have the ability to issue follow-up packets citing the original.  The follow-up would automatically have a new IVORN, but does this address the issue?  (And who would police it?)

I presume the thought is that when a publisher upgrades to a new version there will always be a lag until all subscribers install corresponding updates.  That being the case, it may be necessary to continue to issue the prior format at least for a transitional period.  This disconnects the client requirements from the server requirements so that updates (for these 24/7/365 systems) can be planned in the first place.  And since the diverse clients may need to synchronize their activities (kind of the whole point), the question becomes whether the v1.1 and v2.0 cohorts call the VOEvents the same thing.

Rob
--

On Mar 29, 2012, at 1:17 PM, Alasdair Allan wrote:

> 
>> However: I don't think this is clear from the VOEvent standard. It tells us that an IVORN is used to resolve a particular "VOEvent packet", and (although I'm not sure it's plainly stated), my reading is that a "packet" is a specific representation, rather than the information contained within. In other words, while I agree with the views expressed here, I certainly don't think the answer is necessarily immediately obvious.
> 
> It 's a fair point. Which leads us to why anyone would want to do something this fundamentally broken in the first place?
> 
> Al.



More information about the voevent mailing list