initial draft of a "common constraints" section

[mlagally]

---

Preview | Diff

---

Preview | Diff

[benfrancis]

What's the difference between this section and the WoT Core Data Model section which already defines such constraints? Is the intention that these constraints would apply to all profiles, and if so why?

[mlagally]

What's the difference between this section and the WoT Core Data Model section which already defines such constraints? Is the intention that these constraints would apply to all profiles, and if so why?

Yes, the common constrains section should be removed from the core profile and be common across different protocol bindings to address the cross protocol interop use case.
If we define the core profile without common grounds and guarantees, we won't be able to achieve interop with other profiles later.
This new section will replace the core data model section, which you wanted to eliminate anyways.
It will be completely rewritten, so we should focus on the parts that are important to include.
Discussing details of the previous core data model chapter - which was very much written with small embedded devices in mind - will slow us down.

I suggest we have a focused conversation when the common constraints section has some contents.

[sebastiankb]

If I understand it correctly, it's about finding something that would meet a very constraint device profile to a large enterprise system profile, right?

[mlagally]

If I understand it correctly, it's about finding something that would meet a very constraint device profile to a large enterprise system profile, right?

No, not really. It will be defining common constraints across protocols. Examples include:

• limiting the number of forms per interaction affordance to 1
• limiting the number of forms at thing level
• mandating version info
• time format clarifications
• clarifications on units
• clarficiations on security schemes, e.g. excluding NoSec

[benfrancis]

I don't think that a Core Data Model section is really necessary, but I feel even more strongly that there shouldn't be a Common Constraints section.

I'm afraid that I disagree with every one of the example constraints you have provided, but that hopefully shouldn't come as a surprise. I have already provided extensive feedback on most of them in #93 (review) as constraints in the Core Profile (which you still haven't responded to), but these make even less sense as constraints which apply to all profiles.

• limiting the number of forms per interaction affordance to 1

This prevents Things from conforming to more than one profile.

• limiting the number of forms at thing level

I think this one is new, but I can't think of any justification for doing this except to annoy developers.

• mandating version info

Why? How does this help interoperability? If version metadata is so important that it should be mandatory in all profiles, then it should be mandatory for all Thing Descriptions. I suggest you file an issue in the Thing Description repo and make your case there.

Edit: On an architecture call @mlagally said that by version info he means the version of the Thing Description specification. I noted that this is already provided by the @context URI.

• time format clarifications

This one arguably makes sense as part of the Core Profile, but is far too restrictive if applied to all profiles. What if someone creates a profile with a protocol binding for an existing protocol which can only represent times and dates in a certain format?

• clarifications on units

What kinds of clarifications? See #29 for the issues on selecting a single ontology that works for everyone. That would be significantly more problematic if applied to all future profiles, which may have specific requirements or include protocols which use their own unit ontologies.

• clarficiations on security schemes, e.g. excluding NoSec

I don't agree with excluding NoSec. There are perfectly valid use cases for an unauthenticated Web Thing and this constraint would prevent all 16 WoT Producer implementations in the WebThings Framework from being compliant.

Apart from the above objections, we are only defining a single profile in v1 of WoT Profile so I think it is premature to try to extract out any common constraints that apply to all profiles as we simply don't know what profiles may exist in the future. Having two sets of constraints for the Core Profile (its own set, plus a "common" set) adds an unnecessary layer of additional complexity at this stage.

If we define the core profile without common grounds and guarantees, we won't be able to achieve interop with other profiles later.

I don't see how direct interoperability between profiles is possible. Bridging from one profile or protocol to another is always going to require some kind of gateway or adapter to translate from one to the other.

It will be completely rewritten, so we should focus on the parts that are important to include.
Discussing details of the previous core data model chapter - which was very much written with small embedded devices in mind - will slow us down.

I agree with starting with a blank slate, but I suggest focusing on re-writing the Core Data Model section with a drastically reduced set of constraints first, following the plan I proposed in #125 (comment)

[mlagally]

Add to the ednote: Or remove this section if it remains empty