EventAffordance: rename data and dataResponse to message and messageResponse

[mlagally]

The term "data" is very generic and non-descriptive.

Since the event subscription is providing messages and corresponding responses, the name should be changed.

[relu91]

I'm ok with the change, but I wondering if "message" isn't too protocol-oriented. We could also evaluate event and eventResponse.

[relu91]

Ops, I've almost forgotten. Sadly, changing data to message or event would break backward compatibility.

[mlagally]

@relu91
event and eventResponse would also be way more descriptive, so +1.

Wrt. backwards compatibility: we could preserve "data" fand add the new vocabulary terms, stating that bata and event MUST have the same value.

[egekorkan]

What is the rush? I would propose to wait for TD 2.0 for doing such a change with names (no matter what is chosen for the actual new word). If we have two words, TD 1.1 consumers need to be able to understand both of these words, which increases implementation effort for Consumers. It also means testing yet another thing and again last minute...
We have declined to introduce such double possibility mechanisms in TD1.1 like inline security definitions #945

Regarding the name, I also think that data is a bit ambiguous, everything is data in the end. Regarding message, I think that it is also a bit ambiguous since both directions are messages. Regarding naming it as event, I find it a bit weird due to an event affordance having an event. Do properties have property and actions have action? Some alternatives that come to mind without a strong preference for one: payload, emission, emit, eventData, eventPayload, output

[egekorkan]

Call of 23.02:

• The group wants to postpone this discussion to TD2.0
• This is an issue that involves other affordances in some way. Maybe a bigger overhaul of all affordance DataSchemas
• No matter the change, we should be aware of the implications of this change.