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

[wot-architecture] minutes - 26 November 2020

From: Kazuyuki Ashimura <ashimura@w3.org>
Date: Mon, 11 Jan 2021 16:21:16 +0900
Message-ID: <87h7nondlf.wl-ashimura@w3.org>
To: public-wot-wg@w3.org
available at:

also as text below.




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

                            WoT Architecture

26 Nov 2020


      [2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda


          Kaz_Ashimura, Michael_Lagally, Michael_McCool,
          Tomoaki_Mizushima, Sebastian_Kaebisch





     * [3]Topics
         1. [4]Prev minutes
         2. [5]FPWD
         3. [6]Architecture TF page
         4. [7]Transferring the requirements section to the Use
            Cases TF
         5. [8]Issue 565 and PR 567
         6. [9]PR 528
         7. [10]PR 562
         8. [11]Use Cases PRs
         9. [12]Profile
        10. [13]AOB
     * [14]Summary of Action Items
     * [15]Summary of Resolutions

   <scribe> scribenick: kaz

Prev minutes


     [16] https://www.w3.org/2020/11/19-wot-arch-minutes.html

   Lagally: let's approve the minutes

   all: ok



   [17]wot-architecture11 FPWD

     [17] https://www.w3.org/TR/2020/WD-wot-architecture11-20201124/

   Lagally: FPWD of WoT Architecture Ver 1.1 has been published

   McCool: we should think about publication schedule update

   Lagally: how did we mention our plan on the Charter?


     [18] https://www.w3.org/2020/01/wot-wg-charter.html#profiles

   McCool: generally, changes which wouldn't break the
   compatibility should be the target for this Charter period

   Kaz: we used "Update" vs "Next" instead of "1.1" vs "2.0"
   within the Charter

   McCool: right
   ... the current TD spec allows the usage of additional
   ... would like to see the updated schedule tool

   [19]milestone calculator

     [19] https://w3c.github.io/spec-releases/milestones/

   McCool: we should start with the CR transition given the FPWD
   is published

   Lagally: (tries it)
   ... maybe around July 1 for CR?
   ... and REC in the end of Sep

   McCool: we should think about the possible feedback from the
   wide reviews like privacy
   ... what about CR early July?

   Lagally: (tries that)

   McCool: could you put the resulted dates on the main wiki?

   Lagally: (updates the publication schedule on the WoT Main

   [20]Publication schedule

     [20] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Deliverable_and_F2F_Meeting_Plan

   McCool: we could remove 2.0 portions

   Lagally: July 1 for CR
   ... September 1 for PR
   ... November 1 for REC

   McCool: the point here is that we concentrate on the "Updates"

   Lagally: ok
   ... we can revisit the update plan

   McCool: regarding the Use Cases Note, we should be able to
   publish a stable version in Feb 2021 as planned

   Lagally: might be even earlier

   [21]updated publication schedule

     [21] https://www.w3.org/WoT/IG/wiki/Main_WoT_WebConf#Deliverable_and_F2F_Meeting_Plan

Architecture TF page

   McCool: we should create a Pullrequest for the wot-marketing
   ... you can go ahead and generate one for wot-architecture
   ... and myself can work on wot-security, etc.
   ... we can talk about the template of the pages during the
   marketing calls
   ... if you want, I can grab the architecture wiki content and
   create a Pullrequest for you

   Lagally: great

Transferring the requirements section to the Use Cases TF

   Lagally: created a Pullrequest for that purpose

   [22]5. Requirements within the WoT Use Cases Note

     [22] https://w3c.github.io/wot-usecases/#sec-requirements

   McCool: we should add privacy/i18n in addition to
   ... probably we should add a separate section for horizontal

   Kaz: not within the use cases section but within (or
   additional) requirements section. right?

   McCool: yes, maybe we could add an intermediate section
   ... can look into that

   Lagally: ok
   ... note that we should look into the reference section as well

   Kaz: do you mean picking up the latest/updated links?

   Lagally: no, simply fix the format

   McCool: note that ReSpec should handle the format
   ... so we should update the ReSpec DB too

   Lagally: what about adding hyperlinks first
   ... and then think about how to deal with them using ReSpec
   ... (looks into the HTML source of the reference section)

   [23]Appendix B: References

     [23] https://w3c.github.io/wot-usecases/#a-references

   McCool: there should be DB entries at the top of the HTML code

   Lagally: (creates a GitHub issue for fixing the reference

   [24]ReSpec Documentation

     [24] https://respec.org/docs/

   Lagally: ReSpec handles the references

   Mizushima: are there any example descriptions?

   Lagally: you can look into wot-thing-description/index.html,
   wot-architecture/index.html and wot-profile/index.html
   ... (shows the example of wot-profile/index.html)


     [25] https://github.com/w3c/wot-profile/blob/master/index.html

   Lagally: the reference entries are automatically generated
   based on the reference links within the specification text

   McCool: we need to look into the ReSpec DB entries as well for
   possible additions

   [26]Specref site

     [26] https://www.specref.org/

   Lagally: Mizushima-san, could you see that?

   Mizushima: ok, will do

Issue 565 and PR 567

   [27]Issue 565

     [27] https://github.com/w3c/wot-architecture/issues/565

   [28]PR 567

     [28] https://github.com/w3c/wot-architecture/pull/567

   Lagally: removing the requirements section from the WoT
   Architecture document


     [29] https://pr-preview.s3.amazonaws.com/w3c/wot-architecture/567/6ddd5ef...680c108.html

   Lagally: would suggest we merge this

   McCool: concur

   Kaz: +1


PR 528

   [30]PR 528

     [30] https://github.com/w3c/wot-architecture/pull/528


     [31] https://github.com/w3c/wot-architecture/pull/528/files

   Lagally: connected building requirements
   ... (goes through the changes)

   McCool: maybe we can add an Editor's note saying "still need

   Kaz: this change should be also transferred to the wot-usecases
   repo. right?

   Lagally: right
   ... would suggest we once merge this within the
   wot-architecture repo
   ... and then transfer the content to wot-usecases

   Kaz: ok

   Lagally: (adds a note to PR 528)

   [32]Lagally's comment

     [32] https://github.com/w3c/wot-architecture/pull/528#issuecomment-734385902

   (and then merged)

PR 562

   [33]PR 562

     [33] https://github.com/w3c/wot-architecture/pull/562

   Lagally: add candidates for UI link types

   McCool: would have several iteration about this
   ... so would suggest we merge this PR itself

   Lagally: ok

   Kaz: +1


   Lagally: now no open PRs for wot-architecture

Use Cases PRs

   McCool: what about wot-usecases?

   [34]wot-usecases PRs

     [34] https://github.com/w3c/wot-usecases/pulls

   Lagally: 3 open PRs
   ... but let's talk about them during the Use Cases call

   McCool: ok
   ... can look into PR 51 on ITU-T summary

   Lagally: let's discuss it during the next Use Cases call

   McCool: ok


   [35]wot-profile issues

     [35] https://github.com/w3c/wot-profile/issues

   [36]Issue 55

     [36] https://github.com/w3c/wot-profile/issues/55

   Lagally: let's assume we don't have any signing at the moment

   McCool: ok
   ... technical discussion on how to deal with canonicalization
   would make sense
   ... we could put it into TD
   ... Profile also needs canonicalization, though

   Lagally: there is a PR on canonicalization

   [37]PR 51

     [37] https://github.com/w3c/wot-profile/pull/51

   McCool: it's a starting point but not complete yet
   ... thinking about array and the order of the values

   Kaz: maybe looking into the mapping between TD and SDF might be
   useful here as well

   McCool: note SDF doesn't handle URLs

   Lagally: ideally the canonicalized representation should be
   identical for the same class of TDs

   McCool: right

   (Sebastian leaves)

   McCool: maybe we need some additional wrapper information to TD
   ... about which part to be added by directory

   Lagally: kind of like phonebook to get the address

   Kaz: which includes semantic search as well possibly

   Lagally: may include encrypted TDs

   <inserted> mm: possibly could return part of the TDs

   Kaz: so it would relate to the TD fragments discussion

   McCool: right

   Lagally: (going back to Issue 55)

   [38]Issue 55

     [38] https://github.com/w3c/wot-profile/issues/55

   Lagally: (shows McCool's comment gave 7 days ago)

   [39]McCool's comments

     [39] https://github.com/w3c/wot-profile/issues/55#issuecomment-730501826


   Other TD canonicalization topics discussed:

   Default values. Do we omit properties that are assigned their
   default values? These could have been filled in when a TD is
   imported into a directory, for example.

   Prefixes. This is a JSON-LD issue. If a URL is defined for a
   prefix, and a database expands them internally, we need to
   convert BACK to prefixes when serializing... IF the original
   document used them. We may have to add a rule that TDs must
   ALWAYS use prefixes and not URIs for vocab terms? I suspect
   this is the main thing we should coordinate with the JSON-LD
   group, but we should ask them about other known issues.

   Array ordering. There some places in TDs where arrays are used
   but the order does not matter, eg form, op, etc. We need to add
   an assertion that TD processing must not change the order of
   any arrays, even if there is no semantic change. Note that JCS
   says that order of arrays is not changed.

   Array-of-one-element: see above. We should check for any other
   equivalent-ways-to-express the same thing and the canonical
   form should insist on one.


   McCool: note that now we have the combo scheme

   Lagally: if you have some self-contain content...
   ... what would be expected?
   ... possibly a couple of different protocols there

   McCool: first is discovery
   ... currently we're thinking about HTTP
   ... another possibility is CoAP over TCP/IP
   ... possibly multiple protocols in one form
   ... there is a use case for that

   Lagally: right
   ... on the other hand, we want to keep our profile simple
   ... we need some balance here

   McCool: depends on machine-to-machine interaction or human
   ... if we identify specifying the order would be useful, the
   most important one should be listed first
   ... would be not essential but should be safer
   ... the use case in my mind is mainly regarding the directory

   Lagally: note that the canonicalization should keep human
   ... RFC8785 already defines some canonicalization


     [40] https://tools.ietf.org/html/rfc8785

   McCool: right
   ... we should be compatible with that
   ... as the starting point

   Lagally: need any updates to PR 51?

   [41]PR 51

     [41] https://github.com/w3c/wot-profile/pull/51

   McCool: can work on that
   ... do you want me to work on that?

   Lagally: would merge PR 51 itself
   ... and then ask you to give updates

   (merged as the starting point)


   [42]wot-architecture issue 569

     [42] https://github.com/w3c/wot-architecture/issues/569

   Kaz: we talked about some possible boilerplate text for W3C
   specs in general at the beginning of today's call
   ... please let me record that here
   ... will check with the W3Mers

   <scribe> ACTION: kaz to talk with PLH, Ralph and Wendy about
   the possible boilerplate text on diversity, etc.

   McCool: would follow the W3C policy

   Lagally: anything else for today?



Summary of Action Items

   [NEW] ACTION: kaz to talk with PLH, Ralph and Wendy about the
   possible boilerplate text on diversity, etc.

Summary of Resolutions

   [End of minutes]

    Minutes manually created (not a transcript), formatted by
    David Booth's [43]scribe.perl version ([44]CVS log)
    $Date: 2020/12/17 14:37:16 $

     [43] http://dev.w3.org/cvsweb/~checkout~/2002/scribe/scribedoc.htm
     [44] http://dev.w3.org/cvsweb/2002/scribe/
Received on Monday, 11 January 2021 07:21:21 UTC

This archive was generated by hypermail 2.4.0 : Monday, 11 January 2021 07:21:21 UTC