search

cloudevents / spec

CloudEvents Specification
https://cloudevents.io
Apache License 2.0
5.03k stars 582 forks source link

Based on the description of "namespace", we may just call it "event-producer" or "event-organization" to avoid confusion. #109

Closed cathyhongzhang closed 6 years ago

cathyhongzhang commented 6 years ago

Assigned to: @cathyhongzhang

cathyhongzhang commented 6 years ago

You can assign this to me

clemensv commented 6 years ago

That's a more direct way of expressing one purpose of the namespace scoping: "Who owns this definition?"

Namespace is a fairly established concept, though, and choosing a narrower concept might have downsides. Changing the namespace is a way to break out of a versioning lineage, for instance. I might start out with urn:mything-microsoft-com and version my schemas within that scope, and then I do a complete reset out of that branch and use a new scope urn:mynewthing-microsoft-com.

I view the namespace as more of a disambiguator around my particular structure of events and their structural details (what is an event-type, how is my subject structured, etc) for one context, than as an identifier for my org per-se.

ultrasaurus commented 6 years ago

@clemensv yes, this was a bit clearer when it was a single string. By splitting "namespace" into a separate attribute that introduced quite a bit of confusion

duglin commented 6 years ago

Where are we on this one? Leave "namespace" as-is? @cathyhongzhang ?

yaronha commented 6 years ago

if the namespace specifies the org who defined that event (Schema), why isn't it just part of the Schema string ?

cathyhongzhang commented 6 years ago

If the namespace is not meant to be just an identifier for the org, then the description of it needs to be updated.

duglin commented 6 years ago

@cathyhongzhang perhaps you want to issue a PR to clarify? I'd hold off until after the scope/goals and "what is source" talks wrap up though.

cathyhongzhang commented 6 years ago

Ok

clemensv commented 6 years ago

@yaronha I think of "namespace" as a global disambiguator for how the content of all metadata fields for that event is to be interpreted and to what system scope they relate.

If I'm emitting an event from a particular system, that system will have a certain way to express event identifiers and the source/topic and further qualifiers, and those might be in conflict with concepts from other systems. The "namespace" telegraphs "the content of this metadata follows the conventions from system X". For events from Azure, the source/topic is a fully qualified Azure resource path, and further qualifiers relate to that path. A prefix on the source/topic (a) requires a rule for how that prefix is composed onto that expression without causing parsing issues and (b) doesn't span all related further qualifiers.

The schema is specifically about the structure of the event payload, not about the metadata.

Within a system, e.g. for us within Azure, the namespace distinction doesn't matter, at all. It does matter when you're mixing events from different systems in one system and are interested in interpreting the content of the metadata fields rather than just treating them as opaque fields. For running filter rules over the topic/source field and other metadata fields that are smarter than just a blind regex, having an indicator for what structural convention you're looking at for the metadata will be helpful.

duglin commented 6 years ago

@cathyhongzhang since we've merged namespace into source, can we close this one now?