Meeting minutes
Minutes Review
McCool: It's been a while due to all of the charter discussions. Let's read the minutes carefully
… some typos, but I am not too worried of them
… (marks a comment by Kaz) Is that actually reflecting what you said?
Kaz: I updated the comment offline
McCool: We should have a look on the "Propose Closing" issues today
… (updated the Agenda)
… minutes look okay, only a few typos, but let's publish the minutes as they are
… any objections?
No objections, minutes are published
Issues
Issues and PRs marked as "Propose Closing"
<kaz> Issues with "Propose Closing" label
McCool: We have a lot of open issues, some of which are labelled Propose Closing
… I would simply close them in bulk, if someone disagrees, they can reopen them
Farshid: I think we should rather go through them one by one
… for example, the issue about the diff parameter could be postponed
… however, I added the label myself, so it can probably be closed
McCool: I would simply close them, they could be reopened if needed
… will do it offline
PR 462
<kaz> PR 462 - CR Update - DID and DNS-SD fixes
McCool: This PR has not been merged yet, but we got feedback by PLH
… still some work to do regarding URLs
… and updates to changelog
… port discussion in the PR was resolved
… comment by Manu Sporny needs to be addressed. Will create an issue for deciding on the URL and some additional points that need to be clarified, but will merge it as is
… does anyone feel the need to edit this PR before it is merged?
… this resolves the DNS-SD stuff and makes progress regarding DID
… in any case, I can merge it and apply additional fixes afterwards
… I am not hearing anyone's opinion, so I will first create the issue
… (creates an issue regarding outstanding DID fixes)
McCool: So, we do not need to refer to the DID ontology in my opinion. We should follow up on this discussion and go ahead with the PR for now.
<kaz> wot-discovery issue 467 (transferred from the wot repo)
McCool: (moves the issue from the wot repository, where it was accidentally created, to the wot-discovery repository)
… changes are to the top-level index.html file, so we need to update the CR candidate at some point
… (merges the PR)
<McCool_> w3c/
Other issues
McCool: Regarding the outstanding issues, we should go through them and figure out whether they need to be resolved by PR or deferred
<FarshidT> Issue 234 - JSONPath as a search query language
<FarshidT> Issue 129 - Review IETF JSON Path draft
McCool: we probably have about 60 issues still open
Farshid: The JSON path issues marked as "Propose Closing" should be kept open
McCool: Oh, yes, that was a mistake
… or we can only leave one open
… we should have a look at the latest IETF draft for JSON Path, maybe we can use it, but we should leave it open when it comes to the new charter
McCool: We can close Issue 129 and will continue the discussion in Issue 234
… and remove the Consolidation label from that issue
… we should probably go through the issues and see which ones can be marked as deferred or Resolve by PR
Issue 466
<kaz> Issue 466 - Removing the RFC 9175 assertion?
McCool: Is about the multicast DDoS CoAP assertion, that will probably go away anyway since it is marked as "At Risk"
Issue 465
<kaz> Issue 465 - TDD Thing Model is missing contentType in response objects
Jan: Thing Model API description has the problem of not defining a contentType for all response objects in forms
… leading to invalid TDs if instantiated as is
… proposed a workaround, also raised the issue in TD repository
McCool: Could be fixed by an informative statement or the workaround Jan proposed
… needs a longterm fix, probably in the TD spec
Issue 464
<kaz> Issue 464 - How to keep Thing Descriptions updated in a Directory
McCool: Issue raised by Ben Francis
Farshid: Can be marked as a question
… asks why there is no standard way of keeping Thing Descriptions updated
McCool: (Adds a comment that this would be good to be clarified)
Issue 463
<kaz> Issue 463 - Align Context URLs with TD specification
McCool: Is related to 464
… (adds a comment)
Issue 458
<kaz> Issue 458 - WG 2023 Charter - Update
McCool: I think we should close this issue and move it to the charter discussion
… will mark it as "Propose Closing" and close it in the next round of things
Issue 448
<kaz> Issue 448 - Assertion for DNS referencing UDP may be split normative/informative
McCool: We may have already fixed this issue
… I think the PR I just merged has fixed this
… can leave the "Resolve by PR" label and leave it as is for now
Issue 445
<kaz> Issue 445 - Implementation Report Fixes
McCool: I think this is also "Resolve by PR", just cleans up the Implementation Report
Issue 416
<kaz> Issue 416 - clean up logilab results
McCool: This is related to testing, I will label this issue and similar ones as such
… (applies the label to other issues as well)
… (also applies the label "Resolve by PR" to Issues 414 and 415)
Issue 413
<kaz> Issue 413 - Improve wording of tdd-absolute-time assertion
McCool: The description is a bit unclear, not sure what I wanted to do here
… was probably more of an English thing or an editorial problem
Issue 410
<kaz> Issue 410 - Use TDD consistently
McCool: I think this one was also editorial
… not sure if it is resolved yet
… I think resolving by PR would be good, but it is not critical
Issue 333
<kaz> Issue 333 - [repository] No link to the spec from the repository
McCool: This is a weird one
… which we should fix right now
… (sets the link to the rendered version of the specification as the repository's "homepage")
… (adds a comment and closes the issue)
… are you okay with closing?
Kaz: I agree with closing, and this is a question for the whole working group, of how to deal with the rendered HTML document
McCool: Okay, I am going to close it
Issue closed
Issue 283
McCool: This one is labelled "Resolve by CR", will mark it as "Resolve by PR" and add the testing label
Issue 327
McCool: Is this still an issue we need to worry about, Farshid?
Farshid: There were some use cases that were not included in the explainer
McCool: I am more concerned about incorrect than missing correct statements
Farshid: I don't think there are any incorrect statements, but I will have another look. We don't need to add a label for the issue
Issue 257
Issue 257 - What part of a TD can a TDD modify
McCool: This one is marked as "Resolve by CR"
… I don't think we have any assertions about that
… and I think that was our conclusion regarding this issue
… and Ege agrees in an issue comment
… I would propose deferring it, as we cannot add assertions at the moment
… (adds a comment to the issue)
… I think signing will impact this
… once we support it
… (removes existing labels and adds "defer to Discovery 2.0")
Issue 239
McCool: This one is just cleanup, so I will mark it as such
… (adds the "Cleanup" label)
Issue 224
McCool: This one does not have an appropriate label
Farshid: I agree with Ben, the consumer can add the default, does not need to be done by the directory
… could be added as part of the SPARQL DB (?)
Andrea: As an implementor, this @type is mainly necessary for the framing
Andrea: if the @type is missing, then we inject it, and store the fact that it has been injected privately
… should be open to the implementors how to handle this
… don't need to change the specification
McCool: We need to clear about this in the next specification version, since it may affect signing
Kaz: Maybe we can organize a W3C developer meetup to gather feedback before the next charter period
… we need to identify what needs to be added separately
McCool: We are out of time, we will continue next time, until then, please scan through the issues
[adjourned]