<scribe> scribenick: kaz
Lagally: let's approve the minutes
all: ok
(approved)
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?
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
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)
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
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
Lagally: created a Pullrequest for that purpose
5. Requirements within the WoT Use Cases Note
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)
McCool: there should be DB entries at the top of the HTML code
Lagally: (creates a GitHub issue for fixing the reference section)
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)
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
Lagally: Mizushima-san, could you see that?
Mizushima: ok, will do
Lagally: removing the requirements section from the WoT Architecture document
Lagally: would suggest we merge this
McCool: concur
Kaz: +1
(merged)
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)
(and then merged)
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
McCool: what about wot-usecases?
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
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
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)
Lagally: (shows McCool's comment gave 7 days ago)
[[
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
McCool: right
... we should be compatible with that
... as the starting point
Lagally: need any updates to PR 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)
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]