- From: Dave Raggett <dsr@w3.org>
- Date: Mon, 4 Apr 2016 15:21:07 +0100
- To: "Kovatsch, Matthias" <matthias.kovatsch@siemens.com>
- Cc: "Claes1.Nilsson@sonymobile.com" <Claes1.Nilsson@sonymobile.com>, "public-wot-ig@w3.org" <public-wot-ig@w3.org>
- Message-Id: <CFCAC0EB-C009-4C96-AF68-3DF73BC18AE8@w3.org>
> On 4 Apr 2016, at 14:42, Kovatsch, Matthias <matthias.kovatsch@siemens.com> wrote: > > Von: Dave Raggett [mailto:dsr@w3.org <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://** <ble://**>*******” or BACnet-specific addressing into a string like “bacnet://** <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 Monday, 4 April 2016 14:21:28 UTC