Open thjaeckle opened 2 months ago
Welcome back @thjaeckle !
Your example is not conforming to the first assertion but conforms to the second one. The second TM should not have the same affordance in the first place. For your use case, using tm:ref
would be the only allowed solution I think. It can result in way too many tm:ref
but it would be correct.
If that is not good for you, we can open the discussion to make the extension mechanism more tolerant. In that case, we will probably need a use case description from you.
Thanks for the quick feedback @egekorkan (as always I would say :)).
So to summarize: It is not recommended (but not forbidden due to SHOULD NOT
) that a single affordance "overwrites" an affordance inherited via tm:extends
, even in a "compatible" way so that the child affordance is still valid to the parent affordance?
This I would understand from:
A Thing Model SHOULD NOT overwrite the JSON names defined within the properties, actions, and/or events Map of the extended Thing Model.
However - it still can (because only SHOULD NOT
) - and then this applies?
Definitions SHOULD NOT be overwritten in such a way that possible instance values are no longer valid compared to the origin extended definitions.
As the example in Figure 6 provides exactly such an example for a property
named "dim"
, I assume this should ;-) also work for actions and events.
Good points and my first comment can be ignored. In that case, your question would the 2nd TM "Black magic performing Thing Model" also "inheriting" the "input" and would its "output" contain properties from the extended model merged with the own defined properties?
has the answer yes. The only issue I see there is the required
array. Should the final td contain "required":["blackMagicApplied","result"]
? The initial thinking says yes as the figure 6 in the spec gives the message that the data schema can become less restrictive and not more restrictive, i.e. min 5, max 95 becoming min 0 and max 100 is allowed. In your case, result key needs to be there so that the past values are not becoming invalid.
In any case, the spec should define more clearly what is a less restrictive extension and what is a more restrictive one.
The only issue I see there is the required array. Should the final td contain
"required":["blackMagicApplied","result"]
?
Yes, I would also expect that .. Only that way, you could correctly validate the JsonSchema of the resulting TD action "output".
Yes, the spec leaves some "room for interpretation" here. But the good thing is, that the concept should still work without having to copy/repeat information from the extended model.
So I think that the "simple" part of this question is answered (let us know if not @thjaeckle). Looking at the bigger picture, the point " the spec should define more clearly what is a less restrictive extension and what is a more restrictive one." is important, which relates to the following points:
Hi WoT folks. 👋
I ran into a question regarding extension of ThingModels which I could not find answered in the 1.1 TD specification. How exactly are
actions
andevents
"extended"?The specification states:
and:
But for me it is not quite clear, if e.g. "input" not specified is "copied" to the extending model. Or if the "output" should be "merged" with the extended "output".
Or, if "input" and "output" explicitly must be copied to form a "valid TM action".
Example:
Example TM extending from the above:
In the example above, would the 2nd TM "Black magic performing Thing Model" also "inheriting" the
"input"
and would its"output"
contain properties from the extended model merged with the own defined properties?