<scribe> scribenick: zkis
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
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
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