W3C

- DRAFT -

WoT-PF/Test

07 Nov 2018

Attendees

Present
Kaz_Ashimura, Michael_McCool, Taki_Kamiya, Dave_Raggett, Michael_Lagally, Kunihiko_Toumura, Takeshi_Yamada, Tomoaki_Mizushima, Toru_Kawaguchi, Ege_Korkan
Regrets
Chair
McCool
Scribe
kaz

Contents


<McCool> https://www.w3.org/WoT/IG/wiki/PlugFest_WebConf#Agenda_07.11.2018

Timeline

McCool: go back to the requirements
... don't have to complete testing work before CR but strongly recommended to do so
... highly desired for us to do that
... given the 6-month extension
... aiming April is dangerous
... maybe the end of March at the latest?
... or CR to be submitted end of Feb
... practical deadline might be end of March
... candidate release end of Dec

Kaz: our initial updated deadline should be Feb at the latest

Telco slot

McCool: pros and cons with this slot
... suggested we use the binding slot
... do we need another doodle?

Kaz: note Koster is not available today

McCool: he's not available once a month
... would see the conclusion of the TD tf
... maybe we can hold a simple doodle
... the binding slot or the current slot
... and see if people would be available
... if not we can try another slot
... to be clear, next meeting will be at this slot next week
... any comments?

(none)

Testing plan

McCool: how to handle testing?
... the main testing repo and possibly subdirectories of TD
... we should create a new main testing repo
... separate repo for test suite?

Kaz: we need two test suites, one for TD and another for architecture

McCool: TD is the main one
... e.g., checking the validity of a TD
... need many behavior tests

Dave: TD validation itself is not required for CR exit criteria

Kaz: right. that's why I've been asking people to extract assertions from specs

(discussion about what is expected)

Kaz: thought plugfest reports by a, b, c could be a starting point

McCool: would like to generate an initial list of assertions

Taki: description about implementations for the implementation report

Dave: possible review by the other groups?

Kaz: possibly accessibility, i18n, etc.

McCool: still wondering about validity of TD formats

Kaz: that depends on the TD spec
... if validity itself is the feature of TD spec, we should add description to TD spec

McCool: let's think about the structure of testing first

Ege: we have property expecting server to send out
... might have an assertion about that expectation using some JSON object

<dsr> I don’t agree that actions should always produce the same output given the same input.

<dsr> That relates to application semantics

<kaz> right

Kaz: we can add any kinds of additional resources to each assertion later
... and we need to extract assertions from the spec as the starting point

McCool: we can create sample TDs to test assertions
... test plan document can be a CSV file initially
... test result document would be a table
... explains how to extract assertions

Kaz: we can extract key features manually from the TD spec
... and also extract structural features from the Turtle files possibly
... anyway we should see what are expected to be extracted as assertions by revisiting previous implementation reports, e.g., the one for EMMA

EMMA implementation report as an example: https://www.w3.org/2002/mmi/2008/emma-ir/

McCool: would like to review that offline

Lagally: btw, there is a pullrequest for Oracle plugfest report

[adjourned]

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/11/07 16:34:26 $