- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 03 Feb 2020 10:29:22 +0900
- To: public-wot-wg@w3.org
available at: https://www.w3.org/2020/01/13-wot-minutes.html also as text below. Thanks a lot for taking the mintues, Zoltan! Kazuyuki --- [1]W3C [1] http://www.w3.org/ - DRAFT - WoT-Scripting 13 Jan 2020 Attendees Present Kaz_Ashimura, Michael_McCool, Tomoaki_Mizushima, Zoltan_Kis, Daniel_Peintner Regrets Chair Zoltan Scribe zkis Contents * [2]Topics 1. [3]Future testing work 2. [4]Public minutes 3. [5]issues * [6]Summary of Action Items * [7]Summary of Resolutions __________________________________________________________ <scribe> scribenick: zkis Future testing work McCool: we need tests for all TD consumer and exposed Things ... node-wot acts as universal consumer ... but we need test coverage ... so what can we do about testing Daniel: we have an open issue on the testing and test framework McCool: for scripting, maybe there is a separate testing ... for some things are not visible for Scripting, like security configurations Kaz: when we say "testing" here, it's not the procedure for the recommendation track alone but it has a wider scope? McCool: we need to verify every feature in implementations of consumer and producers ... now most tests are focused on producers ... what we lack is the consumer side ... can we say node-wot is a consumer that implements all features in the spec? ... which features can be tested with scripts and which ones cannot ... we should create those feature lists Kaz: the transition requests for Architecture and TD are approved but Scripting is not on the REC track ... so this discussion is not related to the PR process for Architecture and TD ... and this is part of bigger testing discussion Daniel: even then we should indeed look into how to test the Scripting API itself and also using Scripting in testing consumers and producers McCool: Scripting is not in the Rec track, but it could be. Zoltan: we should raise the interest of browser makers <dape> [8]https://www.w3.org/WoT/IG/wiki/Implementations [8] https://www.w3.org/WoT/IG/wiki/Implementations Daniel: we have asked about WoT implementations in 2016 ... we need to come up with a way to identify if an implementation is WoT compliant and how much McCool: that's why we should have a test suite Public minutes Zoltan: on meeting minutes: they will be public. Propose to have 1 week review period and if there are no correction suggestions, previous minutes are accepted as the first agenda point in meetings. Daniel: why do we need one week ... other WGs publish immediately, why not follow the same? Kaz: during the Architecture call and the TD call last week, there was discussion and for the first week people preferred there is trial about waiting for 1 week and then publish ... we can talk about this again during this week and if all agree in distributing immediately, we can do it McCool: minutes should be reviewed for accuracy; ... the draft is published on the mailing list, if nothing comes up then we can publish it ... and yes, we should follow the same rules in all TFs issues [9]https://github.com/w3c/wot-scripting-api/issues/200 [9] https://github.com/w3c/wot-scripting-api/issues/200 Zoltan: we should make a PR about this hopefully this week [10]https://github.com/w3c/wot-scripting-api/issues/199 [10] https://github.com/w3c/wot-scripting-api/issues/199 Daniel: we can set write handlers even though the Property is not writeable Zoltan: the write handler would define the error handling ... will make a comment and wait for other people's input Daniel: the next issue is about TD updates [11]https://github.com/w3c/wot-scripting-api/issues/198 [11] https://github.com/w3c/wot-scripting-api/issues/198 Daniel: we made a PR that is not going to be included in the final document, only in the next version Zoltan: so implementations could use different contentType vs DataSchema combinations, but the implementation should encapsulate that McCool: it is indeed possible to transform e.g. from XML to JSON in order to be able to represent as an object Daniel: in node-wot we also support plain string that is not JSON ... internally we have a blob and a marker that tells if a binary block is XML or JSON ... later you can parse it [12]https://infra.spec.whatwg.org/#json [12] https://infra.spec.whatwg.org/#json Daniel: DataSchema only defines the structure of the data on the wire Zoltan: but do we want to expose that DataSchema in a binary form to the app, rather than transforming to JSON? McCool: actually at the Scripting (not internal) level, we need a DataSchema being JSON Zoltan: to summarize, we have data, and data structure. Data structure is defined by contentType and eventually additional DataSchema. ... when there is contentType+DataSchema, then the DataSchema presented to the app should be JSON? ... or could be XML? ... we need use cases why we need to present other than JSON (in Scripting) adjourned Summary of Action Items Summary of Resolutions [End of minutes] __________________________________________________________ Minutes manually created (not a transcript), formatted by David Booth's [13]scribe.perl version 1.154 ([14]CVS log) $Date: 2020/02/03 01:27:58 $ [13] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm [14] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 3 February 2020 01:29:31 UTC