W3C home > Mailing lists > Public > public-wot-wg@w3.org > January 2021

[TD-TF] minutes - 13 January 2021

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Wed, 27 Jan 2021 18:44:48 +0900
Message-ID: <87blda1zov.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.

Thanks a lot for taking the minutes, Cristiano!



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

                             WoT-WG - TD-TF

13 January 2021

   [2]Agenda. [3]IRC log.

      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Thing_Description_WebConf#Jan_13.2C_2021
      [3] https://www.w3.org/2021/01/13-wot-td-irc


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





    1. [4]Preliminaries
    2. [5]previous minutes
    3. [6]Defer issue to TD 2.0
    4. [7]Pull requests
    5. [8]issues

Meeting minutes


   Sebastian: happy new year to everybody.
   … today we'll focus mainly on the topics from GitHub issues
   … anything else to be added to the agenda?
   … ok

  previous minutes

   <kaz> [9]Dec-16 minutes

      [9] https://www.w3.org/2020/12/16-wot-td-minutes.html

   Sebastian: we had some discussion on IETF ASDF meeting
   … in particular how SDF can be transformed to an Thing Model

   McCool: I expect to have a SPARQL directory for the next
   PlugFest, we can experiment there with SDF

   Sebastian: I have also a student who's working on this topic

   McCool: about Plugfest please if you have any other topic that
   you want to be covered please feel free to ping me.

   Sebastian: we postponed TD "produced" field for the next
   version. it needs more discussion

   Sebastian: another issue was about having multiple methods
   names. You have defined a default mapping to transform a single
   form with multiple ops

   <kaz> [10]Issue 712 - Multiple methodName's

     [10] https://github.com/w3c/wot-thing-description/issues/712

   McCool: one problem is that it is odd to have one method name
   and multiple ops
   … we probably need an assertion to avoid this situation.

   Daniel: I disagree it is possible to have a PUT method to both
   read and write

   McCool: how do you distinguish between the operations?
   … it is ambiguous
   … we may use SHOULD instead of MUST

   Sebastian: what about the assertion made in issue comment?
   about the transformation?

   McCool: I agree with that

   Sebastian: next topic was about 617 and we'll probably continue

   McCool: yes it is relevant for discovery, in particular for
   multiple error responses
   … I think is a good feature but we have to think about retro

   Sebastian: minutes approved

  Defer issue to TD 2.0

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

     [11] https://github.com/w3c/wot-thing-description/issues?q=is:issue+is:open+label:"Defer+to+TD+2.0"

   McCool: I think there might be a set of issue like the one
   about multiple responses that need to be deferred because of
   their impact in retro compatibility

   Sebastian: the list linked in not complete, please ping me to
   add more

   Sebastian: I also made a label to tag old issues or issues that
   could be closed

   McCool: the geolocation issue is still open, please remove the

   Sebastian: ok I removed the label

   McCool: my concern about geolocation is that we need a
   definitive structure to do geo based searches in directories
   … probably we might need a separate document with best
   practices or guidelines for geolocation with WoT

  Pull requests

   <kaz> [12]PR1027

     [12] https://github.com/w3c/wot-thing-description/pull/1027

   Sebastian: the first one is from kaz. The main change is the
   modification of the spec status
   … plus he remove the image width

   Kaz: yes it is an obsolete feature.

   Sebastian: plus there are some automatically generated files

   Sebastian: it seems fine to me. Any other comments?

   Kaz: I mentioned during the architecture call as well: we
   should have a naming convention for IDs for sections, figures
   and examples

   McCool: I wouldn't change it now.

   <kaz> kaz: in any case, if there are duplicated IDs, I'll fix
   them before publication.

   Sebastian: ok merged
   … then there are two wip PRs

   <kaz> [13]PR1025

     [13] https://github.com/w3c/wot-thing-description/pull/1025

   <kaz> s/wip PRS/wip PRS, PR1025 and PR1024/

   Sebastian: daniel found some capitalization errors about the
   observeall operation

   Sebastian: it might be an error of the render script

   Sebastian: then there's a PR about the Thing Model chapter

   Sebastian: we have some agreement for introducing a version for
   the model. it can be also used in a TD instance
   … also we have a small consensus about how to link the model in
   TD using the link field.
   … I add SDF to TM example

   Cristiano: is the version field optional?

   Sebastian: yes it is optional

   <kaz> [14]PR1021

     [14] https://github.com/w3c/wot-thing-description/pull/1021

   Sebastian: next PR is about issue 1010

   Sebastian: is it from daniel and it introduces the
   exclusiveMaxium and exclusiveMinimun terms
   … does SDF have this terms?

   Koster: no, I don't think so, but let me check
   … oh we have it then.
   … sometime you need it. Is it not a problem to include it

   McCool: certainly consistency with JSONSchema is good

   Sebastian: ok then the PR looks good so far.
   … ok there's is some conflicts. It is probably related to the
   kaz PR merge.

   Daniel: since it is a generated image that is in conflict we
   could ignore it and merge it anyway. It will be overwritten

   Sebastian: ok merged

   <kaz> [15]PR964

     [15] https://github.com/w3c/wot-thing-description/pull/964

   <kaz> [16]PR924

     [16] https://github.com/w3c/wot-thing-description/pull/924

   Daniel: can we remove the Bump PRs? they are old
   … no big deal

   Kaz: I think I need to look into the settings

   Sebastian: I'll propose to test those and see if the render
   script will work correctly.

   Sebastian: there's another old PR from mc

   McCool: unfortunately this PR was broken by the update of the
   render script. I'll work on it
   … probably I'll create a new one

   <kaz> [17]PR945

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

   Sebastian: what about 945?

   McCool: it breaks compatibility so it is deferred.


   <kaz> [18]Issue 617

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

   Sebastian: the first one is multiple responses in a form
   … one problem there is again backward compatibility.

   McCool: one workaround is to add a new term (i.e., responses)

   Sebastian: yeah it is like title and titles

   Ege: I like responses, but I am afraid for typos if we have
   response togheter with responses. we could remove response in
   future versions

   McCool: is response mandatory

   Ege: yes

   McCool: it might still not 100% retrocompatible
   … old system wouldn't understand
   … responses

   Sebastian: I like the proposal. but can we say that respose be
   a single value or an array

   McCool: is not backward compatible

   Sebastian: we might do an exception here
   … I also like responses tough

   Daniel: I tend to agree to keep response as it is and add a new
   term for other responses

   <McCool> to clarify, I was propose adding an
   "additionalResponses" field for "other" responses

   Cristiano: what about dataschema?

   Sebastian: it reminds me the discussion we had with
   … we talked about other fields to describe multiple payloads

   McCool: JSONschema allows multiple choices.

   Koster: but we cannot map to a particular response
   … in SDF we'll use a json pointer to indicate the data schema

   McCool: how do we distinguish different responses? with http we
   have different codes. we could use dataschema even to define
   different responses
   … the challenge is how to use headers to distinguish between

   Koster: json pointers are useful when referring other pieces of
   information inside a json document.

   McCool: it could be really simple if relative to the schema

   Koster: let's look at some example and try it

   McCool: because we have a concrete use-case in the discovery
   let's start from there

   Sebastian: so to conclude: one step is decide if to include a
   new terms form multiple responses. last how to point
   dataschemas from responses
   … json pointers is on the table as one possibile solution for
   the second point.

   <mjk_> We prefer "anyOf" rather than "oneOf" for reasons

   McCool: dealing with errors is a gap that we have in TD, we
   should work to fix this missing feature.

   <mjk> [19]https://github.com/ietf-wg-asdf/SDF/pull/8

     [19] https://github.com/ietf-wg-asdf/SDF/pull/8

   <mjk> discussion of use of "anyOf"

   Sebastian: mc can you take responsibility for this issue?

   McCool: yes I'll bring this up in the Discovery task force and
   then Farshid or I will provide a PR

   <kaz> [20]Issue 923

     [20] https://github.com/w3c/wot-thing-description/issues/923

   Sebastian: next issue is about a security scheme for Philips
   light bulbs.

   McCool: yes we reviewed in security task fource. basically keys
   are embedded in URIs and we cannot describe it

   McCool: I proposed a new scheme, much like the one that ege is
   suggesting in the issue tracker
   … it is still a open problem but we have to introduce this new
   mechanism to handle URI templates
   … I don't have a PR yet. I'll try to create one before Monday
   … if anyone has more examples of URI embedded security
   parameter please comment in the issue
   … I'll also improve the API key documentation

   Ege: why don't use this pattern inside the API key?

   McCool: yes we'll do
   … we'll have a new "in" value (i.e., URItemplate)

   Sebastian: maybe ege you could join the security call and
   discuss about the new proposal

   <kaz> [21]Issue 307

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

   Sebastian: next issue 307
   … it is an old issue and it's about introducing $ref pointers
   inside the TD
   … the major usecase is to minimize redundancy
   … also you can change one definition in one place
   … Legally mentioned about the recursive problems

   Ege: jsonschema avoid it by disallow recursive refs
   … also we have to pay attention about how to include
   definitions or other schemas

   Koster: we had this in SDF, but we dropped it. It is too narrow
   because $ref should point always to a schema
   … like ege mentioned it is not clear if you can put a URI
   there. Therefore we coined a new pointer
   … we have to be careful to use $ref for this limitations. In TD
   it is best to introduce a new term

   Sebastian: should we also avoid the $ref to point to other json

   Koster: because $ref means precisely use the schema at this

   <kaz> [22]sdfRef

     [22] https://ietf-wg-asdf.github.io/SDF/sdf.html#sdfref

   McCool: I think this is a 2.0 feature.

   Koster: true

   Sebastian: agree

   McCool: we could pre process a TD with this new feature and
   convert it back

   Daniel: what about JSON-LD? is this new feature working with
   … victor had some points about the issue

   Koster: probably in json-ld you'll use a fragment identifier

   McCool: I don't know, it looks different in json-ld

   Koster: Is an URI with a fragment in RDF.

   Ege: one point of pre processing. we could introduce this
   feature in TD model instead of TDs

   McCool: right and in 2.0 we could introduce it in TDs

   McCool: is there a frame for generating a TD back from RDF?

   Koster: great idea to use in TM

   <kaz> [23]issue 1015

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

   Sebastian: about framing, McCool, could you provide a PR?

   McCool: I think there's an issue somewhere

   <McCool> (have to drop, sorry)

   Kaz: we might want to talk with DID group about the framing
   … JSON-LD group suggested this also.

   <kaz> [adjourned]

    Minutes manually created (not a transcript), formatted by
    [24]scribe.perl version 127 (Wed Dec 30 17:39:58 2020 UTC).

     [24] https://w3c.github.io/scribe2/scribedoc.html
Received on Wednesday, 27 January 2021 09:44:54 UTC

This archive was generated by hypermail 2.4.0 : Wednesday, 27 January 2021 09:44:54 UTC