<McCool> https://www.w3.org/WoT/IG/wiki/PlugFest_WebConf#Agenda_07.11.2018
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
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)
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]