Skip to content
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

Closed
wants to merge 1 commit into from

Conversation

mlagally
Copy link
Contributor

@mlagally mlagally commented Oct 20, 2022

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

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>.
Copy link
Contributor

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.
Copy link
Contributor

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.

Copy link
Contributor

@sebastiankb sebastiankb Oct 20, 2022

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.

Copy link
Member

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.

Copy link

@chachamimm chachamimm left a 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.

  1. 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.
  2. 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.

@mmccool
Copy link
Contributor

mmccool commented Nov 2, 2022

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...

@mlagally
Copy link
Contributor Author

mlagally commented Nov 2, 2022

Arch call on Nov 2nd.: Agree to close without merging

@mlagally mlagally closed this Nov 2, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Contradiction with the WoT Profile spec on protocol bindings
7 participants