-
Notifications
You must be signed in to change notification settings - Fork 582
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Disambiguation/clarification of source/source-id/source-type #94
Comments
I don't really understand the problem you are trying to solve. I'm having trouble following this series of recommendations, since I'm hearing a critique without a clear statement of how the set of attributes are used together and for what use cases. (This was an issue with the spec before @clemensv arrived, and I really appreciate the focus on detail -- I just want to make sure everyone is aligned on the big picture) |
@clemensv @ultrasaurus i think we only need a single source field which calls out the entity or a proxy which pushed the cloud event, additional source info can be found in the schema. e.g. if there is an S3/Blob update event the source need to be the s3 service, and the source S3 object which pushed the event needs to be in the message body along with other "sources" (users, location, ..). we must keep CloudEvents simple, metadata only describes the "envelop" not the Message itself. dont want us to become yet another Soap/XML/.. |
please see note in issue #82 -- I have the same concern with all of the separate |
@clemensv do you think we can close this one now? |
tagging as "GoingToClose" - so speak before EOD tomorrow if you think we should keep this open |
Closing per WG agreement |
The "source" property is, irrespective of being interpreted as a URI or URL, already an identifier for the source itself. The "source-id" therefore appears superfluous.
However, the present schema does not provide any further context qualification for the event relative to the source, so I am proposing to repurpose the source-id to provide that context qualification. In common messaging APIs and protocols (including the emails stack), the qualification property is called "subject".
Furthermore, with "source" already being a structured identifier (URI) and the event being sufficiently qualified by namespace/event-type and the subject, I question the practical value of the "source-type" property and propose for it to be removed.
Assigned to: @clemensv
The text was updated successfully, but these errors were encountered: