Add schema url to the meta object

[e-backmark-ericsson]

Description

To be able to correctly parse the event data it is critical to know exactly what version was used when creating it. We already have the mandatory meta.version property which should cater for this. For convenience we should also have the possibility to provide an immutable url from where the schema used when creating that event can be fetched. I propose to add an optional meta.schemaUri for this purpose.

meta.schemaUri

• Type: String
• Format: URI
• Required: No
• Description: A URI pointing at a location from where the schema used when creating this event can be retrieved. The schema on that URI should be considered immutable.

Motivation

Event consumers can retrieve the schema used for creating the event, to be used for validation, parsing and extraction purposes.

Exemplification

meta.schemaUri = "https://mySchemaHost.com/schema/EiffelArtifactCreatedEvent/versions/3.1.0"

Benefits

Easier for event consumers to parse the event data. No need to locally store copies of event schemas in each consumer.

Possible Drawbacks

As it is optional there should be no drawbacks

[e-backmark-ericsson]

This is how schema uri's are defined for Cloudevents: https://github.com/cloudevents/spec/blob/master/spec.md#dataschema
A difference between Cloudevents and Eiffel events is that Cloudevents has a generic top level meta layer, and the dataschema is only used for the data sub object within the event.
If we should be fully aligned with that, the Eiffel schemas should be divided into a hierarchy of two different event layers. One representing the meta part and one representing the data sub object (and the links object?).

[ebopalm]

It should be mentioned in the Description section that the reason for this proposal is not just a convenient factor or event versioning matter as much as a need to refine the implementation/usage of the Eiffel protocol aka. Protocol Profiling.
In order to use Eiffel Protocol for M2M applications, a clear definition of the event content is needed, evolving the existing, flexible schema definition into a more strict protocol with support of a schema definition. The schema definition itself should also be constructed in a hierarchical way, indicating different levels of "strictness" to support "Protocol Negotiations" between peers that exchanges Eiffel Events for collaborative purposes. aka. Multi-Vendor Pipelines.
Further more, the support for Protocol Profile compliance should also include the possibility to add the identifier(Id) and verification(Signature) possibility of the entity that claims an event is compliant, as the compliance checking is likely made on custodian basis for either the Event Producer or the owner of the Eiffel Domain in question.
The suggestion to use a URI to refer to a Schema might be a good thing, but the example is actually a URL-format. When we design a protocol, care should be taken to refer to potentially moving targets outside the control of the Eiffel Protocol as it can render large portions of Events in a stale state. Instead, a clever URI reference with emphasis on Identification should be promoted possibly followed with an Indicator on how to resolve the URI into a URL.
Final note; I find the suggestion to differentiate the Meta and Data part in terms of Protocol Profiling a good suggestion. It enables the peers to focus on the essential part of Event handling but also takes a step further towards clarifying the Meta object as an object of its own, aggregated with each different Data Object to form an Event.

[e-backmark-ericsson]

Oh. URI or URL. Well, there seems to be some confusion on that allover the place. We probably most often expect a URI to also be a URL, i.e. an identifier that also tells you how to get hold of it. We've however used URI allover the protocol until now, so I think we should stick to that.
https://danielmiessler.com/study/difference-between-uri-url/

[m-linner-ericsson]

👍