- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Fri, 8 Mar 2019 12:22:01 +0900
- To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
Sorry I've found the subject line was wrong, and am resending with a correct subject "27 February 2019" to make sure. Kazuyuki On Tue, Mar 5, 2019 at 4:32 PM Kazuyuki Ashimura <ashimura@w3.org> wrote: > > available at: > https://www.w3.org/2019/02/27-wot-pf-minutes.html > > also as text below. > > Thanks a lot for taking these minutes, Ege! > > Kazuyuki > > --- > > [1]W3C > > [1] http://www.w3.org/ > > - DRAFT - > > WoT TestFest > > 27 Feb 2019 > > Attendees > > Present > Kaz_Ashimura, Michael_McCool, Ege_Korkan, > Kunihiko_Toumura, Michael_Lagally, Taki_Kamiya, > Toru_Kawaguchi, Tomoaki_Mizushima > > Regrets > Matthias > > Chair > McCool > > Scribe > ege > > Contents > > * [2]Topics > * [3]Summary of Action Items > * [4]Summary of Resolutions > __________________________________________________________ > > <kaz> scribenick: ege > > McCool: review where we are > ... (shows implementation report) > ... changes to the TD repo added new assertions > ... most of them have to do with the context > ... some of them can be tested with JSON Schema but some other > ones like URL should be dereferencable, we cannot test with > JSON Schema > ... there are duplicates > ... we need to create context at form and security level > ... I think we have to assume to keep these context assertions > > Kaz: this is great. thank you! > ... on the other hand, please remember that for CR transition > what is required is clarifying all the assertions based on the > spec > ... fullfilling all the assertions with concrete results is not > required > ... getting concrete results earlier is of course nice, though > > Ege: can we leave all of them not tested for CR > > McCool: we can test all of them manually > ... at the worst case, we can ,ake them "features at risk" > > Kaz: note that having 20 features as "features at risk" would > not be good > > McCool: these are all related to one issue, context > ... some are, like scopes, are very easy to fix > ... panasonic added some examples > ... so if some other companies do that too, it will be fine > ... ege do you know why this td-data-schema-objects is not > tested > > Ege: I don't know, I will write an issue for it > > McCool: I should mark some as resolved > ... this is related to some subitems, td-event-names > ... there is also multi languages missing > ... we also need uriVariables > > Ege: urivariables in events are complicated > > McCool: each time I see 0s it looks weird > ... td-forms is not tested? > ... i think we miss a test here > ... ege you should go through this list here > > Ege: yes I can do that > > <Zakim> kaz, you wanted to ask about (1) whether this > report.html is generated based on the CSV files manually > generated (or using the assertion tester) and (2) if this > result includes all the results from Princeton TestFest > > Kaz: I just want to make sure > ... are these manual or automatic > > McCool: both > > <McCool> > [5]https://github.com/w3c/wot/tree/master/testfest/2019-03-onli > ne/templates > > [5] https://github.com/w3c/wot/tree/master/testfest/2019-03-online/templates > > McCool: (shows the directory) > ... panasonic had some updates as well > > Kaz: so you merged automatic and manual > > McCool: yes > ... (explains how the merging works) > > Kaz: I wasn't so sure whether these were equal > > McCool: they don't overlap > > Kaz: it would be nice to explain the fact that the inputs > directory includes both the manually tested CSVs and the > automatically tested CSVs, and the covered areas of assertions > are different between them (manually tested CSV and > automatically tested CSV) > > Ege: in the readme maybe? > > McCool: documentation is there if you look at the update.sh > script but it would be clearer to split the "inputs" area into > 2 pieces, one for manually tested CSVs and another for > automatically tested CSVs. let me think about that. > > Ege: the links are not valid anymore in the descriptions > ... we have /inputs instead of /TDs anymore > > Lagally: something has changed > > <McCool> > [6]https://github.com/w3c/wot-thing-description/tree/master/tes > ting/inputs/implementations > > [6] https://github.com/w3c/wot-thing-description/tree/master/testing/inputs/implementations > > McCool: the readme is not that important but the html > descriptions are > ... I will edit them > ... I have highlight for all the assertions, gray by default > and yellow if it is at risk > > Lagally: why is that name assertion yellow > > Ege: this must because of the name being similar > > McCool: (explains the bug) > > Lagally: there is something wrong with description as well? > > McCool: it seems so > ... this happens because of the render > ... and I can't change it easily > ... maybe it is because the data is not provided but still > marked as risk > > Lagally: can we go through the spec and do a sanity check? > > McCool: there is the content-type as well > ... we have two contentType at the output data > ... but only one here > ... somehow handling multiple assertions is not good > ... highlighting is not being generated right > ... I can go over them manually and change the ids > ... it is kind of tricky > > Lagally: it is important to know whether some specs will go out > of the spec > > Summary of Action Items > > Summary of Resolutions > > [End of minutes] > __________________________________________________________ > > > Minutes manually created (not a transcript), formatted by > David Booth's [7]scribe.perl version 1.154 ([8]CVS log) > $Date: 2019/03/02 23:59:32 $ > > [7] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm > [8] http://dev.w3.org/cvsweb/2002/scribe/
Received on Friday, 8 March 2019 03:23:08 UTC