<scribe> scribenick: zkis

Future testing work

McCool: we need tests for all TD consumer and exposed Things
... node-wot acts as universal consumer
... but we need test coverage
... so what can we do about testing

Daniel: we have an open issue on the testing and test framework

McCool: for scripting, maybe there is a separate testing
... for some things are not visible for Scripting, like security configurations

Kaz: when we say "testing" here, it's not the procedure for the recommendation track alone but it has a wider scope?

McCool: we need to verify every feature in implementations of consumer and producers
... now most tests are focused on producers
... what we lack is the consumer side
... can we say node-wot is a consumer that implements all features in the spec?
... which features can be tested with scripts and which ones cannot
... we should create those feature lists

Kaz: the transition requests for Architecture and TD are approved but Scripting is not on the REC track
... so this discussion is not related to the PR process for Architecture and TD
... and this is part of bigger testing discussion

Daniel: even then we should indeed look into how to test the Scripting API itself and also using Scripting in testing consumers and producers

McCool: Scripting is not in the Rec track, but it could be.

Zoltan: we should raise the interest of browser makers

<dape> https://www.w3.org/WoT/IG/wiki/Implementations

Daniel: we have asked about WoT implementations in 2016
... we need to come up with a way to identify if an implementation is WoT compliant and how much

McCool: that's why we should have a test suite

Public minutes

Zoltan: on meeting minutes: they will be public. Propose to have 1 week review period and if there are no correction suggestions, previous minutes are accepted as the first agenda point in meetings.

Daniel: why do we need one week
... other WGs publish immediately, why not follow the same?

Kaz: during the Architecture call and the TD call last week, there was discussion and for the first week people preferred there is trial about waiting for 1 week and then publish
... we can talk about this again during this week and if all agree in distributing immediately, we can do it

McCool: minutes should be reviewed for accuracy;
... the draft is published on the mailing list, if nothing comes up then we can publish it
... and yes, we should follow the same rules in all TFs

issues

https://github.com/w3c/wot-scripting-api/issues/200

Zoltan: we should make a PR about this hopefully this week

https://github.com/w3c/wot-scripting-api/issues/199

Daniel: we can set write handlers even though the Property is not writeable

Zoltan: the write handler would define the error handling
... will make a comment and wait for other people's input

Daniel: the next issue is about TD updates

https://github.com/w3c/wot-scripting-api/issues/198

Daniel: we made a PR that is not going to be included in the final document, only in the next version

Zoltan: so implementations could use different contentType vs DataSchema combinations, but the implementation should encapsulate that

McCool: it is indeed possible to transform e.g. from XML to JSON in order to be able to represent as an object

Daniel: in node-wot we also support plain string that is not JSON
... internally we have a blob and a marker that tells if a binary block is XML or JSON
... later you can parse it

https://infra.spec.whatwg.org/#json

Daniel: DataSchema only defines the structure of the data on the wire

Zoltan: but do we want to expose that DataSchema in a binary form to the app, rather than transforming to JSON?

McCool: actually at the Scripting (not internal) level, we need a DataSchema being JSON

Zoltan: to summarize, we have data, and data structure. Data structure is defined by contentType and eventually additional DataSchema.
... when there is contentType+DataSchema, then the DataSchema presented to the app should be JSON?
... or could be XML?
... we need use cases why we need to present other than JSON (in Scripting)

adjourned