TPAC summary and Proposed wording to explain the concept of "Bindings extend, Profile restrict"

[lu-zero]

During the TPAC we had enough consensus along the lines of "Bindings extend, Profiles restrict"

My initial draft takes from the Binding Templates introduction:

Binding Templates enable a Thing Description to be adapted to a specific protocol, data payload formats or platforms that combine both in specific ways. A Profile warrants that only the Binding Templates it mandates, or a subset of them, will be used to describe all the Affordances exposed by a conforming Thing.

[egekorkan]

The initial rewording proposal from Siemens:

Binding Templates enable a Thing Description to be adapted to a specific protocol, data payload formats or platforms that combine both in specific ways. A Profile document contains only a subset of features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.

[benfrancis]

Hi Luca,

Luca wrote:

"Bindings extend, Profiles restrict"

First of all, I agree with this high level concept.

Regarding the text you have proposed, what is it for? A resolution? New specification text? And is this definition meant to apply from Profiles 1.0 or Profiles 2.0?

Note that we refined the Introduction of the specification back in June to provide a clearer description of what profiles are for.

See an extract below:

The Thing Description specification includes a number of extension points including protocol bindings, payload bindings, security mechanisms, link relations and semantic contexts... This specification is designed to complement the Thing Description [wot-thing-description11] specification, by enabling ad-hoc interoperability through the use of "profiles". A profile prescribes a finite set of extensions and defaults that a Thing can be constrained to in order to guarantee out-of-the-box interoperability with any Consumer which implements that profile.

I don't think either your proposed text or the one suggested by Sebastian really captures this.

Luca wrote:

A Profile warrants that only the Binding Templates it mandates, or a subset of them, will be used to describe all the Affordances exposed by a conforming Thing.

Protocol bindings and payload bindings are only two of the five (six if you include discovery mechanisms) extension points which need to be constrained in order to guarantee out-of-the-box interoperability between a Thing and a Consumer.

Sebastian wrote:

A Profile document contains only a subset of features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.

I think I agree with the point you're trying to make, but I don't think it's quite accurate to say that "A Profile document contains only a subset of features of the Thing Descriptions specification". What a Profile should do is constrain the extension points of the Thing Description specification to a finite set of extensions, and require certain defaults to be observed.

E.g. a Profile probably wouldn't say "a Thing Description must not contain a @context member", or "a Thing Description can describe properties but not actions and events" or "a Thing Description can have numerical properties but not boolean properties", or "a Thing Description can have a title but not a description", or "a Thing Description can not contain links", or "a Thing Description can not use Thing Models".

However, a Profile might say "a Thing conforming to this profile must provide an HTTP protocol binding and conform to the defaults defined in the HTTP Binding Template" or "a Thing conforming to this profile must provide payloads serialised in JSON" or "a Thing conforming to this Profile must only require authentication using the OAuth2 security scheme" or "a Thing conforming to this profile must use the saref ontology for describing units".

Furthermore the reason a profile defines these constraints is not "to describe all the Affordances and metadata exposed by a profile-conforming Thing", but to guarantee out-of-the-box interoperability between a Consumer and a Thing.

At a high level I would say that:

• Binding templates extend the Thing Description vocabulary to make it possible to describe interaction affordances using additional protocols and payload formats (i.e. extend what can be described by a Thing Description)
• Profiles constrain the extension points in Thing Descriptions (i.e. constrain what can be described by a Thing Description) to guarantee out-of-the-box interoperability between Consumers and Things.

I will try to join the meeting later today.

Kind regards

Ben

[egekorkan]

The comment from the call from @benfrancis that improves the Siemens text:

A Profile document constrains features of the Thing Descriptions specification and of individual Binding Template documents to describe all the Affordances and metadata exposed by a profile-conforming Thing.

This is still not perfect since the word feature is not clear and the part starting with "to describe" is not clear.

Some parts to be more thorough about:

• A document would be a registry entry, assuming we have a binding and a profile registry. Binding core spec uses the term "subspecification" at this point. Examples of a document would be "HTTP Core Profile", "MQTT Binding Template" etc. but NOT "WoT Profiles", "WoT Binding Templates".
• features should be clarified but we meant any vocabulary term and its values. The TD should be still valid in the end.
• A small exercise:
  • Let's assume that the TD Information model defines 10 vocabulary terms, 2 of which are mandatory, each term having 3 values.
  • Let's assume we have 2 bindings, each defining 5 vocabulary terms, each term having 4 values.
  • A profile can do the following when I meant by restricting features:
  • Mandate the inclusion of 4 optional terms from the TD spec (2 mandatory are included anyways) and restrict each of them to a single value. If they don't have specific values (e.g. description), the length or type (relevant for something like input) can be restricted as well.
    • Example1: title must be present in all affordances and its length can be maximum 32 characters.
    • Example2: type can either be a string or number within property affordances.
  • Mandate the inclusion of a binding without specifying anything more than supporting the URI scheme and the vocabulary terms.
    • Example: TD must support the HTTP binding in all the forms (i.e. No restrictions on method)
  • Mandate the inclusion of 3 terms from a binding and restrict the values of each term to 1.
    • Example: TD must support the CoAP binding and cov:method must be present, cov:contentFormat must be present with a value of application/json or application/cbor, cov:accept must be present.
  • (not sure about the implications) Mandate the exclusion of terms, e.g. description should not be used in the TD.

Also, just to repeat and make sure: These are my opinions on the mechanism in general. Whether all terms should be allowed to be restricted or how we allow a profile to exist in the WoT WG level or as part of a registry is another discussion. I feel that we do not have enough experience to mandate or even recommend a bunch stuff to all WoT users. We do not have any agreed-upon use case (ootbi is too vague and cannot be easily accomplished even with the current level of profiles). However, within ecosystems or within individual organizations, I would see profiles flourishing more. E.g., like an API marketplace, one can mandate the inclusion of "support": "https://mycompany.com" in TDs or a Matter profile which is almost like a set of TMs that are allowed to be used.

@benfrancis and @lu-zero I have finished editing my comment.

[benfrancis]

As a reminder, the current definition of "Profile" in the WoT Architecture specification is:

A technical specification which provides a set of assertions such that any Consumer which conforms with the those assertions is out-of-the-box interoperable with any Thing which also conforms with those assertions.

Thinking about this, and all the comments above, I tried to further refine the proposed text from Siemens and arrived at:

A Profile document is a technical specification which constrains features the vocabulary terms of the Thing Descriptions specification Thing Descriptions and of individual Binding Template documents and their values to describe all the Affordances and metadata exposed by a profile-conforming Thing guarantee out-of-the-box interoperability between Things and Consumers which conform with those constraints.

If all a Profile can do is constrain "the vocabulary terms of Thing Descriptions and their values", that's a bit different to the approach I had proposed in WoT HTTP Basic Profile 2.0 - Strawman Proposal, which focuses on constraining six key extension points:

1. Protocol bindings
2. Payload bindings
3. Security mechanisms
4. Discovery mechanisms
5. Link relations
6. Semantic contexts

This got me wondering about whether constraining "the vocabulary terms of Thing Descriptions and their values" is sufficient to constrain all six of these extension points:

1. Protocol bindings - could constrain the URI schemes that can be used in the href members of forms and the @contexts of protocol binding vocabularies (could also constrain the use of particular terms like htv:method in order to enforce defaults)
2. Payload bindings - could constrain the values of contentType that can be used in forms
3. Security mechanisms - could constrain the security schemes that may be used in securityDefinitions
4. Discovery mechanisms - this one is completely outside of the Thing Description and can not therefore be constrained by constraining terms in a Thing Description
5. Link relations - could constrain the values of the rel member of links
6. Semantic contexts - could constrain the values of the @context member

One other "feature" that @egekorkan suggested we might want Profiles to constrain in the meeting today was data schemas. I think that could be achieved by constraining the values of input and output members of ActionAffordances, data members of EventAffordances, and various members of PropertyAffordances.

So with the exception of discovery mechanisms, upon first analysis the above definition could potentially be workable, but I think it requires a lot more thought.

There are a lot of nuances to consider such as:

• Can a Thing only use the prescribed protocol bindings, payload formats, security schemes, link relation types and semantic contexts, or can it provide Consumers with other options as well?
• Does a Consumer have to support all of the allowed protocol bindings, payload formats. security schemes, link relations and semantic contexts or only a subset of them?
• Can a profile prescribe that a Thing only uses the default protocol bindings defined in a protocol binding template?
• Can a Profile prescribe that a Consumer interprets a particular link relation type in a particular way?
• Can a Profile prescribe that a Consumer interprets a particular data payload in a particular way?
• Can a Profile prescribe that Things and Consumers must support a particular discovery mechanism and/or security bootstrapping?
• How would all of the above be expressed in a Profile?

The above also assumes the action suggested in Profile Mechanism 2.0 of moving the protocol binding sections out of profiles into protocol binding template documents as defaults. Without this, the above approach definitely wouldn't work.

P.S. @egekorkan I was writing this while you were writing your last comment and it appears we've been having some similar thoughts. For the record I do believe out-of-the-box interoperability can be achieved on the Web of Things and I have very concrete commercial use cases for it.