- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 15 Feb 2019 15:15:26 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at: https://www.w3.org/2019/02/13-wot-minutes.html also as text below. Thanks a lot for taking these minutes, McCool! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT-IG/WG 13 Feb 2019 Attendees Present Kaz_Ashimura, Dave_Raggett, Matthias_Kovatsch, Daniel_Peintner, Kunihiko_Toumura, Michael_Koster, Michael_Lagally, Michael_McCool, Taki_Kamiya, Tetsushi_Matsuda, Tomoaki_Mizushima, Toru_Kawaguchi, Zoltan_Kis, Sebastian_Kaebisch, dsr, Ege_Korkan Regrets Chair Matthias, McCool Scribe McCool Contents * [2]Topics 1. [3]Agenda 2. [4]Scripting 3. [5]Quick updates * [6]Summary of Action Items * [7]Summary of Resolutions __________________________________________________________ <scribe> scribenick: McCool Agenda updates to org to be distributed via W3C marketing; IG renewal, updates to chairs and affiliations Scripting Zoltan: security section on runtime in arch docs <zolkis> [8]https://github.com/w3c/wot-scripting-api/pull/155#issuecomme nt-442830910 [8] https://github.com/w3c/wot-scripting-api/pull/155#issuecomment-442830910 Matthias: definitely does not belong in TD ... can it be extended to other scripting ... can it be generalized? Zoltan: yes it can be generalized Matthias: if it can be generalized, arch is a good place ... but maybe more implementation guidance ... notions of provisioning, etc. are there as well, don't belong in scripting ... if too long compared to other content kind of awkward ... would be good to move into a branch McCool: elena did this PR, she probably has to do the PR reorg Matthias: ok Lagally: would be good to have final cleaned up text in a pr Zoltan: the text is good, it's just the discussion about where it goes ... is a pr is both places McCool: pr in scripting is to remove things from scripting that we wanted to move to arch <zolkis> [9]https://docs.google.com/presentation/d/1HN15VhjCcZEjrSllFSUV xUWiYhxFdslx80EtyJObNeo/ [9] https://docs.google.com/presentation/d/1HN15VhjCcZEjrSllFSUVxUWiYhxFdslx80EtyJObNeo/ McCool: but can leave the PR for now and reorganize it Zoltan: sharing slides on examples for new scripting API <mlagally__> mlagally: we wait for a new security PR against the architecture doc and don't consider the current one matthias wanted to get some clarification Matthias: want to have concrete reasons for each design decisions ... felt that information was missing Zoltan: did you see the design document? That was the main driver Matthias: it would be good to summarize the reasons in the slides ... for example, why are there constructors that are not used? Zoltan: but they are used... ... today, before this meeting, got some comments from kenneth ... he had some issues with "getting" event names ... since events happen, you don't "get" them ... matthias was asking about integrating with fetch standard ... but looks very complicated Matthias: fetch is just there to get a document Zoltan: but then we have to add a section to explain how to use it ... but you seem to agree with ben that we should use document fetch Matthias: but everything was removed from the wot object except fetch Zoltan: that is true, but where else would be put it ... anyway, we got that comment ... another issue, programmatic TD specification ... this is a separate use case ... takes a lot of boilerplate ... just for creating a JSON document out of JSON object ... it is very long, as long as the TD spec ... do we have this use-case justified, and is there an easier way? ... the question is, do we want to stay with the node API, or make it W3C compatible McCool: I don't know why we can't just create a JSON object and validate it ... that would be a very simple API Zoltan: there are a lot of issues with type conversions and so forth <Zakim> dape, you wanted to maybe we can even leave out "fetch" in general from scripting Daniel: not opposed to make some changes to move towards browser ... moving towards browser, but don't have support from browser vendor ... if they tried to implement it they would have further changes ... so we are not sure we are filling their needs ... we would need a lot more feedback from them Zoltan: that is why I made these side-by-side changes ... it is not that many changes ... is it just a style thing? ... personally I think the change is not that much, just style Dave: want to respect the tag's opinion ... but they may not reflect those of the browser vendors ... we should also be reaching out more broadly to dev community Zoltan: I also asked (?name) who is a member of the node community Dave: different communities as well, node, web devs, etc. ... maybe we need more than one api ... but we really do need to reach out Zoltan: sure; how do we do it? Dave: well, the usual things, blogging, etc. ... I don't think a simple questionnaire is enough ... people need to try it Zoltan: so maybe we don't standardize things yet, we should do oss implementations first ... so are aligning with mozilla that we should not really standardize this Dave: at least we should reach out more broadly Zoltan: so node-wot would not be an implementation of a W3C spec ... how do we position the current API? Matthias: central issue is that no structure to the problems we have ... need to better structure issues, resolutions ... also, scripting API is not a standard, just a note ... we have failed to come to a consensus on this ... but good to at least have a note that captures what we have and the design decisions for them ... at TPAC we decided to document what we have now Zoltan: so, what is the next step? Matthias: need some clear consensus on group that we are not doing a standard, just a note ... also important for arch document ... docs say we are just doing a note Zoltan: yes, we agree on that Matthias: a lot of people in this round were saying "standardization", want to make it clear we are not doing that Zoltan: what is not clear is what should go in the note ... one option is to make a note from the current content ... and use an interface description, not WDL ... if we go and make small changes, then can use WDL McCool: maybe we should publish both, get feedback ... also, keeping current spec minimizes rework on node-wot ... we could then publish another spec with the new interface, ask for feedback Kaz: think there are 2 levels of problems here; policy level and technical level; for the technical discussion, we've been talking with Yves and PLH, also possible discussion during the expected workshop; on the other hand, we need to talk about the policy level, i.e., which way to go ... should happen before technical level discussion sebastian: agree with McCool; have two notes ... one on current API ... get it published ... one other thing in charter is a "simple API" ... that would be more compatible with browser ... anyway, let's complete the current one, then spend the time to target the browser ... that was my understanding of the outcome from Lyon Matthias: two notes is not a good idea... ... release a low-level API that we can build on ... technically from what I know, using the current API as a low-level API will be hard ... so something simpler would be better ... and zoltan's proposal is in this direction ... just want to see documentation of design decision McCool: summary, prefer moving to the proposal from Zoltan, BUT need to better document design decisions ... and don't think we should publish the current (complex) spec as a note Dave: have been working at Simple API... McCool: what is a better basis? a low-level layer? Dave: don't quite want to prejudge right now, but agree a low-level base layer is probably better Zoltan: ok, let's follow up in scripting call Matthias: one final point, since it is a note, we don't have to do testing, validation, etc. McCool: this information is in the minutes, but should probably be in the wikis <dsr> Just for the record, I want to explore things as property values in the high level API Quick updates <Zakim> kaz, you wanted to make some reports :) Kaz: quick reports ... I've been attending the W3M meeting ... and the workshop has been approved, yeah ... also mentioned a proposed subtitle, "an open web to challenge IoT fragmentations", during the call, and got a comment to say "fragmentation" instead since it's uncountable ... note possible change to the workshop date ... currently 27 May-29 May but 27th is a bank holiday in the US ... so Siemens is looking at option to move the event a bit ... have not gotten feedback yet on that ... when hear, will let people know ... also IG extension announcement was sent to the AC list ... finally, would like to wrap up the f2f minutes ... please review, would be good to wrap up next week <kaz> [adjourned] Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes manually created (not a transcript), formatted by David Booth's [10]scribe.perl version 1.154 ([11]CVS log) $Date: 2019/02/15 06:11:59 $ [10] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [11] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 15 February 2019 06:16:28 UTC