- From: Kazuyuki Ashimura <ashimura@w3.org>
- Date: Mon, 11 Jan 2021 16:21:16 +0900
- To: public-wot-wg@w3.org
available at:
https://www.w3.org/2020/11/26-wot-arch-minutes.html
also as text below.
Thanks,
Kazuyuki
---
[1]W3C
[1] http://www.w3.org/
WoT Architecture
26 Nov 2020
[2]Agenda
[2] https://www.w3.org/WoT/IG/wiki/WG_WoT_Architecture_WebConf#Agenda
Attendees
Present
Kaz_Ashimura, Michael_Lagally, Michael_McCool,
Tomoaki_Mizushima, Sebastian_Kaebisch
Regrets
Chair
Lagally
Scribe
kaz
Contents
* [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]Nov-19
[16] https://www.w3.org/2020/11/19-wot-arch-minutes.html
Lagally: let's approve the minutes
all: ok
(approved)
FPWD
[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]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
vocabulary
... 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
wiki)
[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
repo
... 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
security/accessibility
... probably we should add a separate section for horizontal
requirements
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
section)
[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]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]diff
[29] https://pr-preview.s3.amazonaws.com/w3c/wot-architecture/567/6ddd5ef...680c108.html
Lagally: would suggest we merge this
McCool: concur
Kaz: +1
(merged)
PR 528
[30]PR 528
[30] https://github.com/w3c/wot-architecture/pull/528
[31]changes
[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
review"
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
(merged)
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
Profile
[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
interaction
... 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
readability
... RFC8785 already defines some canonicalization
[40]RFC8785
[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)
AOB
[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?
(none)
[adjourned]
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