<kaz> scribenick: mjkoster
<kaz> prev minutes
(accepted)
<kaz> Scripting API draft - Conformance section
<McCool> Looks like scripting API making some progress on marking normative assertions
<McCool> also they do have the conformance text now
<McCool> https://rawgit.com/zolkis/wot-scripting-api/master/index.html
https://github.com/w3c/wot-thing-description
McCool: will ask about progress on Friday at the TD meeting
<inserted> kaz: got some feedback from the CSS WG about how to extract assertions from specs:
[[
1) Blocks of normative text: split the document in sections at H1-H6, remove well-known non-normative sections based on their ID (status, bibliography, ToC, etc.), remove other non-normative sections based on their first line containing "is informative" or "is not normative", and remove notes (class=note) and examples (class=example). But extracting individual assertions from the remaining text would require knowledge of English.
2) All CSS properties and descriptors with several of their characteristics (property-specific syntax, inheritance, media). Properties are rather well marked up, because various tools rely on that mark-up (such as Bikeshed, which makes alphabetic indexes and cross-references).
3) The productions of the generic syntax of CSS and productions that are shared by several properties are often, but not always marked up with class=prod. This is less consistent, because nobody in the WG itself extracts them automatically. For some parts there are no productions at all, because they have been replaced by an example top-down, left-to-right parsing algorithm in English.
]]
(toumura leaves)
McCool: will clean up and create a
conventions section
... based on these 3 items
... there needs to be a conformance section
kaz: initial sentence at the beginning of each section to indicate whether it is normative or informative
McCool: next step is extraction of
normative statements to create test cases
... security and bindings are informative
... binding templates will be incorporated into TD and have
some normative content at that point
McCool: example of a remote access
thing
... has basic auth as a security example
... planning to host a Thing Directory also
<kaz> Online Test Things
McCool: people should put things
online for remote access
... can the Oracle implementation be available online?
Lagally: it is online since
Prague
... want to give people some hands-on help and be careful about
access
McCool: we need a way to distribute credentials
Matthias: want to discuss setup for the
AC meeting
... what things are safe to use
in the Panasonic demo? What about the blinds?
... tried the hangout but couldn't get the lab camera
Kawaguchi: will check into it
Matthias: will be set up to pitch WoT
during the entire session
... has a Nabaztag bunny for control
McCool: what security protocols will
we support
... time to start on the preparation documents
... can we make it easier to record results?
Matthias: the result document is easy to use, it is a good summary
McCool: thinking about a template per
project
... each one can be smaller
kaz: would it include all of the elements, including proxy, etc?
McCool: yes, separate documents for each project
Matthias: it might go too far to the
fine grain extreme and result in too many small documents
... maybe there is some balance where common components are
documented together
McCool: we should try to have some
basic security implemented
... what is expected to be supported by node-wot for the next
plugfest?
Matthias: bearer token and http basic
are implemented
... could add digest
McCool: we should work up some
scenarios
... would be good to have an ACE interoperability test
Matthias: can we make a security
questionnaire and make it demand driven?
... some way to pick from a few options
McCool: what about planning separate meetings for testing and plugfest?
Koster: eventually will need a separate planning cycle for the plugfest
McCool: still developing an overall test plan
<kaz> [adjourned]