-
Notifications
You must be signed in to change notification settings - Fork 63
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
Where to place the HTTP Default Binding and which format #1274
Comments
Although I acknowledge the fact that leaving it inside the TD spec has the advantage to be normative, I would prefer to move as much information as possible to its Protocol Binding document. The advantage is to have one single place to maintain and point people to read. IMHO Thing Description specification should leave any protocol-specific information to Protocol Binding documents or Profile documents. |
Note that this topic was originally raised in w3c/wot#996, which led me to file w3c/wot-binding-templates#135 and #1259 to consider which specification it should be removed from. In terms of format, I prefer the table from the Protocol Binding Template specification which is organised by operation type. This is how we structure the protocol binding in the WoT Profile specification too. @relu91 wrote:
As I said in w3c/wot#996 (comment), I think it's important to distinguish between a "protocol binding template" and a "protocol binding". The documents you are referring to are not "Protocol Binding" documents, they are "Protocol Binding Template" documents, which is slightly different. My understanding is that a protocol binding template just provides the semantics for describing a particular protocol, and an actual protocol binding (which may use that vocabulary) is either provided:
The set of default HTTP verbs defined for different operations in the Thing Description specification (which are also separately defined in the non-normative Protocol Binding Templates specification but probably shouldn't be) is a very lightweight kind of concrete protocol binding which is really just a set of default values to help make Thing Descriptions less verbose, and was a bit of a stop-gap before we had the Core Profile. It doesn't include defaults for all operations and misses many details, so it's not really a complete protocol binding. The concrete HTTP protocol binding in the WoT Profile specification builds on that set of defaults, but goes into much more detail by defining HTTP headers, payload formats, response codes etc. Now that we have a Core Profile which defines a more comprehensive HTTP protocol binding, I think there are two questions:
I would be open to removing the defaults altogether, but I'm inclined to think that they're still useful for Thing Descriptions which don't conform to the Core Profile but still use the default verbs for basic operations. As to where they should live, I agree it's neat to put them as defaults alongside the vocabulary defined in the Protocol Binding Template, but as @relu91 mentioned this is a non-normative specification. That would mean that Consumers may implement the Thing Description specification, but not the HTTP Protocol Binding Template specification and would therefore not know to apply these defaults. The developer of a Thing Description may assume that a Consumer would apply those defaults, so omit those details. This could result in a Consumer being unable to use interaction affordances which don't include HTTP verbs explicitly. Therefore I think they probably need to stay in the Thing Description specification, unless we decide they're not really needed any more in which case they should just be removed from both specifications. |
from today's TD call:
|
I suppose this is not really use-case-related but rather an "organizational" question, right? |
In the Binding part of the TD call of 10.11.2021, there was a small discussion on where to put the HTTP default binding. It was based on the w3c/wot-binding-templates#135 . There are some things to discuss in general:
htv:methodName
are put in a table and their values depend on the value of theop
. These two ways are shown in the screenshots below, first one is the TD spec, second is the binding templates HTTP. They contain the same information but in different ways:We should choose one and stick with it. I personally like the second approach, i.e. the one in the binding templates since it is easier to read and reason.
The text was updated successfully, but these errors were encountered: