- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Wed, 26 Jul 2017 23:18:37 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2017/07/26-wot-minutes.html also as text below. Thanks a lot for taking the minutes, McCool! And thank you very much for joining the call, Benjamin! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT IG/WG 26 Jul 2017 See also: [2]IRC log [2] http://www.w3.org/2017/07/26-wot-irc Attendees Present Achille_Zappa, Barry_Leiba, Ben_Francis, Daniel_Peintner(IRC_only), Dave_Raggett, Katsuyoshi_Naka, Kaz_Ashimura, Kazuaki_Nimura, Kazuo_Kajimoto, Keiichi_Tokuyama, Kunihiko_Toumura, Masato_Ohura, Matthias_Kovatsch, Michael_Koster, Michael_McCool, Ryuichi_Matsukura, Taki_Kamiya, Tomoaki_Mizushima, Yongjing_Zhang Regrets Chair Matthias, McCool, Kajimoto, Yongjing Scribe McCool Contents * [3]Topics 1. [4]Agenda bashing 2. [5]Mozilla, Ben Francis - Web Things proposal/contribution 3. [6]F2F update * [7]Summary of Action Items * [8]Summary of Resolutions __________________________________________________________ <kaz> scribenick: McCool Agenda bashing <scribe> agenda: mozilla's contribution, f2f recap if time last week no mtg due to people travelling <mkovatsc_> [9]https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#26_July_2017 [9] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#26_July_2017 note: ocf liaison meeting suspended in favor of protocol binding meeting, which a doodle will be sent out for shortly johannes won't be able to contribute to node-wot/SA, so we will have to figure out how to fill in Mozilla, Ben Francis - Web Things proposal/contribution matthias: see overlap, complementary parts ... status, roadmap, main concepts, etc. ben: until further notice <benfrancis> [10]https://hacks.mozilla.org/2017/06/building-the-web-of-thing s/ [10] https://hacks.mozilla.org/2017/06/building-the-web-of-things/ Mozilla is not a member of this group, but contributes elsewhere blog post: consider Web as unifying application stack three integration patterns (from Web Thing model from prior proposal) patterns: direct, gateway, and cloud three different levels can expose a "WoT API" Mozilla's project Things three parts: Things Cloud, Things Gateway, Things Framework so far, have implemented an OSS implementation of Things Gateway also have a TLS tunneling service to Things Cloud Web Thing API - mention ongoing work at W3C, IETF, and this work has a lot in common with previous and current work on "Web of Things", but more concrete have specific definitions in terms of encoding (JSON), API, etc. Web Thing API description includes properties, actions, events; also links "Thing Description" also define a Web Socket API six basic message types keep payloads as consistent as possible with the REST API main issue with WS is that you have to invent your own protocol also section on Web Thing Types have some built-in types, just like HTML has built-in-tags idea is that you could extend these with semantic tagging with JSON-LD discussing whether with JSON-LD 1.1 whether we can implement this Mozilla wants to figure out best way to collaborate going back to formal objection... felt certain parts were not mature enough Ben: does this fit within the scope of the WG, IG, or should there be a CG? how to move forward? matthias: short answers to some questions regarding google, tried to figure out concrete blocker the issue was more dependencies, eg we needed to specify a "main deliverable" which we decided was the Thing Description we also determined that RDF etc is aligned with what Google is doing and, as can be seen with activity on iot.schema.org, Google is interested in this other comments: are lots of other IoT standards out there, we can't try to argue people over to yet another standard issue is domain knowledge so we want to go down a descriptive rather than a prescriptive approach gateway backend still has a lot of pain in the backend for integration; there is a lot of complexity there but we would like to use patterns from the web to make embedded interfacing easier but... some useful defaults for web interfaces would be useful so,Mozilla's proposal would be a "target proposal" for Web-based APIs long run, want to look at convergence of different technologies but this will take time... look how long it took for the web ben: want to sell idea of WoT to web developers our experience is that some things will appeal to them, others will put them off our concern is that semantic web technologies can make things look too complex so... want something simple as the first view for web developers so... see plain JSON encoding as good complement to current work want to avoid too much complexity current proposal has a log of x-agnostic components which add a lot of complexity matthias: in work on charter, also got this feedback... some parts are fuzzier than they should be, but as we have done the work things have become clearer for instance, for scripting API, in principle should be language-agnostic but what we work on right now, and what will be in first spec, is JS and is concrete similar to what's in web browsers we are aiming for a narrow waist... using Thing abstraction for everything, including system services SA overall is optional as well: people don't have to implement, but has been very useful other issue was RDF, etc. we do want a mode where people can work with a hard-coded vocabulary and can avoid the complexity of full RDF ben: personally skeptical of SA, have seen similar work... feel it is the wrong layer of abstraction to standardize should be about linked resources and web APIs but do understand that is the current charter what mozilla wants to figure out is the best way to collaborate matthias: first, we are looking at other serializations of TD we have been using JSON-LD, which comes for "free" but we have also been discussing others, eg. a plain JSON serialization this can definitely be done in IG, but maybe in WG other part is protocol bindings Moz proposal is prescriptive but, if we do a web-style interface, if "defaults" does something like Moz's proposal, then TD should be simple ben: provides metadata, but also links to resources our take on WoT is that is gives things URLs but they don't think it makes sense to extend to non-web protocols matthias: WG charter definitely covers serialization formats for TD schedule is part of the reason we pushed back right now JSON-LD works... but on the roadmap we definitely would be willing to look at other serializations ben: in terms of timelines... plain JSON format can be fairly quick if based on concrete model rather than trying to encode general-purpose abstract model ben: but, things are still in flux; not sure it will be stable soon matthias: so that sounds more like IG work <dsr> [11]http://iot.mozilla.org/wot/ [11] http://iot.mozilla.org/wot/ dsr: see that positioned this as w3c submission do you still want to go down that formal path? <dsr> [12]https://github.com/w3c/wot/blob/master/proposals/dsr-td/jso n-to-ld-dsr.md [12] https://github.com/w3c/wot/blob/master/proposals/dsr-td/json-to-ld-dsr.md also noticed that spec is very similar to what dsr proposed a while back and that provides a route to connect this to what we are doing think there is a way to connect this to what we are doing in both ig and wg ben: thanks for all the lively discussion ... not sure which route makes sense ... what is the most productive thing to do here? ... major difference is presence of links in TD... had discussion on github are those links part of TD or provided separately dsr: there are links elsewhere, are part of the overall story <dsr> Member submissions is a benefit for W3C Members, but in this case it seems clear that the submission would be directed to the WoT IG/WG, so a formal submission isn’t needed <kaz> +1 <kaz> McCool's point on descriptive api <mjkoster> if anyone is interested in what the IETF is doing, please come participate <mjkoster> the discussion Ben refers to is already taking place in the relevant bodies in IETF kaz: would also appreciate Ben's contribution and participation in this call today and would also like to mention there are several paths and collaborations for this proposal for instance, auto wg has been looking at websocket-based interface and got VW's Member submission on similar mechanism (websocket + REST) however, probably the best solution for this proposal is bringing this directly to the WoT IG ben: auto wg reminded me... is a good example of offline or local collaboration and security etc is a big problem... having issues with HTTP, DNS, etc. kaz mentions the wot group has been holding joint meetings with the automotive wg at TPAC to think about possible collaboration about issues, e.g., on HTTPS, DNS, WebSocket have also been looking at automotive as possible use case for WoT work matthias: many topics... most important, perhaps topic on convergence but doesn't feel this will work with prescriptive approach but each ecosystem is still interested in connecting to others so they were interested in descriptive approach so... not pushing them to change their path so see TD as a way to help people converge for instance, if less-complex TD results, then will encourage adoption of common patterns ben: to re-iterate, want to get web developers to adopt technology but the more general approach is also more complex ben: is this something that a web developer can "get"? matthias: we have to figure out the best tradeoff maybe we can even consider a "lossy" serialization also have to consider audience: industrial, home, hobby, etc ben: definitely talking about real commercial applications prior experience was with web apps what eventually went out was progressive web apps, was very simple but seeing good takeup. ben: personal observation, new apis are a subset of the work ... yes, agree it is about finding the right balance matthias: would be nice if we can align it a bit; perhaps break it down into components? main point is that there are just a few things that were issues: hard-coded URLs, must be HTTP, etc. want to figure out how to present in a unified way, not create more fragmentation ben: interaction model ... dsr and I were discussing whether there is an enforced URL structure? <dsr> (more about simplifying the work needed by developers through convenient defaults) matthias: why we went just back to interactions was to make things look more like forms so there was just one way to build things; more flexible makes it easier to add additional interaction patterns later also had thought about URLs for non-HTTP/CoAP protocols could register a URI Matthias: there was also some comments about HTTP2 but... "big web" people were not so interested in IoT did not get eventing model right, esp for small constrained devices <mjkoster> there is plenty of discussion on these questions in IETF and a lot of ideas also, IETF/CoAP working group did look at offline security issues already it may take another decade for HTTP to catch up ack <mjkoster> perhaps Mozilla should also participate in the relevant IETF WG for http, CoAP, httpbis <kaz> [13]TPAC schedule fyi [13] https://www.w3.org/2017/11/TPAC/schedule.html kaz: would be great if Ben could join the WoT IG as an official participant recap: summarize, next steps <dsr> It would be great to include the Mozilla approach in the next plugfest at TPAC we are both aware of usability tradeoffs it is certainly in the charter to look at alternative serializations can definitely start a tf to look at other serializations maybe we can have an additional meeting to get up to speed on current status should get better over the next few months as we nail down first working draft big more long-term, moz will try to look at TPAC participation could look at interoperation between the two approaches <kaz> [ note that the WoT group will meet on Monday/Tuesday (=Nov. 6/7) during TPAC 2017 in Burlingame ] ben is in the UK, so not "local" in SF also for security TF, need to consider the issues with HTTP <mjkoster> mjkoster is in Mountain View <mjkoster> ...and would be happy to meet with some of the project members <kaz> mccool: we're starting the binding tf and think about event handling as well <kaz> ... should look into Mozilla's proposal as well <kaz> ben: hope it would be better to see what would be the best solution eventing model... less obvious clear single solution <mjkoster> I want to use MQTT mccool: at any rate, a concrete action we can take is to describe the web socket approach at least dsr: there are various other issues with rebooting, etc. matthias: have to look at what devices are out there ben: eventing is a big challenge, but MQTT is "not the web", so... <mjkoster> websockets is more sockets than web ;-) matthias: also some IETF activity looking at eventing as said earlier, "big web" is not so much interested in this different approaches with state update (eventual consistency) and "real" events ben: also clear that more work needs to happen at IETF to deal with issues with HTTP and DNS, etc. F2F update matthias: should be use last ten minutes on update on F2F? <kaz> +1 <mjkoster> agree on the IETF comment, would like to see Mozilla participate <kaz> [14]Dusseldorf f2f minutes fyi [14] https://www.w3.org/2017/07/09-13-wot-minutes.html matthias: next F2F will be at TPAC <kaz> [15]future f2f planning [15] https://www.w3.org/2017/07/wot-f2f/slides/2017_F2F-Dusseldorf-Next.pdf ben: wg/ig joint? matthias: yes, some parts are more exploratory note also that IETF is right afterwards in Singapore so we want to avoid doing things after TPAC <kaz> [16]TPAC 2016 agenda fyi [16] https://www.w3.org/WoT/IG/wiki/F2F_meeting,_September_2016,_Portugal,_Lisbon#WoT_IG_Agenda note: we will target IEEE security conference with a separate event, not try to co-locate with F2F note also IETF changed dates to go to Montreal rather than the US Oct next year will be in Lyon matthias: (review of slides on deliverables) <kaz> [17]TF list [17] https://www.w3.org/2017/07/wot-f2f/slides/2017_F2F-Dusseldorf_ModularizationWork.pdf <kaz> [ adjourned ] Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes formatted by David Booth's [18]scribe.perl version 1.152 ([19]CVS log) $Date: 2017/07/26 14:08:59 $ [18] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [19] http://dev.w3.org/cvsweb/2002/scribe/
Received on Wednesday, 26 July 2017 14:19:44 UTC