W3C home > Mailing lists > Public > public-wot-ig@w3.org > December 2018

[Testing] minutes - 29 November 2018

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Sun, 2 Dec 2018 17:23:16 +0900
Message-ID: <CAJ8iq9UPDEtr3vwCw21=feAKPbC+yPus=URtyFMoM5KDGvNP7A@mail.gmail.com>
To: Public Web of Things IG <public-wot-ig@w3.org>, public-wot-wg@w3.org
available at:
  https://www.w3.org/2018/11/29-wot-minutes.html

also as text below.

Thanks a lot for taking these minutes, Taki!

Kazuyuki

---

   [1]W3C

      [1] http://www.w3.org/

                               - DRAFT -

                              WoT Testing

29 Nov 2018

Attendees

   Present
          Kaz_Ashimura, Michael_McCool, Dave_Raggett, Ege_Korkan,
          Taki_Kamiya, Tomoaki_Mizushima

   Regrets

   Chair
          McCool

   Scribe
          TK

Contents

     * [2]Topics
         1. [3]Status
     * [4]Summary of Action Items
     * [5]Summary of Resolutions
     __________________________________________________________

   <scribe> Scribe: TK

   <scribe> ScribeNick: taki

Status

   McCool: I did merge changes on main in TD.
   ... including scripts in main repo.
   ... goal is making progress.

   McCool is showing report.html

   McCool: I merged PRs.

   <McCool>
   [6]https://github.com/w3c/wot-thing-description/pull/294

      [6] https://github.com/w3c/wot-thing-description/pull/294

   McCool: One is 294.
   ... and 309. Scripts to merge test results.

   <McCool>
   [7]https://github.com/w3c/wot-thing-description/pull/309

      [7] https://github.com/w3c/wot-thing-description/pull/309

   McCool: updated report was also checked in.
   ... panasonic, intel and siemens descriptions are available.

   Dave: mine is available. I put it into a directory.

   McCool: I will grab it and merge it.

   Dave: Thanks.

   McCool: I made the report.html at the top level. I moved around
   files.
   ... Dave has 2. Client and hub

   <kaz>
   [8]https://w3c.github.io/wot-thing-description/testing/report.h
   tml

      [8] https://w3c.github.io/wot-thing-description/testing/report.html

   Dave: an implementation report from W3C/ERCIM as part of the
   F-Interop work.

   McCool: Impl.csv lists all implementations.

   Dave: ERCIM is the appropriate name as contributor according to
   the agreement.

   McCool is adding impl-ercim-arena-client and
   impl-ercim-arena-webhub to the csv.

   <kaz>
   [9]https://w3c.github.io/wot-thing-description/testing/report.h
   tml

      [9] https://w3c.github.io/wot-thing-description/testing/report.html

   Kaz: Can we use GitHub rendered version?

   McCool switching to w3c.github.io rendered version....

   McCool adding a rendered version to README.md

   McCool: We need to go through the assertion list
   ... How to test each assertion

   McCool is editing testspec.html...

   McCool showing "Test Specifications"...

   McCool: td-vocabulary. generic assertion.
   ... TD needs to be valid.
   ... What the client expects. Client needs to detect errors.

   Dave: It is syntax test, then.

   McCool: There are many sub-assertions.
   ... Security syntax is more complicated.

   McCool is editing td-vocab in testspec.html....

   Dave: What about behaviour?

   Kaz: From process's viewpoint, implementability of the
   specification needs to be tested. Datamodel and syntax of TD
   instead of behaviours.

   Dave: I disagree. Syntax is one. Behaviour needs to be tested
   as well.

   McCool: The list contains both.

   Kaz: TD spec is about data-model. Theoretically, CR-exit
   criteria is vocabulary and syntax.

   McCool: Let's get syntax stuff done in the list first.
   ... We need to discuss them one by one.
   ... td-unique-identifiers.
   ... name-value pairs, all ids must be unique.

   Ege: We can test it with a JSON-Schema rule.
   ... with "unique" (or similar) constraint.

   McCool: A specialized JSON schema will be written that checks
   this condition.

   Ege: The JSON Schema can also check other assertions.

   <kaz> Kaz: btw, I was wondering about the relationship between
   this Appendix A (test specifications) and the main assertion
   table

   <kaz> McCool: the text within Appendix A will be brought back
   to the assertion table. the point here at Appendix A is "test
   specification text"

   McCool: td-jsonld-keywords.
   ... this is about "MAY"

   Ege: @context cannot be a number, for example.
   ... It has to be JSON-LD keywords.
   ... @context has to be string.
   ... It cannot be numbers, booleans, etc.

   Dave: The spec should say TD is a valid JSON-LD.

   McCool: "td-context" restricts it.
   ... "td-context" can be considered as a parent.

   Ege: TD should be validated by JSON-LD checker.

   Kaz: Given the spec text (section 6.1.1) which caused this
   assertion, we should say something like:

   The root object of a TD instance MAY include the @context name
   from JSON-LD 1.1.
   and
   If it includes @context, the value MUST be (or MUST include)
   "http://www.w3.org/ns/td".
   ]]

   Dave: We should collect comments and take it to TD meeting.

   McCool: td-string-type.
   ... for example, type associated in tables. data model value
   serialized to JSON string.

   Ege: "type", "number", etc.

   McCool: This is a bit ambiguous.

   McCool is looking at TD spec. contentType has Type string.

   McCool: contentType value is string.

   <kaz> [10]https://w3c.github.io/wot-thing-description/

     [10] https://w3c.github.io/wot-thing-description/

   Dave: JSON names are strings as well.

   McCool: assertion needs to re-worded.
   ... should probably be "vocabulary terms that identify values
   that use simple types..."
   ... this rule may be included in more general rules.
   ... values associated with vucabulary terms MUST have the given
   type...
   ... same same applies to td-integer-type etc. as well.
   ... We agree that we can validate with JSON-Schema, right?

   Ege: Yes.

   McCool: td-context. if you have it, it MUST be of the value
   "http://www.w3.org/ns/td".
   ... assertion should be revised that way.
   ... the value can be an array, and one of the value MUST be
   that.
   ... assuming this is what is meant, it can be checked with JSON
   schema.
   ... we should prototype 4 or 5 of this kind of tests.

   Dave: What does this have to do with implementation report?

   McCool: we check each implementation against each test.
   ... each implementation shows pass/fail/no-impl.
   ... generator collects all of them.

   <kaz> kaz: we should be clear that schema itself is not part of
   the TD spec

   <kaz> McCool: right

   McCool: I did my part on test merger.
   ... We can show ambiguities etc to TD meeting.

   Ege: I will do my part.

   McCool: 3 or 4 cases will be enough before the meeting.
   ... We meet again next week.

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [11]scribe.perl version 1.154 ([12]CVS log)
    $Date: 2018/12/02 08:22:16 $

     [11] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [12] http://dev.w3.org/cvsweb/2002/scribe/
Received on Sunday, 2 December 2018 08:24:23 UTC

This archive was generated by hypermail 2.3.1 : Sunday, 2 December 2018 08:24:23 UTC