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

Add link arrays to Property, Action and Event objects #119

Merged
merged 2 commits into from
Nov 26, 2018

Conversation

benfrancis
Copy link
Member

Closes #79 and closes #108.

Live preview viewable here.

This is a proposal to add an array of Link objects to Property, Action and Event objects in the same format as the top level links member. This will allow links to be assigned a mediaType and rel where required and is particularly useful for binary properties which link to a binary file or stream (e.g. images and videos) with a defined media type.

This is similar to the form objects in the current W3C spec, but with simple link relations rather than forms with operations. This may eventually change as the links vs. forms debate continues.

Note that the term mediaType is currently used, consistent with the current top level links member. In the latest W3C draft mediaType was recently changed to contentType for forms, while links use the term link. I've filed w3c/wot-thing-description#306 to find out whether this difference is intentional. We may eventually need to change mediaType to to contentType or type once this becomes more clear.

This is a breaking API change and we should make an effort to be backwards compatible with the deprecated href member in our next release (perhaps with a console warning).

@ghost ghost assigned benfrancis Nov 23, 2018
@ghost ghost added the review label Nov 23, 2018
Copy link

@dhylands dhylands left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM - It seems to me that you could leave href and links both present and maintain backwards compatability.

@mrstegeman
Copy link
Contributor

@dhylands I don’t see a need to retain backwards compatibility for an in-development spec. We can do that on the gateway side.

@benfrancis Should the individual property links have a rel?

@benfrancis
Copy link
Member Author

@mrstegeman wrote:

@dhylands I don’t see a need to retain backwards compatibility for an in-development spec. We can do that on the gateway side.

I agree.

@benfrancis Should the individual property links have a rel?

I thought about that for consistency, and they could, but I think the relationship is probably implied by the context of the links array (a links array in the context of a Property object provides link(s) to representation(s) of the property). Are there other types of link relation that might be present, with different types of relationship which need differentiating? Either way a "property", "action" and "event" relations could be implied defaults for Property, Action and Event objects respectively.

@hobinjk
Copy link

hobinjk commented Nov 26, 2018

It makes sense to me to have an optional "rel" with sensible defaults so that a link can highlight that it has some kind of special functionality (e.g. is an optional high-bandwidth video stream that severely impacts battery life)

index.html Outdated
@@ -193,7 +193,8 @@ <h3><code>events</code> member</h3>
</section>
<section>
<h3><code>links</code> member</h3>
<p>The links member provides an array of link relations ([[!web-linking]]) to other resources of a thing. Links can include a link relation type (<code>rel</code>) and an optional media type (<code>mediaType</code>). Examples of links include a link to a <a href="#properties-resource">Properties resource</a> (<code>"rel":"properties"</code>), an <a href="#actions-resource">Actions resource</a> (<code>"rel":"actions"</code>) or an <a href="#events-resource">Events resource</a>. It can also include links to alternate representations of a thing such as a WebSocket API endpoint or an HTML user interface (<code>"rel":"alternate"</code>).</p>
<p>The links member provides an array of <a href="#event-object">Link Object</a>s which link to other resources of a thing.</p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You're linking to #event-objects here.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

index.html Outdated
<li>A <code>description</code> (A string providing a human friendly description)</li>
<li>A <code>links</code> array (An array of <a href="#link-object">Link object</a>s linking to one or more representations of a <a href="#property-resource">Property resource</a>)</li>
<li><code>enum</code> (an enumeration of possible values for the property)</li>
<li><code>readOnly</code> (A boolean indicating whether or not the property is read-only)</li>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we indicate here the readOnly defaults to false?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

@benfrancis
Copy link
Member Author

@hobinjk wrote:

It makes sense to me to have an optional "rel" with sensible defaults so that a link can highlight that it has some kind of special functionality

Yep, that makes sense. The links array of Property, Action and Event objects already re-uses the Link object, which can have a rel member. I've added some text to each to note the implied default values for rel if not provided. We can add additional examples later if we think of use cases for other possible values for rel.

(e.g. is an optional high-bandwidth video stream that severely impacts battery life)

This particular case might be better expressed by the mediaType (or some other additional metadata) because the actual relationship between the resources is really still the same. The linked resource represents a property of the current resource (the Thing Description), so implcitly rel=property.

@benfrancis benfrancis merged commit 098848b into WebThingsIO:gh-pages Nov 26, 2018
@ghost ghost removed the review label Nov 26, 2018
@benfrancis
Copy link
Member Author

Oops, forgot to squash.

@mrstegeman mrstegeman added this to Done in WebThings Gateway Apr 9, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Development

Successfully merging this pull request may close these issues.

Binary Properties Links or forms for actions?
4 participants