A TD should be able to define which `Properties` are `required`

[thjaeckle]

I did not find a "required" definition for Property Affordances, is that correct?

I would like to define which properties must always be present (required) in a TD and which ones are optional.

I would have expected that this exists, because a Property Affordance is in my eyes almost the same as an ObjectSchema where required properties may be specified, reusing the JsonSchema required.

I found that for ThingModels there was tm:required added, however for ThingDescriptions the possibility of defining required/optional properties does not exist.

Or did I overlook something?

[danielpeintner]

Or did I overlook something?

No, I don't think there is anything like that. I think what you envision to see is a required arrays in the spirit of JSON schema.

Having said that, I wonder what is the use case for that. A TD, at least for me, should describe the actual device and contain only properties/actions/events that the thing can fulfill. Having interactions that may (or may not) be supported makes it more more complex to deal with.

Do you have a specific use-case in mind?

[thjaeckle]

Seems inconsistent to me if you can e.g. define a JsonObject property in which you can use the required marker to define required and optional fields inside the JsonObject, but you can't do that one level above ..

One use case coming from our Eclipse Ditto / digital twin pattern (where the cloud delivers the TD and reflects the latest reported state by the device): A device integrator may choose to model a property "onlineSince": "<timestamp-in-iso8601>" or "connectedUntil":"<timestamp-in-iso8601>" - both may be either present (if the device is currently "online") or not, e.g. the device could delete them as "last will" when disconnecting via MQTT.

[egekorkan]

From my point of view, I also do not understand the use case entirely. If a TD exists, it is for a concrete device that already exists. In the case of MQTT example above, the TD should have both properties and the Consumer will get them if they are published. There is no guarantee that even a temperature value will be published by the Thing if it exists in the TD. I sort of see the problem that all properties' values may not be always available but this is not about a Thing having the property or not but more the value of that property not being available. We can add some annotations to indicate whether the property affordance represents a value that is always available or not, a bit like the safe and idempotent level of annotations we have for actions.

[thjaeckle]

We can add some annotations to indicate whether the property affordance represents a value that is always available or not, a bit like the safe and idempotent level of annotations we have for actions.

That would of course work - I understand that using the JsonSchema required is a little difficult, because it would have to be defined next to properties which would be on top-level.

Thinking about another use case: a Thing could expose its "currentErrorState" as property - which in the best case is absent, but only is present if there is an error state.

These are use-cases we see in Eclipse Ditto how Things are modeled. Maybe annotations like nullable or required would help.

[sebastiankb]

from today's TD call:

• there are some open questions such about what happen if there are multiple forms entries
• maybe additionalResponses can be an alternative to define different schemas based on the possible responses
• discovery uses this approach

[thjaeckle]

I agree that adding required is not really needed and that using the "additionalResponses" also perfectly works if e.g. a property can not be provided.

I however am a little puzzled about the Thing Model tm:required then .. Does this mean that the generator of the TD (based of the TM) only needs to add the required interaction affordances to the generated TD? The others would be missing from the TD, even if they "could" still be available on the instance described by the TD?

So what is the background of the tm:required if this does not match to a concept in the TD but just skips non-tm:required elements?

[egekorkan]

The others would be missing from the TD, even if they "could" still be available on the instance described by the TD?

I do not really understand this.

From my understanding: We can have a TM for a light switch and if you want to say that your TD represents this light switch, it should at least have (the required), let's say, a toggle action. The TM can contain however an adjustable toggle action that allows to set brightness of the light and this is more like an optional feature.

[relu91]

From my understanding: We can have a TM for a light switch and if you want to say that your TD represents this light switch, it should at least have (the required), let's say, a toggle action. The TM can contain however an adjustable toggle action that allows to set brightness of the light and this is more like an optional feature.

That's my understanding too. Maybe what is confusing is the fact the default is that everything is optional.

[thjaeckle]

From my understanding: We can have a TM for a light switch and if you want to say that your TD represents this light switch, it should at least have (the required), let's say, a toggle action. The TM can contain however an adjustable toggle action that allows to set brightness of the light and this is more like an optional feature.

@egekorkan I think I start understanding why we think different here. You (and probably also the spec) assume that the generator of the TM->TD somehow "knows" which affordances the device supports. And that should be true if the TD is provided by the device itself. However in my case, a "digital twin" platform generates and provides the TD for a device without knowing anything about the device. So I have to assume that I provide all of the interaction affordances from the TM into the created TD. That's why I don't have a need for the tm:required at the moment.

In the end, the device can still decide if it e.g. supports invoking an action by returning an error when it is invoked.

That's my understanding too. Maybe what is confusing is the fact the default is that everything is optional.

@relu91 I also think that a better default would be that everything is required and optional parts can be specified explicitly.

[egekorkan]

@relu91 I also think that a better default would be that everything is required and optional parts can be specified explicitly.

I would also say that this is more intuitive.

[relu91]

Also if everything is an option by default it means that any TD implements any basic TM (assuming that most developers will forget to add the required keyword). This would force the application to check every time the existence of a particular TM feature (e.g., a Property affordance status with a string data schema) making TMs almost useless. I know that JSONSchema is using the same approach but it now feels a little bit problematic.

[danielpeintner]

I am still not seeing the problem in the first place.

IF a TD has a given set of properties (or also actions and events) my assumption is that the interaction exist. IF a device does not have a given property the TD is not in-sync.

Do we really want to have the discussion that some interactions are optional?

[thjaeckle]

@danielpeintner you also assume that the TD is provided by the device - which is e.g. not the case for when a digital twin platform generates TD based on TMs for the devices already connected to that digital twin platform. -> Which is exactly my use-case ;)

[danielpeintner]

I see, but does it help if an implementation knows that a certain property is optional? I think an implementation has to deal with such issues anyway... no matter whether a property is marked as required or not. But maybe I miss anything?

[thjaeckle]

@danielpeintner you're right I think the discussion drifted away from marking that properties shall define if they are "required" or not:

• I would now also say that this is not required

The discussion ended in whether providing tm:required in ThingModels is a good idea or not - and that (maybe) the default shall be that all affordances of ThingModels are "by default" required in TDs following a TM. And that something new like tm:optional could mark the really optional ones.

Shall we create a new issue for that TM discussion? Shall we close this issue - FMPOV this would be ok to close as "won't fix".

[relu91]

Shall we create a new issue for that TM discussion? Shall we close this issue - FMPOV this would be ok to close as "won't fix".

Yeah, I think it might be better to move the discussion about TM somewhere else.

[egekorkan]

Given that @thjaeckle has added the propose closing label and #1400 is open, the discussion should continue there