Skip to content
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

Closed
clemensv opened this issue Feb 21, 2018 · 6 comments
Closed

Disambiguation/clarification of source/source-id/source-type #94

clemensv opened this issue Feb 21, 2018 · 6 comments

Comments

@clemensv
Copy link
Contributor

clemensv commented Feb 21, 2018

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

@ultrasaurus
Copy link
Contributor

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)

@yaronha
Copy link
Contributor

yaronha commented Feb 27, 2018

@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/..

@ultrasaurus
Copy link
Contributor

please see note in issue #82 -- I have the same concern with all of the separate source issues

@duglin
Copy link
Collaborator

duglin commented Mar 31, 2018

@clemensv do you think we can close this one now?

@duglin
Copy link
Collaborator

duglin commented May 10, 2018

tagging as "GoingToClose" - so speak before EOD tomorrow if you think we should keep this open

@duglin
Copy link
Collaborator

duglin commented May 15, 2018

Closing per WG agreement

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants