Are the "eventTime"and "data" attributes really optional?

[dmigliori]

In the Terminology section of the spec, "Events will contain two pieces of information: the Data representing the Occurrence and extra Context metadata providing additional information about the Occurrence." Yet within the Context Attributes section, the "data" attribute is designated as Optional.

Further, an Occurrence is tightly coupled to a point in time. Yet within the Context Attributes section, the "eventTime" attribute is also designated as Optional.

I believe a timestamp ("eventTime") and value ("data") are the basis of all time series and event data.

Further an "eventTime" value has global cross-domain meaning, whereas an "eventID" value may have meaning only to the event producer, yet the "eventID" attributed is designated as Required while "eventTime" is not.

[erikerikson]

RE: data - An event could represent a binary sensor being activated, indicating that it was triggered but not carrying any meaningful data beyond that. In such a case sending the event is sufficient and there is no data collected to send.

RE: eventTime - while commonly sent, it is not always desirable to trust clients to supply timestamps. This is particularly the case when clients can be malicious. Due to clock synchronization difficulties even when clients or servers can generally be trusted including a timestamp with a message can be considered misleading and encouraging of abuse. As a result there are principled cases where timestamps are avoided.

[dmigliori]

RE: data - An event representing a sensor being activated can have a data value representing an enumerator of the sensor status (activated). I believe every event should have a data value for consistency and simplicity in consumption - even if it's the status of the sensor/device or sales order.

RE: eventTime - I expect that the values of all context attributes need to be equally trusted - not just timestamp. Timestamp is the fundamental context attribute for a state change event. A consumer will not trigger an action without it - as it would have no way of knowing if the event occurred 10 years ago or 10 seconds ago.

[cneijenhuis]

An event of type com.example.FileDeleted or com.example.CommentDeleted does IMO not have a need for a data attribute (if it has a descriptive source attribute).

There are many examples where a listener will fetch the current state anyway. E.g. a PR-checker on GitHub will always checkout the up-to-date branch, even if it receives an event pointing to an outdated commit. It doesn't depend on the timestamp.

[dmigliori]

An event representing object deletion can have a data value identifying an enumerator of the object status (deleted). That said, it makes sense to define loosely constrained (e.g. optional) context attributes within the CloudEvents spec to maintain flexibility while allowing a referenced schema (via schemaURL) to add a layer of additional constraints (e.g. required) which simplify interpretation by event consumers within a specific domain or ecosystem. This is proposed in issue #308.

Any context attribute that is designated as Required within the CloudEvents spec (e.g. eventID) should have a reasoning included within the description of the attribute.

[dmigliori]

Also, if "data" is to remain optional, then the following in the Terminology section needs to be reworked:
"Events will contain two pieces of information: the Data representing the Occurrence and extra Context metadata providing additional information about the Occurrence."

[erikerikson]

@dmigliori - you keep saying "can" but there's a lot of space between can (what you are saying) and must (what you are advocating).

Perhaps it would be more productive if you explain the negative consequence(s) you expect to result from a CloudEvent not having a data attribute?

What concerns would making it required address?

[duglin]

re: "Events will contain two pieces of information... - I think a PR to change "will" to "can" to make it even more clear that its non-normative, wouldn't hurt, IMO. But I also fear a rat-hole wordsmithing exercise on this one :-) when I think most people already get our intent.

[Humancell]

RE: eventTime - I wanted to throw in my request that eventTime remain OPTIONAL for the following reason. We have a groups of sensors and sensor infrastructure products that already emit JSON similar to this, and we want to adopt this format. With our sensors we have already had to deal with the issue of eventTime for years. Remember that many of these are extremely low powered, can be battery operated, and go to deep sleep between generating events. There are three scenarios we have with these embedded devices.

1. They have an RTC and can easily get time - but at additional hardware cost. This is a small percentage of our products. It's an option to the customer, and most go for cost.
2. They can make NTP requests, and attempt to get the real time. This is available in a larger percentage of products, but is not 100% guaranteed. If there is no response after limited NTP retries, we still might not have the time. In a battery powered embedded device we can only spend so much time/power.
3. They are in secure environments with firewalls (medical/HIPPA environments, etc.) or simply no Internet connectivity to get to an NTP server. In this case we just can't get the time.

In our endpoints, if the eventTime field is not present, the receiver has the option of what to do with the event. They could choose to discard it, or add a timestamp for when they received the event, or simply use it as it is.

RE: data - I agree with the comments so far, as the event and source can often be enough.

[duglin]

@dmigliori what's the status of this one?

[dmigliori]

Commenters provided valid reasons why these attributes should remain optional to accommodate specific use cases / implementations. I believe there are also valid reasons why other attributes (e.g. EventID #326 ) should be optional, rather than required. #311 proposed expanding the scope of a referenced schema to further constrain optional attributes (e.g., make required) for a specific implementation.

This issue 307 can be closed.

[duglin]

Closing per @dmigliori's request