W3C home > Mailing lists > Public > public-wot-ig@w3.org > April 2016

AW: [WoT-IG]: Comments on proposed charter for WoT WG

From: Hund, Johannes <johannes.hund@siemens.com>
Date: Tue, 5 Apr 2016 07:36:32 +0000
To: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>, Dave Raggett <dsr@w3.org>
CC: "Claes1.Nilsson@sonymobile.com" <Claes1.Nilsson@sonymobile.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
Message-ID: <C271054E16F8474D9104E1146C767BF1621F66@DEFTHW99EK1MSX.ww902.siemens.net>

I was adding my comments on the discussion thread on github (to have it more sticky).

First of all thanks for the feedback!
Let me express my opinion for all of @ClaesNilsson<https://github.com/ClaesNilsson> 's points:

Ad Sect. 1 / Scope, Motivation: I see also the picture only addressing some specific side-aspects of WoT, yet that is the nature of complex matter: there is not one single image to explain it completely. However, I would like/suggest to also include images from the architecture document.

Ad Sect. 2 / scripting: fully agree. We had some discussion before we had this concept of both server and client-sided scripting APIs in our group as consensus and it might be too implicit here to be understandable by someone not in the discussion.
@ClaesNilsson<https://github.com/ClaesNilsson> I think your wording in this issue is covering the matter precisely but understandable, could you send that in as PR?

Ad. Sect 1.3: That is the intention I think. I would see the deliverable as a description how the "patterns" or "interactions" from the thing description (Actions, properties, events etc.) are mapped into resources and how to interact with these resources.

The question of how these resources and interactions on the resources are then translated in the protocols is sometimes trivial, sometimes more complex. In the end, it only imposes a constraint on the messages used for the sake of better interoperability. For example, its easy for protocols like CoAP or HTTP, but e.g. OFC has defined a mapping of RESTful resources to XMPP. It does not leverage the full power of XMPP, but makes a seamless integration easily possible.

The tradeoff here is how to use the protocol's intrinisc features to make a mapping "elegant" vs. a simplistic mapping. That's why I see it important for this task to involve the people of the protocol standardization themselves.

Ad Sect: 1.4 / Out of scope: The meaning of that sentence is clearly too vague at the moment. My longer form of that would be:

"We assume the protocols to have some way to uniquely address items (which we call resources) such as actions or properties. This identifier resp. address is an opaque string for in WoT. How this is string is constructed for each individual protocol is not the scope of this group."

If it is a problem, I have no objection to drop it. The intention was mainly it might however help companies regarding IPR issues.
I’ll also allocate a slot in tommorrow’s AP call for this discussion as we do not seem to be consent here yet – or are not aware of it.

Best regards,

Von: Kovatsch, Matthias [mailto:matthias.kovatsch@siemens.com]
Gesendet: Montag, 4. April 2016 17:29
An: Dave Raggett
Cc: Claes1.Nilsson@sonymobile.com; public-wot-ig@w3.org
Betreff: AW: [WoT-IG]: Comments on proposed charter for WoT WG

My statement was on XPath, XPointer, etc. being unrelated to the out-of-scope point on URI definition and the idea behind it. I do not see how XPath, XPointer, etc. can carry information for the transport layer and lower. If we want to make things addressable in a uniform way, URIs appear to be the obvious solution; they have been used for that in every Plugfest so far; they are fundamental to the World Wide Web, so why not for the Web of Things?

To avoid convolution more topics into the discussion about the particular out-of-scope point, let’s clear that one. After what I have learned about the primary intention of the Out of Scope section in the charter, I think we can simply drop that bullet point. We will confirm that in the corresponding GitHub issue (https://github.com/w3c/charter-drafts/issues/48).

Best regards,

Von: Dave Raggett [mailto:dsr@w3.org]
Gesendet: Montag, 4. April 2016 16:21
An: Kovatsch, Matthias
Cc: Claes1.Nilsson@sonymobile.com<mailto:Claes1.Nilsson@sonymobile.com>; public-wot-ig@w3.org<mailto:public-wot-ig@w3.org>
Betreff: Re: [WoT-IG]: Comments on proposed charter for WoT WG

On 4 Apr 2016, at 14:42, Kovatsch, Matthias <matthias.kovatsch@siemens.com<mailto:matthias.kovatsch@siemens.com>> wrote:

Von: Dave Raggett [mailto:dsr@w3.org]

The point about having an out of scope section is mainly to assist companies with their IPR review of the potential patent licensing commitments in respect to the W3C Recommendations produced by a given working group. I would propose we drop this bullet point from the charter as it is proving complex to explain and justify.

This interesting to know. Is there also a mechanism to focus the work within an W3C WG?

Yes, the scope section sets the general boundaries, but, the charter should also describe the expected Recommendation track work items, although WGs’ may choose to refactor specs if needed.

 The nearest precedent I could find relates to XPath and XPointer. W3C defined a registry for XPointer Scheme Names, for use in URI fragments, see [1].  The URI specification is owned by the IETF and defines a generic syntax for URI fragments, but the meaning of these fragments is dependent on the resource identified by the URI, e.g. whether it is HTML, XML, etc. There has been some work done on an analog of XPath for JSON, e.g. Stefan Goessner’s JSONPath, see [2]. However, as far as I am aware, there is no official standard for that. RFC690 defines a less powerful approach called JSON Pointer, see [3], which may be good enough for most purposes.

Unfortunately, I cannot see how this relates to the issue at hand. In Nice, we were talking about using URIs to be able to abstract from protocol-specific addressing. Whatever a protocol uses should be formatted in a simple string that can be included in the TD or handled uniformly by the runtime environment to enable communication from scripts to things. This is completely unrelated to pointers/addressing within documents. State of the art is anyway to use semantically enriched schemas to make documents machine-understandable.

That very much depends on the protocol.  I don’t think we should tie the hands of the protocol experts in the charter.  XPath and JSON Pointer act on object models rather than on documents.  The object models exposed to applications by the web of things is analogous. You have objects with properties and sub-properties, and the need to express integrity constraints and updates for specific sub-properties etc. I respectively disagree with your assertion that there is no relation to pointers/addressing in document object models. The format of the syntax used in given serialisations of the web of things object model should be decoupled from the protocol specific addressing mechanisms.  This should be clear from the range of possibilities, e.g. XML and XPath, JSON and JSON Pointer, RDF and SPARQL.

 I am talking about, for instance, putting BLE addressing information into a string like “ble://*********” or BACnet-specific addressing into a string like “bacnet://*******”. Again, the WG should only work on the mechanism to use such string to handle protocol-specific addressing information uniformly in the TD and Scripting API. This string is then passed down to the stack and the Protocol Binding takes care of producing the correctly addressed and serialized messages.

Let’s leave the question of whether it is appropriate to define new URI addressing schemes to the experts for that protocol!

Exactly. Hence, simply put defining new URI schemes out of scope for the WoT WG, no?

No, it is much easier to simply leave this out of the charter.  What happens in the Bluetooth SIG wants to work with W3C on registering a new URI scheme for Bluetooth Smart devices? I can’t see any reason to forbid that. Moreover, we shouldn’t assume that the WG won’t include protocol experts.

By the way do you have plans to work with the Bluetooth SIG on URI schemes? At the very least it would be good to see some use cases where this is considered desirable.

Best regards,
   Dave Raggett <dsr@w3.org<mailto:dsr@w3.org>>

Received on Tuesday, 5 April 2016 07:37:06 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:26:58 UTC