Way to identify profile(s)

[danielpeintner]

We need to think about a way so that

• people can "mark" a TD as profile "XYZ" or on the contrary
• people can be sure that a TD is of profile "XYZ"

[mlagally]

Need to indicate combination of protocol- and data model profile.
Could be a combined label, e.g. core/http, enhanced/coap.

We ask the TD spec to add a new vocabulary term "profile" with a String type.
w3c/wot-thing-description#806

[mmccool]

If we add a "profile" vocab term to the TD, I think it needs to be an array of strings, and if multiple values are given, it means the TD satisfies the requirements of all profiles listed. This does mean we need to be careful when specifying profiles to ensure they are "composable". One place where we probably have to be careful is default values that are different in different profiles. Another would be requiring optional fields in one profile but disallowing them in another. As I mentioned in another comment we need to define how profiles are composed; we probably need to take the intersection of vocabulary restrictions and the union of supported protocols and payload types.

Another way to identify profiles would be to use a custom @context value. But I think we should reserve this for extensions. Profiles are the opposite, they are restrictions, so a separate field makes sense.

[mmccool]

As discussed in the TD call, it might be safer to handle profile composition "externally" and in fact limit the identification of profiles to a string... or better yet, a URI that can uniquely refer to an external specification of a profile.

[benfrancis]

a URI that can uniquely refer to an external specification of a profile.

Sounds like a good idea.

Could be combined with @context, e.g.:

"@context": "https://www.w3.org/2019/wot/td/v1#core",

or separate. e.g.:
"profile": "https://www.w3.org/2019/wot/core/v1",

The former seems simpler.

I'm not sure I agree with the distinction that extensions extend and profiles restrict. My hope for a core profile is that it can define a default HTTP protocol binding which all web things should support if their creator wants to enable ad-hoc interoperability. Web things can support other protocol bindings in addition to the default.

[draggett]

This is coming back to my old proposal for using a URI to specify protocol bindings rather than requiring a fully declarative solution. I would like to see a widely supported protocol that uses Web Sockets for property updates, event notifications and action invocations and responses. My implementation experiments have shown that polling for events and property updates sucks in respect to performance.

[benfrancis]

This is coming back to my old proposal for using a URI to specify protocol bindings rather than requiring a fully declarative solution.

Strong +1

Maybe this is what is really what is needed here. A way to reference an external protocol binding specification using a URI, rather than a "profile" which also adds additional constraints to the Thing Description data model or is specific to a particular application domain.

I would like to see a widely supported protocol that uses Web Sockets for property updates, event notifications and action invocations and responses. My implementation experiments have shown that polling for events and property updates sucks in respect to performance.

Following initial feedback from various stakeholders, I will shortly be submitting a proposal for a "Web Thing Protocol Community Group" to standardise a WebSocket sub-protocol for exactly this purpose.

[zolkis]

Could be combined with @context, e.g.:
"@context": "https://www.w3.org/2019/wot/td/v1#core",

My thoughts exactly.

[mlagally]

Arch call on 27.8.:
We want to encode the following data in the TD:
profileCompliance = core
profileProtocol = http, coap, ...

profileProtocol can be an array.

This could be addressed by two new keywords (vocabulary terms): profileCompliance, profileProtocol

Overloading the @context is not requried

[mlagally]

We also need to handle profile versions, , e.g. add a number to core. Need to define a "compatibility" rule between versions.
For example if we refer to external @context snapshots, we may want to refer to a later version.

[benfrancis]

profileCompliance = core
profileProtocol = http, coap, ...

Are the valid values of profileProtocol for a given profileCompliance value limited to a constrained list? And how would sub-protocols be denoted?

[mlagally]

@benfrancis In yesterday's call we discussed http and coap as a starting point.
To answer your sub-protocol question it would be good to start a discussion based on concrete candidates.
Can you please propose protocol/sub-protocol combinations that should be considered?

[benfrancis]

Was a conclusion ever reached on this topic? There is a section in the current draft called "Profiling Mechanism", but it doesn't say how you denote that a given thing description implements a given profile.

@mlagally wrote:

To answer your sub-protocol question it would be good to start a discussion based on concrete candidates.
Can you please propose protocol/sub-protocol combinations that should be considered?

Sorry I didn't answer this at the time. I was specifically thinking about the "webthing" WebSocket subprotocol being designed by the Web Thing Protocol Community Group. But as discussed in #73 I really don't think profiles should be protocol agnostic. If that was the case then there wouldn't be a need to separately specify a profile, protocol and sub-protocol as the protocol used would be defined inside the profile. Then the mechanism for denoting the profile could be as simple as:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "profile": "https://www.w3.org/2021/wot/profile/core",
    ...
    }
}

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "profile": "https://www.w3.org/2021/wot/profile/constrained",
    ...
    }
}

If there were different variants of a profile for different protocols then they would effectively be separate profiles so that could just be denoted in the profile URI.

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "profile": "w3c.github.io/web-thing-protocol/websocket/v1",
    ...
    }
}

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "profile": "w3c.github.io/web-thing-protocol/http/v1",
    ...
    }
}

(I still don't mind if the profile is denoted using @context or a separate profile or similar member).

[benfrancis]

Closed by #79