Profile is not exclusive, removing additional profiles #20
Conversation
mlagally
requested review from
danielpeintner,
draggett,
mmccool and
sebastiankb
| </ul> | ||
| <p>Profiles are is not exclusive, they can overlap or | ||
| include others. | ||
| <p>Note that the core profile is not exclusive. Device implementers are free to adopt |
There was a problem hiding this comment.
+1 for this. However, I'm still struggling with the term "core" or "core profile" since this infer that the core have to be always there whatever you are doing. This would be not the case if a Thing is only able to support CoAP as example.
I'm thinking about the term "default". This implies that there are some default assumptions and if those are not other specified the default assumption will be followed. I will setup a separate issue about this point.
There was a problem hiding this comment.
I wonder whether it makes sense to make a technical statement such as calling it according to the technology used e.g,. "http-json" profile (as far as I understand the recent discussion that's what it will be now, see #9 (comment). Correct? Different to the phase the profile work started were the idea was to setup means to define a profile).
Using actual names like "http-json" make the idea of a given profile very easy to grasp. Generic terms like "core" or "default" are very fuzzy with that regard.
|
The naming question needs to be revisited once we have defined the content of the profile spec. |
Removing text for Digital Twin and Thing Templates for Spec version 1.0.
Adding text to clarify that the profile is not exclusive.
This MR addresses and resolves:
#9
#18
#8
Preview | Diff