Proposal for Abstract Transfer Layer #161
Conversation
Add proposal for WoT Interaction Model mapping to abstract transfer layer
|
Can't this be seen as part of the Explicit Protocol Bindings? |
|
To clarify, a mechanism for protocol bindings is proposed. It defines use of a common transfer layer in a uniform way to make binding to specific protocols simple and straightforward. It does this by defining common workflows for processing the resources pointed to by the hrefs when using these protocol bindings. Should something be renamed or classified differently? Another way to define the resource workflow for protocol bindings would be to include a content format identifier associated with the subject of the hrefs, where the content format defines processing rules, for example a TD hrefs could point to a resource in OCF content format, and the client could invoke it's OCF processor to consume the resource. A pdf document for this proposal can be reviewed at: |
|
This is a great contribution. I simply meant to put it under I can also merge it and then do a |
|
If a device does not support JSON but, say, EXI, it should declare a media type like I am not sure I understand why a media type for the abstract transfer layer is needed here. Shouldn't all WoT devices follow these workflows? I see a difference between processing the content of a resource (that might be an OCF resource) and navigating in the resource graph (driven by what the TD declares, i.e. interactions). While I don't doubt media types are useful to indicate the content format of the resource (they are also part of the discussion about value types, by the way, see issue #119), I don't see the need for it at the interaction level. Did I miss something? |
I agree as abstract messages are defined in term of the data types declared for things. You only need media types when you map abstract messages to a concrete protocol. It looks like we don’t all have the same conceptual model, which is making it harder to understand each other. I am now planning on a series of blog posts to outline the conceptual model I am using. — |
|
Internet Media Types don't have anything to do with concrete protocols. They are identifiers for payload/representation formats, which themselves can be versioned under the same identifier. Every formal definition of your abstract massages could be come a representation format, which can then be identified by an Internet Media Type. |
HTTP is a concrete protocol and the content-type header identifies the content payload, e.g. text/html. — |
|
The Content-Type field is part of HTTP, a concrete protocol. It uses the IANA registry for Internet Media Types to specify the type of the body. These types can be used by any protocol (HTTP, CoAP, SMTP, SIP, ...). You might be aware that even operating systems (Linux, Mac OS) rely on Internet media Types to map files (=payload/representation) to the right programs... |
|
@mjkoster The more relevant discussion here is to inlcude this in the proposals for a consistent view. Could you I am splitting the existing content in the README into smaller pieces. We need to get the experimental work for the PlugFest going... ;) |
|
Thanks! |
Add proposal for WoT Interaction Model mapping to abstract transfer
layer