EventAffordance cannot describe contentType of event messages

[hrennau]

EventAffordance: the contentType of the event message pushed by the Thing cannot be described, as the "op" value of the forms in an EventAffordance must be either "subscribeevent" or "unsubscribeevent". The content type specified by a form thus necessarily refers to a "subscribeevent" or an "unsubscribeevent" request - it cannot describe the event message.

Proposal:
Extension of the information model: class Event has a new name-value pair "event" (in analogy to an ActionAffordance's "response"). The value is an instance of a new class "ExpectedEvent" with the same signature as "ExpectedResponse".

Alternative proposal:
Extension of the information model: class Event has a new name-value pair "event" (in analogy to an ActionAffordance's "response"). The value is an instance of a class "Message". This is not a new class, but the result of renaming class "ExpectedResponse".

To illustrate the problem, consider also example 34, where we have an EventAffordance with a single form, which specifies contentType “text/plain”. As there is no "op" name-value pair, the default value applies, which is “subscribeevent”. As there is no “subscription” name-value pair, the message is without payload, and the contentType “text/plain” thus refers to a "subscribeevent" message without payload. The intention, however, was probably different, as the affordance's "data" name-value pair provides an integer data schema. The "text/plain" seems to be intended for the event message containing an integer number.

[egekorkan]

I like the first proposal. However, I think this might be a too big of an addition for the current TD version.
Another proposal would be to rename ExpectedResponse to something else since the word response does not really fit to an event being received. I can only think of ExpectedContentType at the moment since it has to be able to mean the response of an action invoke or an event delivery.

[hrennau]

Let me clarify to avoid misunderstandings, as you speak of "too big an addition". I think we NEED an additional name-value pair in class EventAffordance, as otherwise the contentType of an event message remains undescribable. This would be a bug of the specification.

What remains to be decided is the value type of the new name-value pair: either a new class à la ExpectedResponse, or a generalization of ExpectedResponse, which is achieved simply by renaming the class. (I do not know which change would be "bigger" - probably the renaming.) A third possibility appears to me inferior: have a new name-value pair "eventContentType", which provides the event contentType as a string, not an object. Inferior for two reasons: (1) There is no way of accommodating further communication metadata, e.g. protocol binding specific metadata; (2) lacking consistency, as the same problem emerging in two types of interaction affordance would be solved in two different ways (I mean the problem how to express communication metadata for a further, non-request message).

The name you proposed, ExpectedContentType, would appear to me an unfortunate choice, as the whole idea of wrapping the contentType information in an object is that it might be accompanied by other name-value pairs, which would contradict a name restricted to contentTypes.

[egekorkan]

For the record, after looking at the inputs for the implementation report, I see that 3 TDs use the response. These are listed below:

• responseTest-siemens.json from Siemens node-wot implementation that suggests that this was added to show that node-wot supports this.
• intel-inference.json and intel-camera.json by Intel that from what I remember are actual devices.

Also I do agree that this is needed and that we would have something that we cannot describe.

[sebastiankb]

Please be aware that the response name-value pair is a member of the Form class and not only applicable for Action definitions. That means, response can be also applied in event based definitions.

Please also consider the requirement from the spec:

The optional response name-value pair can be used to provide metadata for the expected response message. With the core vocabulary, it only includes content type information, but TD Context Extensions could be applied. If no response name-value pair is provided, it MUST be assumed that the content type of the response is equal to the content type assigned to the Form instance. Note that contentType within an ExpectedResponse Class does not have a Default Value. For instance, if the value of the content type of the form is application/xml the assumed value of the content type of the response will be also application/xml.

Maybe the generic name is not so perfect for an event-based context, but from my point of view it is possible to describe contentType of event messages.

[hrennau]

Oh yes, you are write in reminding me that the response name-value pair is a member of the Form class - my proposal would amount to an inconsistency, as message metadata would in one case be expressed by a form, in the other case by the containing affordance. And it is the form, by definition, which should take care of message metadata and control data.

But the criticism remains valid for several reasons.

First, the documentation of "response" says:
"The response name contains metadata that is only valid for the response messages."
Event messages are not response messages. If the "response" name-value pair is intended to describe event messages too, the spec should be explicit about it.

But editing the explanation does not solve the problem. A subscribeevent request can have a response, so the "response" name-value pair obviously describes that response. As it does not make sense to assume that response message and event message have the same communication metadata, the "response" name-value pair cannot describe both, response and event message.

I propose to extend the Form class by an additional name-value pair "event", with a value as described in the original posting.

PS: An interesting aspect of the new "event" name-value pair is also the possibility to select the content type of event data - done by selecting a form where "event" has the desired content type.

[sebastiankb]

I see you point. I will discuss this in our next meeting during TPAC next week. I let you know.