<scribe> scribenick: kaz

Agenda

McCool: basically PlugFest but want to use 5mins for testing update

Testing updates

<McCool> https://github.com/w3c/wot/blob/master/testing/plan.md

McCool: testing updates
... testing plan document updated
... there are "ToDo"s
... thingweb playground is now scriptable
... there is still some issue to make it work correctly
... got this tool for test specifications
... extract normative assertions
... (shows normative assertions summary)
... have another PR to include all the tables
... need to work on assertions for that

Ege: testing topic is done?
... wanted to mention again that playground is scriptable

McCool: we can review the tools next time

PlugFest reports

McCool: several people updated their reports
... who would start?

Kaz: maybe starting with Matsukura-san?

<ryuichi> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/result.md

Matsukura: have made a template for the whole results
... want to give some explanation
... based on preparation.md format
... this report starts with section 3
... section 2 is servients list
... a table representing all the registered servients
... so would like to start with section 3 (as the actual reports)
... 3.1 Testing individually
... 3.2 Testing in Client Role
... 3.3 Testing in Server Role
... we started with simple description
... for the next PlugFest

Matthias: clarification question about OK/NG/NA
... did you define them?

Matsukura: OK is succeed
... NG is failed
... NA is couldn't checked this time

Matthias: ETSI PlugTest has 4 categories
... OK, NO, NA, Out of Time (OT)

Matsukura: OK
... can use that definition

Matthias: and you can add a legend at the top

Matsukura: ok
... (goes through the results)
... 3.1.1 validate simplified TDs
... Fujitsu, Hitachi, Panasonic: all OK
... Hitachi and Panasonic have some comments
... wanted to include Intel, etc., as well but couldn't

Kaz: do you want to the others, i.e., Intel, Oracle, Siemens, to put their information into this template?

Matsukura: yes

Matthias: just to make sure
... using this template for each company
... not directly into this file

Matsukura: right

Sebastian: playground is updated and the previous TDs are not valid

Matthias: maybe need to validate again
... in the future, playground should be configured for a specific version

Kaz: like HTML validator's having version switch :)

Matthias: yeah...
... but old versions are just drafts

Kaz: ok

Matthias: let's discuss this with Ege

Kaz: Matsukura-san, are you done?

Matsukura: yes

Kaz: maybe we can ask Kawaguchi-san and Toumura-san for comments?

Toru: key points are already covered by Matsukura-san
... can provide some more detail

Panasonic report

<kawaguch> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/result-panasonic.md

Toru: this is Panasonic results
... copied the content from the preparation-panasonic.md
... and then added the actual results
... the structure is similar to Matsukura-san's report
... (the report includes some diagrams/pictures)
... regarding individual testing
... not significant to mention
... registration with Thing Directory
... some issue is identified
... Interaction with things on Remote Proxy was NOT successful due to some internal issue of the proxy.
... and then
... 3.2 Testing in Client Role
... testing with Oracle
... some difference on how to interpret
... Oracle's Fest Simulator with following local modification.
... Changed "type" from "boolean" to "object" with "properties": {"PumpStatus" : { "type": "boolean" }}, to align with actual endpoint implementation.
... and testing with Intel
... ntel's Button, Light, Motion and RGB- Light.
... Issue: Only first binding could be chosen from Multiple HTTP bindings written in Intel's TD, since there seems to be no way to distinguish and specify particular binding through Scripting API (?)
... due to multiple security configurations
... not sure how to specify particular setting
... with multiple security configurations

McCool: iteration?

Toru: that's my understanding

McCool: would file an issue?

Toru: not yet

Matthias: if there are multiple bindings
... but if the first one works well
... why do you need to think about the second one?
... that's more about different binding?
... with scripting api, you don't have to care about that
... not a requirement for choosing which
... the use case with two bindings
... if there are 2 different bindings, you can test one with one servient
... and test another with another servient

McCool: big difference with latency
... possibly with different network setting
... this is maybe implementation detail, though

Kaz: Kawaguchi-san, do you want to describe this problem a bit more in detail?

Toru: should be clearly written within the Scripting API draft

Lagally: wondering about historical mark
... saying, e.g., "was part of (2)"
... maybe we can simply remove it?

Matthias: introduced that notation to see the historical changes

Lagally: are we suppose to compile one specific document for the results?
... what would be the best way?
... do people need to ready 10 different reports?

Matthias: ideally, you can describe the details within your report (result-oracle.md)
... and give feedback to the main document (result.md)

Lagally: make sense

Kaz: and Matsukura-san and Koster are encouraged to keep the main document updated?

Matsukura: yeah
... agree with Matthias
... summary document should be simple and easy to understand

summary report

Lagally: ok
... and agree

<mjkoster> i agree also

Kaz: Kawaguchi-san, are you done?

Toru: yeah

Hitachi report

<ktoumura> https://github.com/w3c/wot/blob/master/plugfest/2018-bundang/result-hitachi.md

Toumura: this is Hitachi's results
... only implemented the client side
... many checking points are not applicable
... but simplified TD was implemented
... same as Kawaguchi-san
... issue on how to handle multiple form entries
... not using scripting api but it's nice to have some guideline to select multiple forms
... and here 2nd problem
... implemented authentication methods
... basic, digest, bearer
... We need security metadata to designate HTTP header name for API key
... Panasonic's simulator uses "X-PWOT-TOKEN" header.
... for example, OpenAPI 3.0 uses following security metadata (see https://swagger.io/docs/specification/authentication/api-keys/)
... swagger has some feature for ApiKeyAuth

McCool: adding names to indicate it?

Toumura: yes
... on the other hand, server role was not implemented
... appendix includes the implementation detail
... please let me know if you have comments/questions

McCool: any comments/questions?

(none)

Goals for next plugfest

McCool: captured result template, Panasonic, and Hitachi
... we need to seriously plan the PlugFest and the online PlugFest
... we can go into the detail today

<mkovatsc> Doodle

Matthias: Doodle poll for online plugfest
... Friday won't work for me for the 2nd option

McCool: when to make the decision?

Matthias: 2 weeks?
... to get responses from our usual suspects :)

McCool: it's more than just putting things online
... should setup servers for security as well
... need VPN setting
... instructions on how to get connected
... we can create some possible sub nets as well
... like simulated local network
... is it possible to have WebEx for the whole week?

Kaz: yes

McCool: should we put information on the wiki?

PlugFest wiki

Matthias: we should have a sub directory on GitHub

Koster: yes

McCool: who should take the lead?

Matthias: can provide some MD file

McCool: ok
... Matthias to provide MD files under the new subdirectory
... the final topic is yet another doodle for the plugfest/testing calls
... combined or separate

Matthias: why do we need to separate the call?

McCool: can continue the joint call
... for now, let's keep it combined
... e.g., for the next week
... let's not do a separate meeting for now

[adjourned]