Does event-type-version apply to the entire event or only the data payload?

[rachelmyers]

Decide and document if the event-type-version attribute is applicable to the whole event or to the data payload alone. Currently, event-type-version covers the data, while open-events-version covers the context.

Assigned to: @duglin

[duglin]

Does "event-type-version" overlap with the event's "schema-url"? Seems like they both tell you how to interpret the "data", no? Perhaps we can remove "event-type-version" and just keep "schema-url"?

[sslavic]

Assuming CloudEvents spec at minimum covers what contextual data will reach serverless function at runtime (so that one can without changing function implementation move the function to different compliant serverless infrastructure, or have it decoupled from the event transport), I'd prefer that event-type-version makes it to the function. Together with event-type and source (producer) identifying properties event-type-version uniquely identifies the even type, and can be used at runtime e.g. for routing to correct function implementation/variant, and single function could accept these properties and handle them appropriately.

Curious are there use cases others have in mind where having schema-url available to function at runtime would be useful.

On the other hand at function development time it would be necessary to be able to lookup event schema and schema/content-type, so something like schema-url and content-type, for given even type identifying data (source, event-type, event-type-version).

[sslavic]

IMO event-type-version applies to data alone.

[duglin]

PR #48 should cover this.

[schatekar]

@sslavic the spec at some point says that both context and data need to be designed such that they can be delivered to the destination independently or together. So it is implicit that everything inside the context will be delivered to the function.