Meeting minutes
minutes
<kaz> Sep-7
Lagally: review minutes from 7 Sept
… hearing no objections, will publish
agenda
<kaz> agenda for today
Lagally: will review schedule, contributions, publication blockers, testing incl. testfest
schedule
Lagally: look at scope previously, next is testfest
<kaz> Sept 5-9: Determine Profile 1.0 Scope
<kaz> Sept 12-16: Decide Profile 1.0 Scope
<kaz> Sept 26-30 Plugfest / Testfest for Profile 1.0
<kaz> Oct 3-7 Incorporate Plugfest/Testfest results, prepare CR draft
<kaz> 2 - weeks review
<kaz> CR transition End Oct
Lagally: reasonably stable spec except for async actions
… need to understand if we can get two interoperable implementations
Sebastian: important to see what outcome of testfest
… out of the box interoperability needs to be really demonstrated
… it is a big requirement
… we have to be sure this statement is proven by plugfest results
Lagally: agree, if we cannot validate it then we should not publish it
… should not publish if we are not confident
Lagally: ben is not on the call but did have an implementation
… and I have an implementation
… would be good to discuss in post-TPAC
McCool: added 20m to call on Thursday to discuss testing
Lagally: ok; so plan is to target a CR transition end of Oct
Ege: for me not clear whether this is a plugfest or a testfest
Lagally: don't see a reason to split
McCool: rather than getting hung up on the name, we should define scope precisely
… in particular, conformance of implementation with spec, and pair-wise interoperability
… can put in a README.md for the event, can discuss tomorrow
Kaz: basically agree with McCool, but please note that W3C testing is not for conformance, but of specifications
Kaz: we need to get well-prepared beforehand, and the testfest event itself should be looking at implementation checklist
Lagally: will take action item to create a draft readme
McCool: can certainly help with tooling
Ege: agree with mccool, you proposed producer/consumer, two producers same consumer
… want to show it "just works", good to have multiple producers
… want to avoid one implementer doing both sides
Lagally: ok, don't have time today to go into details, let me take the action to create a README to discuss tomorrow
contributions
Lagally: quite a lot of PRs on the table
PR 266
<kaz> PR 266 - WIP - Refine sync vs. async action protocol binding - closes #259
Daniel: PR #266, is marked as draft because we need to decide how to align TD and Profiles esp on sync actions
… we need to make up our mind here
Lagally: I see Ben has joined
… suggest we defer the discussion about sync/async actions to plugfest
… more generally, what is the plan for PRs?
Ben: PR #266 could be merged, except for examples
McCool: I would support merging
Lagally: I would rather keep the PR so we can see the diff
… and have more time to review
Daniel: don't want to go into details, sync actions are more aligned with TD spec, but async is new; this PR makes it cleaner
Ben: agree this makes it match the defaults in the TD spec; even if a TD does not match the profile, can still use async actions
Lagally: ok, let's put on the agenda for the next call, let's review
McCool: suggest we move onto some easy PRs and clear the deck a little bit
Kaz: also feel we should defer, need to see actual need
Lagally: oracle has support async actions for years and feel they are necessary for scalability
PR 271
<kaz> Pr 271 - WIP: Common constraints - identifiers
Lagally: common constraints, needs work, mark as WIP
PR 273
<kaz> PR 273 - make hreflang optional - closes #245
Lagally: make hreflang optional
… small change, any objections? reverts to TD standard, where it is also optional
Daniel: if aligned with TD spec, do we have to mention anything?
Lagally: self-contained is good, but later we can revise
PR 274
<kaz> PR 274 - editorial alignment - consistent use of "WoT Profile Specification" - closes #244
Lagally: consistent use of "WoT Profile Specification"
McCool: do think we should be careful about saying profiles, plural
Lagally: can we merge?
… merged
PR 278
<kaz> PR 278 - Refine Profile definition - closes #243
Lagally: refine profile definition
… is about terminology
… any concerns?
… (none) merging
PR 279
<kaz> PR 279 - fix: typos
Lagally: fixes typos, from dape, purely editorial
… any objections to merging?
… (none) merging
PR 281
<kaz> PR 281 - Regenerate Assertions - Sept 13
Lagally: regenerate assertions in assertions.csv, ran script
… any objections to merging?
… (none) merging
Ege: TD has github action that does this automatically
McCool: fine with this, just avoid clobbering template.csv, used by report generator
Lagally: ok, would be useful to have the github action
… merges
PR 282
<kaz> PR 282 - Update README.md to reflect WoT Profile Specification name and contents
Lagally: updates readme, remove discussion of "core profile"
Lagally: any objections?
… (none) merged
PR 264
<kaz> PR 264 - Add geolocation semantic annotation recommendation - closes #137
Ben: should we delete?
McCool: this is useful, but I think it should be in a mini-profile
Sebastian: geolocation is very complicated, would be against this
Lagally: let's leave the PR open and comment on it
Kaz: maybe add a label "discuss in PR"
PR 265
<kaz> PR 265 - Rename HTTP Baseline Profile to HTTP Basic Profile
Lagally: about consistent renaming of baseline to basic
… diagrams are outdated
Ben: don't have source to diagrams, so this changes text to be consistent
Lagally: unfortunately are merge conflicts
McCool: so, we can agree to merge after conflicts resolved
Lagally: makes note on PR allowing merge
issue
<kaz> Issues with "close" label
Lagally: have been using labels to mark issues that I think can be closed
… please review, need to clean up
… going to close unless I hear any objections
Lagally: there are also a list of eight publication blockers
… but some are for profile 1.1, feel we can remove those
Profile 1.0 open issues
Lagally: see label "Profile-1.0", 24 open issues
… some will be closed, but many others need owners
… some can be done by anyone, eg. generating new images, overview sections
… there is also a link in the agenda; 13 issues in this category that don't have owners
testing
Lagally: ege, you brought this up earlier
… there is already a lot of input from multiple implementations
… and I'm hoping we can reuse a lot of existing implementations for alignment with profiles
… hardest way would be to go through them manually
McCool: suggest that a single JSON schema might be useful to identify TDs that completely satisfy the profile
… then we can focus manual checking on TDs that fail the schema
… also a JSON Schema would be useful in the spec
Ege: we do have a schema for the whole TD spec, also have small schemas for each assertions
… unfortunately can't dedicate resources to this for profiles, but should be relatively straightforward
Lagally: is there anyone else who can help?
Ege: unfortunately fady is also busy these days
… it is also not a one-time job, needs to be updated
Sebastian: end of business year, overwhelmed with various tasks
McCool: any possibility to hire a student?
McCool: maybe we just do this during the testfest
Ben: very few of the assertions in the profile can be tested with JSON schema
… majority are behavioral
Lagally: so manual verification is required anyway
Ben: ideally we should have an automated test suite
Kaz: dependency among specifications, felt we failed to look at that; not a failure of tooling, but failure to look at dependencies
… really want to understand which assertions go into which specifications
… but let's talk next
<kaz> [adjourned]