A schema (constraints) for context and data attributes identified by schemaURL

[dmigliori]

Many of the context attributes (e.g., eventType, source, eventID, contentType) are not tightly constrained to maintain flexibility in specific implementations. However, as noted in the intro to the spec "event publishers (producers) tend to describe events differently. The lack of a common way of describing events means developers are constantly re-learning how to receive (consume) events." Loosely constrained attributes will not effectively address this key problem.

The spec currently describes the schemaURL attribute as "a link to the schema that the 'data' attribute adheres to". Suggest that this be broadened to "a link to the schema defining further constraints to context and data attributes" Thus, a single schema can ensure semantic interop of context attributes between event producers and consumers within a specific domain or ecosystem - not just data.

Further, suggest that the schemaURL and cloudEventsVersion attributes are "schema attributes" that describe the "context and data attributes" and should not be included as "context attributes" describing the occurrence (data).

[dmigliori]

This dovetails open issue #108

[duglin]

@dmigliori what are your plans for this one?

[dmigliori]

I propose a PR based on this issue to accommodate the concerns addressed in #307 and #326

[duglin]

@dmigliori what's the status of this one?

[dmigliori]

@duglin I still think this is a valid issue. For example, in the KubeCon Europe demo of supply chain event management, the Topic, Subject, and Data attributes conformed to a specific schema that aligned to an airport/commerce ontology (ACRIS/schema.org). I think this schema needs to be specified somewhere in a CE message header, as CE can be implemented to support various schemas that further constrain CE attributes (e.g. making optional attributes required).

[duglin]

@dmigliori when you say "schema" can you elaborate a bit on how receivers will use that info? I'm trying to mentally walk through how a receiver of an CE would process the incoming event:

• I would think the first thing they would look at would be either the source and/or type to determine if this event is of interest to them. source obviously would be of interest if they only want events from certain event producers.
• type is probably pretty close to the schema thing you're looking for. While it's not as formal as the schemaURL where it might point to a spec defining things, it's value is meant to be pretty unique/unambiguous about what the payload is meant to carry, at least from a semantic perspective.
• then we have things like the schemaurl which are interesting in cases where the type might be represented in more than one way

So, with all of that, are you asking for a single value that allows for a receiver to know, for example, that this event adheres to the "xyz data model" ? Could that not be encoded in the type ? E.g. type=org.xyz.???.
For example, if you look at: https://github.com/cloudevents/spec/pull/441/files#diff-e75d0b15ae81f9c4edeefb8d9c52fd80R18
it shows that the type is prefixed with com.amazonaws.s3 I think might express what you're looking for, no?

[dmigliori]

@duglin I'm suggesting to change to the description of the schemaURL attribute from:

"A link to the schema that the data attribute adheres to."

to:

"A link to the schema that further defines constraints for the values of one or more of the following attributes: id, source, type, subject, time, and data"

This would allow multiple event formats to be supported under the umbrella/generic CloudEvents schema. For example if schemaURL was set to "https://www.gs1.org/standards/epcis", both producers and consumers of EPCIS events would know how to include EPCIS-specific elements within CloudEvent attributes. Further, the schemaURL could specify that certain optional CloudEvent attributes are required (e.g. time). I don't see a reason why the schemaURL needs to be limited to just the "data" attribute.

[duglin]

Interesting. Would you be ok with a slight wording change?

"
This is a link to a schema that the data attribute adheres to. However, the schema MAY also include constraints for any other CloudEvents attributes - as long as those constraints do not conflict with this specification.
"

I think it's important that we retain the idea that this value's main purpose in life is to define the shape of data. The fact that the schema it points to might also talk about other CE attributes is just icing on the cake to me. I'd like to avoid the hint that we're demanding people come up with new schema just because of CE. So to me this is just making it clear that people CAN extend the scope of this attribute if they want to.

WDTY?

[dmigliori]

@duglin that works. will you draft a PR?

[duglin]

@dmigliori done: #465