Term 'Core' may cause a false impression

[sebastiankb]

As I mention in last week web meeting we have to be very careful about wording. I'm not sure if the term 'core' or 'Core Profile' results to the assumption that this core have to be always be implemented (since it is a 'core') even I would actually follow a profile that covers CoAP or MQTT.

A proposal would be that we use the term 'default' as alternative. 'default' has the impression that there are some basic settings / restrictions that will be adopted if they are not changed otherwise.

[benfrancis]

I agree with this, "default" may be a better name.

[danielpeintner]

I agree that "default" is better than "core" but I raised the question in #20 (comment) whether it makes sense to name it according to the technology used (e.g., "http-json")

[benfrancis]

I agree that "default" is better than "core" but I raised the question in #20 (comment) whether it makes sense to name it according to the technology used (e.g., "http-json")

+1 That sounds like a great idea.

[sebastiankb]

An "http-json" can be also an option that gives a clear technology context. However, I would be worried if this results to bulk of profiles in the future with "http-yaml" or "http-xml" or "http-cbor" or "coap-json" etc.

Btw: I also like the term "OOB Profile". I have seen this here #25.

[egekorkan]

I don't remember where I had mentioned it before but I think that instead of defining a profile, a set of features supported by a TD could be communicated to the Consumers. From this discussion, it seems that people might be more interested in such an "annotation". So instead having something like:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "profile":"http-json",
    "securityDefinitions": {
        "basic_sc": {"scheme": "basic", "in":"header"}
    },
    "security": ["basic_sc"],
    "properties": {
        "status" : {
            "type": "string",
            "forms": [{"href": "https://mylamp.example.com/status"}]
        }
    }
}

We can have something like:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "features":["http","json"], //Only difference here
    "securityDefinitions": {
        "basic_sc": {"scheme": "basic", "in":"header"}
    },
    "security": ["basic_sc"],
    "properties": {
        "status" : {
            "type": "string",
            "forms": [{"href": "https://mylamp.example.com/status"}]
        }
    }
}

Of course, for this case this does not make a big difference. However, if there is a TD like the following:

{
    "@context": "https://www.w3.org/2019/wot/td/v1",
    "title": "MyLampThing",
    "securityDefinitions": {
        "basic_sc": {"scheme": "basic", "in":"header"}
    },
    "security": ["basic_sc"],
    "properties": {
        "status" : {
            "type": "string",
            "forms": [{"href": "mqtt://mybroker.example.com/status"}]
        }
    }
}

Then the profile needs to be something like mqtt-json which looks like a completely different profile to a Consumer but actually only the protocol has changed. We can of course think of a case where the payload format is XML but the protocol is still HTTP, which would also mean "another" profile like http-xml.
On the other hand, when we have a list of features, they can be easily separated in the Consumer implementations, i.e. supporting HTTP and then another payload format are two different things to implement. (In the case of node-wot, protocols are implemented as bindings and different payload formats are implemented as codecs.)

Also, while a profile sounds more reassuring (if you support a profile as a Consumer you get to interact with all Things of that profile), it might be too restrictive in an unnecessary way to some consumers.

[benfrancis]

@egekorkan wrote:

I don't remember where I had mentioned it before but I think that instead of defining a profile, a set of features supported by a TD could be communicated to the Consumers.

I think you're missing the point that what's needed here is not just to tell a client that a web thing uses HTTP and JSON (JSON is already the default and the protocol should be obvious from URLs used in forms), but how to use HTTP and JSON to carry out operations on a device in a standard way (e.g. read a property, write a property, invoke an action, cancel an action, subscribe to an event etc.)

Also, while a profile sounds more reassuring (if you support a profile as a Consumer you get to interact with all Things of that profile), it might be too restrictive in an unnecessary way to some consumers.

Yes, this point has been repeated ad nauseam. The core profile is specifically designed for greenfield devices or services which want to ensure out of the box interoperability by implementing a concrete (sub-)protocol defined in a specification, not brownfield devices or services which can (theoretically, though often not in practice) be described using a declarative protocol binding in a Thing Description, at the cost of not being supported by all clients.

[egekorkan]

but how to use HTTP and JSON to carry out operations on a device in a standard way (e.g. read a property, write a property, invoke an action, cancel an action, subscribe to an event etc.)

Isn't this already solved with normal TDs and protocol bindings? However, as the profile document explains, the profile can constrain HTTP that actions are always done via POST and never with PUT etc. In that case, you are correct, saying that the Thing has HTTP as a feature would not be enough but would need a feature like correct-http :)

[benfrancis]

Isn't this already solved with normal TDs and protocol bindings?

No. If it was possible to implement a general purpose WoT client which could communicate with any WoT device then profiles would not be necessary. I don't believe this is currently possible.

[sebastiankb]

Based on yesterday's vF2F call: Further name proposals came up:

@draggett "baseline"

@egekorkan "simple"

@mmccool "interop"

[draggett]

"baseline" signifies a lowest level of features and performance as a reference point for richer profiles that do better. If the baseline profile relies on simple HTTP long polling for events, then we indeed are setting a low baseline for eventing performance and the risk of losing events that occur in very rapid succession.

[egekorkan]

I think that baseline conveys a somewhat similar meaning to core but a bit better since it can mean that a richer profile can override it? I don't know if conveys really the meaning we want, the profile written as it currently is should not imply that future profiles will be depending on it. It is just a profile that is easy to implement and addresses a good number of use cases that we see in the plugfests:

• Nearly everyone uses HTTP: I and some people have CoAP simulators, no device so far. Some MQTT devices.
• Nearly everyone uses JSON: Some Fujitsu devices use text/plain
• Most data schemas are not fully nested: Exception being Philips Hue
• JSON Schema validation keywords used (and available in the TD spec) are the ones that is taught in the intro sections of JSON Schema tutorials.

For me, all these features that it requires are very simple and straightforward, thus the name proposal "simple". In this case, a profile named "complex", "industrial", "constrained", "eventing", "egeprofile" would not necessarily be related to it. Other names that came to mind were "basic" and "easy" but "simple" is more objective from my point of view.

[benfrancis]

I think we've agreed in #73 that the first profile defined in the WoT Profile specification will mandate the use of HTTP+JSON, but the naming is yet to be decided upon.

In order to eventually choose a name, it's probably good to think about what other profiles might exist in the future so that the name clearly differentiates it. Some that I have in mind are:

1. Constrained - We've talked about a constrained profile which focuses on the needs of constrained devices and mandates the use of CoAP+CBOR
2. Directory - I'm wondering whether it might make sense to define a profile for directories which mandates support for the Directory Service API. Perhaps the WoT Discovery specification could even define that profile?
3. WebSocket - The Web Thing Protocol Group is working on a WebSocket sub-protocol covering all of the operations defined in the W3C WoT Thing Description specification. I would have loved for that to be part of the "core profile" we were originally discussing, but that's impractical given it's currently only at the CG stage.

For this example set of profiles, some example naming schemes could be:

Option A

• Default
• Directory
• Constrained
• Full-duplex

Option B

• HTTP+JSON
• HTTP+JSON Directory
• COAP+CBOR
• WebSocket

Option C

• HTTP Thing
• HTTP Directory
• CoAP Thing
• WebSocket Thing

Option D

• WoT Device
• WoT Directory
• Constrained WoT Device
• Full Duplex WoT Device

May the bikeshedding commence...

[egekorkan]

I like the option B, it probably needs less effort for a novice reader. The downside could be if we, in the future, want to allow also websockets in HTTP+JSON profile, it would be contradicting the name a bit.

[benfrancis]

I have been inspired whilst reading about an unrelated project.

How about we call the first profile the ✨ Common Profile ✨

It is not:

• "core", because other profiles don't necessarily build on it
• "default" or "baseline", because some WoT consumers may not support it at all
• particularly "simple", by the time we've finished with it
• uniquely "interop", because other profiles will allow interop too

But it is:

• Objectively the most "common" combination of technologies (HTTP+JSON) used by current WoT implementations and at PlugFests
• Following "common" patterns for the HTTP protocol (GET to read, PUT to write etc.)
• Providing a "common" protocol for the Web of Things, for implementations which choose to use it

In the context of other profile names:

• Common Profile
• Constrained Profile

Maybe the WebSocket sub-protocol, and even the Directory Service API it makes sense for that to be part of a profile, could be part of a future Common Profile v2.0. Or they could be separate, but we can worry about that later.

What do you think?

[benfrancis]

Duplicate of #5, let's take the discussion there.