- From: Kovatsch, Matthias <matthias.kovatsch@siemens.com>
- Date: Sat, 2 Apr 2016 19:33:39 +0000
- To: "dsr@w3.org" <dsr@w3.org>
- CC: "Claes1.Nilsson@sonymobile.com" <Claes1.Nilsson@sonymobile.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
To identify individual data points, there is always a combination of data element addressing ("paths") and hierarchy within this element ("arrays", objects). This not only differs from protocol to protocol, but often also from application to application. Using URIs together with something Schema-like to describe (hierarchical) payloads, we can easily describe and handle this in WoT. The protocol binding then maps this accordingly to the specifics of protocol and serialization. Where exactly the addressing information goes (protocol address or payload) depends on the protocol. Defining URIs for every thinkable protocol is impossible, hence any definition of a new URI scheme is out of scope. Furthermore, this work needs to be done within the IETF, preferably by or with representatives of the body responsible for the protocol (Bluetooth SIG, OASIS, IETF WGs, ...). In the WoT WG, we should only define the mechanisms around URIs (to access data elements of things, which is in addition to the URI usage in RDF) and flexible protocol mappings to enable extensions now (in parallel to the W3C WG) and in the future. If we need something now, there is nothing stopping the individuals of the WG taking care of this work in the corresponding body. I don't think we need a test for resourcefulness---anything can be a resource by definition anyway... I think the problem with the statement is that it considers that URIs for resourceful/RESTful protocols already exist. The point is, we do not define any new URI schemes in the WoT WG. We just support every protocol that has one, now or in the future. Whoever is in favor of a particular protocol should implement it for the Plugfest and try to interoperate. They can also draft new URI schemes for that, which will be useful input for an I-D. This is the only way to figure out the details of the mappings and which adjustments to the WoT mechanisms might be needed to make it all work together. Keeping this at a fuzzy theoretical level will get us nowhere... Is the idea getting clearer? Do you agree with that? Best regards Matthias -----Original Message----- From: Dave Raggett [dsr@w3.org] Received: Saturday, 02 Apr 2016, 6:14 To: Kovatsch, Matthias [matthias.kovatsch@siemens.com] CC: Nilsson, Claes1 [Claes1.Nilsson@sonymobile.com]; public-wot-ig@w3.org [public-wot-ig@w3.org] Subject: Re: [WoT-IG]: Comments on proposed charter for WoT WG On 2 Apr 2016, at 00:15, Kovatsch, Matthias <matthias.kovatsch@siemens.com<mailto:matthias.kovatsch@siemens.com>> wrote: Von: Dave Raggett [mailto:dsr@w3.org] I would very much like to hear from the IG what exactly is meant by “URI mappings for non-resourceful protocols”. Correct wording will be tricky on this one: A “resource is anything that can be identified by a URI”, but many protocols do not call their data endpoints a resource, but it is still possible to come up with URIs to identify and address them. Thus, “non-RESTful” might be a bit closer. Anyhow, the intention is to define URIs that can address data elements (or “interaction” elements in TD terms) in IoT protocols that do not have URIs (yet), for instance, an attribute in GATT/BLE or a topic in MQTT. A URI is basically just a string that identifies the protocol through the scheme and then more information that can be used to encode protocol-specific addressing information. When a client has the necessary protocol stack, it can contact the interaction element described by the TD through the URI directly. If not, it can pass this URI to a proxy (e.g., using the CoAP Proxy-URI option or HTTP proxying through the Request-Line), which will then make the request in that protocol on behalf of the client. This kind of proxy is application-agnostic (it does not know anthing about WoT, TD, and interactions, but only the two or more protocols). Does the idea become clearer? A little, so we definitely need clearer wording for the charter. At the abstract messaging level, there is a need to express paths in terms of thing data models, e.g. a property might be an array of values, and you want to update the third value in the array. Different protocols could represent such path identifiers in different ways. For instance, a protocol could involve an exchange of JSON messages over Web Sockets. These messages could use a path string to identify what a value update applies to. For those protocols that use URIs for identifiers, we will need a way to map paths for thing data models into the corresponding URIs. The conventions for this form part of the protocol binding specifications. I am left confused as exactly what you want to rule out of scope and why? Is it to do with steering clear of IPR concerns? What is your test for whether a protocol is resourceful or not? — Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>
Received on Saturday, 2 April 2016 19:34:18 UTC