Default value section misses op default for Thing

[danielpeintner]

The Default Value Definitions section specifies default values for forms and differentiates between:

• If defined within an instance of PropertyAffordance
• If defined within an instance of ActionAffordance
• If defined within an instance of EventAffordance

It misses the default value for the Thing itself which may have forms also.

[benfrancis]

I note that this is missing from v1.0 as well*.

What would be a sensible default op for a top level Form?

I don't think it can just be ['readallproperties', 'writeallproperties'] or ['readmultipleproperties', 'writemultipleproperties'] because:

1. What if the Thing doesn't have any properties?
2. We also now have meta operations for actions and events

One option, which would help solve the WebSocket use case described in #1192 (comment), would be for the default to be "all". That is to say that if op is not defined then all operation types are assumed to be supported using the same endpoint.

That might have to be refined to say that:

1. Property operations only apply if the Thing has properties
2. Action operations only apply if the Thing has actions
3. Event operations only apply if the Thing has events

Would this only include the meta operations readallproperties, writeallproperties, readmultipleproperties, writemultipleproperties, observeallproperties, unobserveallproperties, queryallactions, subscribeallevents, and unsubscribeallevents? Or would it also include single affordance operations including readproperty, writeproperty, observeproperty, unobserveproperty, invokeaction, queryaction, cancelaction, subscribeevent and unsubscribeevent?

Note that in the WebSocket use case mentioned above, and the use cases & requirements of the Web Thing Protocol, it may be possible to carry out single affordance operations using a single connection which is shared between multiple affordances, e.g. an invokeaction operation via a shared top level WebSocket endpoint. That's probably a separate issue, but it may influence the chosen default.

---

• This has made me wonder, are members which have the "with default" assignment actually mandatory? Or does it just mean that if they are undefined then a default value can be assigned from the Default Value Definitions table, but if none of those criteria apply then it remains undefined? I note that the informative JSON Schema treats them as optional. But even if "with default" members are not mandatory, it's still ambiguous what a top level form with no op member means, so I think it would still be helpful to define a default as above.

[egekorkan]

I don't think that there can be default values for op in the Thing level since it actually means a separate endpoint most of the time.

[benfrancis]

@egekorkan wrote:

I don't think that there can be default values for op in the Thing level since it actually means a separate endpoint most of the time.

That does make sense for the most common use cases, but doesn't explain what a Consumer should do if it comes across a top level form with no op member. Or is op considered mandatory for a Form at the Thing level, with no default? That would mean that if a shared endpoint does support all operation types then it would have to explicitly list them all. If that's the intention then that's fine, but none of this is defined in the current text.

[egekorkan]

Or is op considered mandatory for a Form at the Thing level, with no default?

I think it should be fixed to this.

[egekorkan]

I have added v1.1 label but this implies a new assertion and we might be too late