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

Revising the 'form' vocabulary? #29

Closed
mkovatsc opened this issue Feb 15, 2018 · 5 comments

Comments

@mkovatsc
Copy link
Contributor

commented Feb 15, 2018

w3c/wot-thing-description#88 raised questions about the terms in our vocabulary and raised one issue:

  • href takes the target URI. Usually it is used for (hyper-)references. In HTML, the target resource of a form goes into the action attribute.

    • action could be used.
    • This aligns with the HTML vocabulary, but is not very expressive. Also, I see the conflict with Actions; going back to read-only Properties and write through an Action is one option; actually doing something new and catering for writeable and observable Properties another.
  • mediaType takes the media type for the serialization. It assumes the same media type for requests and responses. In HTML, the field for the request payload media type is enctype (with a small enum for values). accept was deferred down to the input element (for file uploads together with enctype multipart/form-data) and is now deprecated for HTML forms. For WoT, accept is a proposed option for the request payload schema.

    • encType could be used for request payload media type.
    • mediaType (as type is overloaded) for resonse/notification/event payload media type (use case would be an Action that consumes a different media type than it returns, e.g., to convert payloads for a constrained Thing.
    • This aligns with the HTML vocabulary, but is not very expressive :/
  • *:method is binding-specific.

    • method could be an overarching term that can accept values from different vocabularies such as http:method or coap:methodCode
    • @vcharpeneay Would this work for the ontology behind?
  • rel semantically identifies the form. This is not supported in the human-centric HTML forms. The closest match would be name.

    • rel for forms would be an actual improvement needed for a Web of Things, so that machines can understand their meaning.
@mkovatsc

This comment has been minimized.

Copy link
Contributor Author

commented Feb 19, 2018

Another change could be to change the name of form to binding to make the extension point clear. (It also avoids the argument if forms are forms or complex links.)

@mkovatsc

This comment has been minimized.

Copy link
Contributor Author

commented Feb 20, 2018

@vcharpenay Could you comment how far a common method term is possible?

@vcharpenay

This comment has been minimized.

Copy link

commented Feb 20, 2018

  • *:method is binding-specific.
    • method could be an overarching term that can accept values from different vocabularies such as http:method or coap:methodCode

A CoAP method code is a byte while an HTTP method is a string token, so they must be individually defined, with proper range. However, it should be possible to define something like:

{
  ?prop td:form ?httpBinding ; td:form ?coapBinding .
  ?httpBinding http:method "GET"^^xsd:string
}
=>
{
  ?coapBinding coap:methodCode "001"^^xsd:byte
}

to avoid redundant definitions. It would roughly correspond to translating RFC8075 into RDF.

But, to me, it is better to always explicitly state that an interaction supports two bindings (HTTP and CoAP), which here corresponds to ?prop td:form ?httpBinding ; td:form ?coapBinding. There would then be no need for a generic method property.

@mkovatsc

This comment has been minimized.

Copy link
Contributor Author

commented May 15, 2018

Some update after Prage:

  • href: We also need forms for Properties (as they als might need metadata for custom headers/options etc.), so href will stay href for the target URI
  • mediaType: Is used for the media types served by the target. We still need another term for defining the supported request body media type(s), when they differ from the response body media types.
  • *:method: Okay, I am happy with @vcharpenay 's answer. Yet we need to look into "well-known" prefixes, which is also a topic for domain-specific vocabulary.
  • rel: Let's use rel for form relation types.
@mkovatsc

This comment has been minimized.

Copy link
Contributor Author

commented Oct 3, 2018

Consensus for the remaining terms hangs on w3c/wot-thing-description#179
A new issue came up around media type, which is not expressive enough, as no parameters can be defined. Opening new issue to introduce contenttype.
Closing this.

@mkovatsc mkovatsc closed this Oct 3, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.