Add some additional design points for ID

[duglin]

Signed-off-by: Doug Davis dug@us.ibm.com

[n3wscott]

If you wanted to replay transactions from a database, you would want to use the commit ID in the cloudevent, otherwise you do not have a method for detecting duplicated events and the ID in the context the cloudevent is irrelevant.

[duglin]

I think commit ID is a valid choice for some cases, however, if that DB commit results in more than one event then it's not a good choice. So, I wanted to avoid getting into those nuances in this section and decided to leave that for the primer. I think UUID is a more clear example.

[duglin]

Given our recent discussions around source and ID, I think this one can be reexamined since I think it's consistent with where we landed.

[duglin]

I made a few very minor changes to this today just to better align with the new definitions of source and producer from @deissnerk. I don't think it changed anything substantial - just made the split between source and producer a bit more clear.

I'd like to see if we can resolve this one on today's call - so please give it a review and comment.

I did a force-push by mistake, so here's the diff of the edits I made for those who want to see just those:

--- a/primer.md
+++ b/primer.md
@@ -155,14 +155,15 @@ of the CloudEvent attributes.
 ### id
 
 The `id` attribute is meant to be a value that is unique across all events
-sent by one particular event producer. While the exact value used
+related to one event source.  While the exact value used
 is producer defined, receivers of CloudEvents from a single
-event producer can be assured that no two events will share the same `id`
+event source can be assured that no two events will share the same `id`
 value. The only exception to this is if some replay of the event is supported,
 and in those cases, the `id` can then be used to detect this.
 
 Since a single occurrence may result in the generation of more than one
-event, each CloudEvent constructed for those events will have a unique
+event, in the cases where all of those events share the same `source`
+attribute value, each CloudEvent constructed will have a unique
 `id`. Take the example of the creation of a DB entry, this one occurrence
 might generate a CloudEvent with a type of `create` and a CloudEvent with
 a type of `write`. Each of those CloudEvents would have a unique `id`. If
@@ -171,7 +172,7 @@ to indicate they are both related to the same occurrence, then some additional
 data within the CloudEvent would be used for that purpose.
 
 In this respect, while the exact value chosen by the event producer might
-be some random string or a string that has some semantic meaning in some other
+be some random string, or a string that has some semantic meaning in some other
 context, for the purposes of this CloudEvent attribute those meanings are not
 relevant and therefore using `id` for some other purpose beyond uniqueness
 checking is out of scope of the specification and not recommended.

[duglin]

Approved on the 5/30 call - with the agreement to make it clear that sources are identified by their CE source attribute value, per @evankanderson's suggestion

I updated the text per Evan's suggestion on the call yesterday. PTAL.

[evankanderson]

LGTM.

Looks good. There are some interesting implications of this, I think.

Anything that causes two events with the same source+id key to have different attributes (differential visibility, middleware) may cause one copy to be lost by deduplication. Something for sources and middleware to consider when emitting events. (And I think the text makes this clear enough, but it does suggest that "transparent middleware" may not be a generally-useful thing.)

[duglin]

thanks @evankanderson
Merging per our last call's agreement .