W3C home > Mailing lists > Public > public-wot-wg@w3.org > August 2020

[TD-TF] minutes - 29 July 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Sat, 08 Aug 2020 16:04:34 +0900
Message-ID: <87zh751uv1.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:
  https://www.w3.org/2020/07/29-wot-td-minutes.html

also as text below.

Thanks a lot for taking the minutes, Daniel!

Kazuyuki

---
   [1]W3C

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

                               - DRAFT -

                             WoT-WG - TD-TF

29 Jul 2020

   [2]Agenda

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#July_29.2C_2020

Attendees

   Present
          Kaz_Ashimura, Cristiano_Aguzzi, Daniel_Peintner,
          Michael_McCool, Sebastian_Kaebisch, Taki_Kamiya,
          Ege_Korkan, Tomoaki_Mizushima

   Regrets

   Chair
          Sebastian

   Scribe
          McCool

Contents

     * [3]Topics
         1. [4]Review minutes for July 15 and July 22
         2. [5]Vacation time and meeting schedule
         3. [6]Release dates
         4. [7]Issue
            https://github.com/w3c/wot-thing-description/issues/93
            2
         5. [8]Issue updates from wot
         6. [9]Issue
            https://github.com/w3c/wot-thing-description/issues/93
            4
         7. [10]Modbus binding
     * [11]Summary of Action Items
     * [12]Summary of Resolutions
     __________________________________________________________

   <kaz> scribenick: McCool

Review minutes for July 15 and July 22

   [13]https://www.w3.org/2020/07/15-wot-td-minutes.html

     [13] https://www.w3.org/2020/07/15-wot-td-minutes.html

   [14]https://www.w3.org/2020/07/22-wot-td-minutes.html

     [14] https://www.w3.org/2020/07/22-wot-td-minutes.html

   no objections to publish July 15 minutes

   no objections to publish July 22 minutes

Vacation time and meeting schedule

   sebastian not available 19/8, 26/8, and 3/9

   Sebastian: will Taki be available?

   Taki: yes, I will be available

   Sebastian: it would be ok to have a break, too

   Taki: in that case, let's cancel the 19th and maybe the 26th

   Sebastian: definitely cancel 19; taki can decide and announce
   in the main call
   ... based on open issues

   McCool: I will also record cancellations in main wiki page

   [15]https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellatio
   ns

     [15] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Cancellations

Release dates

   for TD1.1
   [16]https://github.com/w3c/wot-thing-description/labels/FPWD%20
   1.1

     [16] https://github.com/w3c/wot-thing-description/labels/FPWD 1.1

   json schema issue has been fixed -
   [17]https://github.com/w3c/wot-thing-description/pull/896

     [17] https://github.com/w3c/wot-thing-description/pull/896

   <Ege> brb in 2 mins

   Sebastian: have asked Daniel to fix render script
   ... to generate based on ontology files

   McCool: other PRs also need to know how render works, eg in the
   ontology file or in the template

   Sebastian: we also want the rendered diagrams based on the
   ontology

   Cristiano: we also talked about contentType, etc.
   ... where will these changes go?

   Sebastian: actually I forgot where this was supposed to go; I
   will update the issue and deal with this as well in the PR

   <sebastian>
   [18]https://github.com/w3c/wot-thing-description/issues/912

     [18] https://github.com/w3c/wot-thing-description/issues/912

   look at oauth2 pr

   [19]https://github.com/w3c/wot-thing-description/pull/927

     [19] https://github.com/w3c/wot-thing-description/pull/927

   issue with using an ontology (formal vocab) for flow names

   <trackbot> Sorry, but no Tracker is associated with this
   channel.

   would want to do this in a backward compatible way, and allow
   external vocab to define extensions

   eg it needs to be an open enumeration, not closed

   Sebastian: let's discuss under the PR

   next, issue 937

   [20]https://github.com/w3c/wot-thing-description/pull/937

     [20] https://github.com/w3c/wot-thing-description/pull/937

   seems there is an issue in the context files

   Sebastian: some redundancy
   ... in particular, an @id under security seems wrong

   McCool: certainly I may have made an error here

   Sebastian: ok, I will check it
   ... also moving TDT to main section
   [21]https://github.com/w3c/wot-thing-description/pull/938
   ... these are all the PRs that would go into TD 1.1

     [21] https://github.com/w3c/wot-thing-description/pull/938

   McCool: so this is just a move, not a redefinition?
   ... I do think we should loosen the definition a little
   ... for example, it should not be mandatory that security is
   omitted
   ... maybe we should allow URI templates in forms, etc

Issue [22]https://github.com/w3c/wot-thing-description/issues/932

     [22] https://github.com/w3c/wot-thing-description/issues/932

   how to version scripting API separately from TD versioning

   Cristiano: also TD and scripting versions are coupled at
   present
   ... need to know which version of TD a version of the scripting
   API works with
   ... how do we deal with "semantic" versioning when we also have
   "dated" URIs for context files?

   Sebastian: kaz, do you have any experience with how this is
   handled?

   Kaz: we can look into JS and HTML
   ... but the assumption there is that everything is backward
   compatible

   Daniel: example is XML schema, version 1.1 still uses the same
   namespace
   ... so looking at the namespace can't be used to determine the
   version

   McCool: I personally would like to see a scheme like .../v1
   referring to latest v1, v1/0 and v1/1 referring to specific
   versions
   ... unfortunately the date in the URL messes that scheme up

   Sebastian: we should ask the JSON-LD group about this topic

   <kaz> <script type="application/javascript;version=x.x">

   Kaz: if needed we can use something like the HTML version tag,
   e.g. using extended context, or adding specific tag

   McCool: assume we are focusing on TD versioning for now

   Kaz: good JSON-LD joint meeting topic

   Sebastian: agree

   McCool: we should reach out to them and schedule that

Issue updates from wot

   Sebastian: thanks ege for moving issues over from the old wot
   repo
   ... there are some interesting ones

   [23]https://github.com/w3c/wot-thing-description/issues/936
   using links for UIs, IDE

     [23] https://github.com/w3c/wot-thing-description/issues/936

   Sebastian: also relates to Schema, but we have also introduced
   title and descriptiong
   ... but an open question is how to provide icons, etc.
   ... cannot be solved by linking, since links are only at top
   level, not at the interaction level
   ... maybe it can be dealt with using semantic annotations

   Sebastian: please share ideas on issue

   Ege: I also think semantic annotations would be the easiest way
   to do this

   <Ege> [24]https://schema.org/logo

     [24] https://schema.org/logo

   McCool: I think for "generic" icons associating it with a
   semantic tag might be feasible, but for branded icons it is
   tricker
   ... logo thing seems more like an extension than an annotation
   ... if it's a common extension, maybe it should be in the main
   spec
   ... in HTML it makes sense as an annotation since you can
   annotate an existing image tag with microdata

   issue
   [25]https://github.com/w3c/wot-thing-description/issues/935

     [25] https://github.com/w3c/wot-thing-description/issues/935

   McCool: class field to be able to modify several properties at
   once

   Sebastian: we may also be handling this in different ways now

   McCool: I think this is more of a scripting API issue if it is
   about manipulating multiple Things at once
   ... eg the result of a query on a particular annotation

   <dape> [26]https://github.com/w3c/wot-scripting-api/issues/204

     [26] https://github.com/w3c/wot-scripting-api/issues/204

   Daniel: this does not seem like it should be in the core spec
   of scripting though

   McCool: I agree, it can be implemented using other features we
   are already working on, in particular semantic annotations and
   directories queries that return a set of results
   ... but we might have to consider some tweaks to make it
   possible to submit queries to directories without revealing the
   URL of directories (for privacy reasons, eg. to avoid
   fingerprinting...)

Issue [27]https://github.com/w3c/wot-thing-description/issues/934

     [27] https://github.com/w3c/wot-thing-description/issues/934

   <inserted> [28]related issue on wot repo

     [28] https://github.com/w3c/wot/issues/281

   Sebastian: my reading is that this example is addressed with
   our current spec
   ... except for global definitions of types
   ... example uses SSE defined in a "protocol" field
   ... for example; but this specific case we have subprotocols
   now

   <sebastian>
   [29]https://github.com/w3c/wot-thing-description/issues/307

     [29] https://github.com/w3c/wot-thing-description/issues/307

   Sebastian: then there is the use of $ref etc for definitions
   ... there are points on our roadmap that will address the
   compound values

   <inserted>
   [30]https://github.com/w3c/wot-thing-description/issues/934

     [30] https://github.com/w3c/wot-thing-description/issues/934

   Daniel: but not sure about streams; there is another open issue
   on streams I believe

   Sebastian: let's keep it open, and discuss

Modbus binding

   Ege: looked into in detail

   <sebastian>
   [31]https://github.com/w3c/wot-binding-templates/pull/98

     [31] https://github.com/w3c/wot-binding-templates/pull/98

   Ege: is missing concept of default modbus binding
   ... e.g. is read property reading a bit a word?
   ... also, do vocabulary files need an "editor" at the top?
   ... respec gives me a warning if there is no editor

   Cristiano: also the examples still need to be updated; the
   uppercase values need to be camel-case

   Sebastian: would check that the terms use correspond to normal
   modbus terms

   Cristiano: may also have to update node-wot implementations,
   may not have used the exact same terms

   Kaz: I thought there are two resources here, (1)
   machine-readable vocabulary definition and (2) human-readable
   document describes that. If we want to publish the
   human-readable document as a W3C Note, then we DO need an
   editor
   ... applies to human-readable documents

   Cristiano: about length and byte length, for node-wot, length
   is defined in content type

   McCool: I am also wondering about extensions to data schema for
   bit length

   Ege: better to distinguish data schema from protocol
   information

   Cristiano: problem is that if returns something like json, then
   it is redundant to have the length
   ... but if the content type is an octet stream, we should
   include the length in the content type

   Sebastian: seems like it needs more deliberation; have taken
   notes in the issue
   ... we will watch for his replies
   ... author only worked loosely with Ege

   Kaz: maybe this is overkill, but do we want to worry about
   "livestreams" where the end is not known?
   ... possibly related to media discussion

   Cristiano: not applicable to MODBUS
   ... might apply to other protocols however, e.g. media

   McCool: assume in the case of livestream we could use a content
   type without a length
   ... ends when socket is closed

   Sebastian: ok, done, move to adjourn

   <kaz> [adjourned]

Summary of Action Items

Summary of Resolutions

   [End of minutes]
     __________________________________________________________


    Minutes manually created (not a transcript), formatted by
    David Booth's [32]scribe.perl version ([33]CVS log)
    $Date: 2020/07/31 10:37:51 $

     [32] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [33] http://dev.w3.org/cvsweb/2002/scribe/
Received on Saturday, 8 August 2020 07:04:39 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 8 August 2020 07:04:40 UTC