-
Notifications
You must be signed in to change notification settings - Fork 43
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Clarify interaction affordance binding mechanism-2 #860
Conversation
This is an alternative proposal for the description of the protocol binding mechanisms. It takes into account the discussion in #850 (comment) and implements the approach that was proposed by @mmccool It resolves #850
|
||
<span class="rfc2119-assertion" id="arch-hypermedia-protocol-binding-1"> | ||
<a>Protocol Bindings</a> MUST be serialized in such a way that they are self-descriptive or otherwise | ||
clearly associated with definitions that indicate how to activate the <a>Interaction Affordance</a>. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
instead "clearly" I would be more stronger here by "unambiguously"
|
||
<span class="rfc2119-assertion" id="arch-hypermedia-protocol-binding-2"> | ||
This MAY be achieved by <a href="#sec-hypermedia-controls">hypermedia controls</a>, | ||
by using <a>Profiles</a> or by using protocol specific metadata. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the profiles is not published, we cannot really refer to it right? This is not a normative reference (not using [[my ref]] so it might be ok but it is still NOT clear what a profile can do. If we look at https://w3c.github.io/wot-architecture/#profile-description-methodology , it only says that it can constrain the protocol verbs etc. Thus, a profile cannot define a protocol binding by this definition.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think it's fine as long as there is a Profile definition. Using <a>Profiles</a>
would expect this otherwise it will emphasize with a curled red line.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since WoT Profile 1.0 will now be published after WoT Architecture 1.1 and WoT Thing Description 1.1, I have proposed moving the definition of "profile" from the Profile specification to the TD or Architecture specification in order to resolve the dangling reference - see w3c/wot-thing-description#1719.
Also see w3c/wot-thing-description#1674 in which I proposed an updated description of protocol bindings in the TD specification which takes profiles into account. The wording in that issue describes the two different types of protocol bindings and how they are used.
It would be simpler if there were no normative definitions in the WoT Architecture specification at all, but as long as they exist they need to be kept in sync with the other specifications, since they all cross reference each other.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I have two questions.
- In this PR, a new assertion was cleated. But to add new features in wot architecture 1.1 was frozen. If new features should be added, it is important to think the reason.
- Each Feature( or assertion) must be implemented. Have these assertions already been implemented or will they be implemented soon? The end of the charter period is near. So we should pay attention to the implementation status.
Note that adding new assertions causes a lot of problems at this point: we have to update the IR, update the at-risk list, do testing, etc. Ideally we would just modify an existing assertion if a normative change is needed. Not that it's impossible, just keep in mind we have to do it (at least adding it to the list of at-risk features in the sotd section). Also, if we make all of section 7 informative as discussed... we should not be adding any assertions to that section. I did not get a chance to check that, but be aware assertions can only be in normative sections. I think the existing assertions are in a normative section so that's fine... |
Arch call on Nov 2nd.: Agree to close without merging |
This is an alternative proposal for the description of the protocol binding mechanisms. It takes into account the discussion in #850 (comment) and implements the approach that was proposed by @mmccool
It resolves #850
Preview | Diff