Multiple profiles (mechanism)

[mlagally]

Supporters: Intel, Siemens, Ben, Cristiano, Hitachi

The mechanism used to indicate that a TD satisfies a profile should be general enough to indicate the TD satisfies the requirements for multiple profiles.

Some people are concerned about fragmentation, if multiple profiles would be defined. However this requirement is about the mechanism to identify the profile in use.

Discussion: Does this mean a thing can support multiple profiles? TD already supports multiple profiles Profiling mechanism is described in the profile spec, may need to be polished

[mlagally]

Arch call on 9.2.:
TD already supports multiple profiles, goal is to define a HTTP based profile.
We should not have constraints on other profiles that are defined for other protocols in the current profile spec.

Language for OPC-UA, constrained profile, ... already exists.

What does a consumer have to support when he gets a TD with multiple profiles?

The scope of the profile specification in the current charter period is focused on HTTP(S) only.
We need to specify consumer behavior what to do when he gets a TD with multiple profiles. How to chose?

[egekorkan]

Is there any resolution on this? As I have stated at w3c/wot-testing#417 (comment) I think it is quite problematic to have multiple profiles. Here are my observations from the current testfest TDs:

• If a profile does not restrict a certain aspect but another does: Profile A does not say something about events, Profile B says. If the Consumer sees an event in a Profile A+B TD, does it mean that that event is part of profile B? Is this behavior defined? This is the case currently when we have baseline+sse.
  • If that event is part of profile B, is this not possible to have other types of events in this TD?
• If a profile restricts a certain aspect and another does it too, how is the conflict resolved, how can the Consumer see that one affordance is compliant to profile A or B? This is currently the case with SSE+Webhook.

Given that we have only one normative profile planned, this might not be necessary but given that the profile term is an array, people can be confused and try to use the informative profiles as well.

[benfrancis]

@egekorkan wrote:

Is there any resolution on this?

Yes, the resolution is that a single Thing can use multiple profiles:

The value of the profile member MUST be set to either a valid URI [RFC3986] identifying a single profile, or an array of valid URIs identifying multiple profiles.

I think it is quite problematic to have multiple profiles.

Due to the way the current profile mechanism works (a profile is just a list of assertions which could say anything) it is certainly possible that two profiles could conflict with each other. It is up to the designers of the profiles to ensure they do not conflict with each other, and to my knowledge the current profiles do not.

If a profile does not restrict a certain aspect but another does: Profile A does not say something about events, Profile B says. If the Consumer sees an event in a Profile A+B TD, does it mean that that event is part of profile B? Is this behavior defined?

A couple of things:

1. It is the responsibility of the profile specification to define how to select a Form for a given operation. The SSE profile says to look for a form with subprotocol: "sse" and the Webhook profile says to look for a form with subprotocol: "webhook". Therefore they do not conflict with each other.
2. Just because a profile requires a certain protocol binding, there's no reason that a Thing can not provide additional protocol bindings which do not use the protocol binding from the profile, as long as the Thing conforms with all of the assertions in the profile. A Thing could conform to the HTTP SSE Profile whilst also providing event protocol bindings which use WebSockets for example, but if it provides protocol bindings using the HTTP protocol with the sse sub-protocol then they do have to comply with the protocol binding in the profile. This important point is currently only mentioned in the Abstract, but in Revised Abstract and Introduction - fixes #115 #297 I have proposed to make it more explicit with a note in the protocol binding mechanism section.

This is the case currently when we have baseline+sse.

As explained above, I don't believe this is a problem.

If that event is part of profile B, is this not possible to have other types of events in this TD?

It is possible.

If a profile restricts a certain aspect and another does it too, how is the conflict resolved, how can the Consumer see that one affordance is compliant to profile A or B? This is currently the case with SSE+Webhook.

As I said above, it is up to the authors of the profiles to design them in such a way that they do not conflict with each other, by clearly defining how a Form should be selected for a given operation.