Meeting minutes
Minutes
McCool: (asks about Oracle's testing status)
Lagally: (mentions some
problems with ReSpec)
… RFC keywords still written in lower
cases
McCool: let's come back to the minutes review itself
(minutes approved)
Architecture Implementation Report
McCool: talk about the
Architecture implementation status again
… (shows the latest HTML of the Architecture
Implementation Report on his PC locally)
… (and explains what McCool's assertion tool
does)
Lagally: the tool detects the keyword [[class="rfc2119-assertion"]]. right?
McCool: right
(some more discussion about how to deal with the mechanism.)
Lagally: wondering about how to deal with non-MUST assertions
McCool: policy
suggestions?
… we could make them lower cases
… the question is which the assertion is, policy
issue? or deployment issue?
Lagally: some of the
assertions can't be tested, I'm afraid
… and also wondering about optional features and
"MUST NOT" features
McCool: still need two
implementations for optional features
… and regarding "MUST NOT" features, probably we
need to see the features would fail
Kaz: right
… note that from the W3C process viewpoint,
"Testing" for specs is not "testing the implementations as
products" but "checking if the spec document is
implementable"
… and we need to get two interoperable
implementations even for optional features
Kaz: we should clarify
what is really required for an implementation to be a conformant
WoT Architecture implementation
… and I personally think the WoT Architecture spec
itself should concentrate on the basic architecture design, and the
detailed behavior should be described by the children specs like
TD
… and all the concrete tests also can be handled by
the children spec side
… so would suggest we add that kind of Editor's
Note instead of testing all the details on the WoT Architecture
side
Lagally: I think this level of behaviors should be tested as part of the WoT Architecture specification
Kaz: don't necessarily
mean we should transfer all the assertions to the children
specs
… but we should check again which assertions
can/should be tested by which child spec
… if some of the assertions can/should be tested by
the child spec side, we don't need to care about them on the
Architecture side as assertions
McCool: some of the assertions like requirements for TLS are important and should be part of the assertions for the WoT Architecture
Lagally: we can still check the implementation status using the existing implementations like node-wot
Kaz: yeah, I think
that's inline with my suggestion
… we still need to clarify which of these proposed
assertions should be include in the final assertions to see if an
implementation is a conformant WoT Architecture
implementation
… and how to test all the assertions for that
purpose
Lagally: let's have discussion during the Architecture call tomorrow
Plugfest
McCool: do we wan to
hold Plugfest, e.g., during the Post-TPAC meeting?
… week of September 26
Lagally: Architecture should not need additional testing
Kaz: just to make sure,
do we really mean "Plugfest"?
… maybe "Testfest" instead?
McCool: right
… so focus on Profile testing
… Architecture shouldn't need additional
testing
Lagally: wondering if we need two Things and two Consumers
McCool: node-wot can be used as a generic Consumer
Lagally: Toumura-san's NodeRED also can be considered?
McCool: right
Kaz: we can of course
reuse the existing WoT implementations for WoT Architecture
testing
… but we need to provide WoT Architecture
assertions so that implementers can check if each WoT Architecture
assertion is testable, and how they can test it
… if we need to require manual test for some (or
all) of the assertions, that's still fine
… but we need to show how to test them to the
implementers
Lagally: would do the things incrementally
[adjourned]