Closed msporny closed 2 months ago
selfissued
commented
2 months ago @msporny, since you agree with the changes in #1 #2 and #3, let's merge them now. Then it will be more obvious what this PR does, at which point I'll review it. Right now, it's all jumbled together here. Thanks.
msporny
commented
2 months ago @msporny, since you agree with the changes in #1 #2 and #3, let's merge them now.
To be clear, I don't agree with everything in them, but they're not problematic enough to object to them before an FPWD. I'll raise individual concerns in each PR, but that doesn't have to wait for FPWD publication (since consensus isn't required on all content to publish FPWD).
Then it will be more obvious what this PR does, at which point I'll review it. Right now, it's all jumbled together here. Thanks.
WG process is to allow 7 days for people to vet each PR before it appears in the mainline specification. I can't merge any of those to main w/o violating WG process.
In any case, it doesn't matter for the FPWD, since they're merged in the static FPWD copy (they are in there). Once we publish the FPWD, we can merge this PR, and all of it will go in at that point in time (which will be after the 7 day merge window)... but as I said, there are some minor problems with #1, #2, and #3 that probably should be dealt with in those PRs.
selfissued
commented
2 months ago WG process is to allow 7 days for people to vet each PR before it appears in the mainline specification. I can't merge any of those to main w/o violating WG process.
I understand, but arguably, these are all editorial, since they're applying changes that were already in the VC-JOSE-COSE or VC-DATA-INTEGRITY versions of the Controller document text. Let's talk about this on the editors' call tomorrow.
In any case, it doesn't matter for the FPWD, since they're merged in the static FPWD copy (they are in there).
Yes, I believe you, but it still doesn't give us a clean diff that shows what changes are unique to this PR and which came from mine. That's what I'm asking for, in order to efficiently review this PR. Thanks.
msporny
commented
2 months ago it still doesn't give us a clean diff that shows what changes are unique to this PR and which came from mine. That's what I'm asking for, in order to efficiently review this PR.
You can shift-click a range of commits in a PR to just view the changes that are on top of yours. To do this:
Here's the URL that does that for this PR (it filters out your PRs and just shows the ones I had to put on top of yours to fix the spec so the FPWD won't throw publication errors):
iherman
commented
2 months ago I wonder whether the publication of this FPWD should not be accompanied by PR's that remove the corresponding sections from the JOSE-COSE and the DI documents. This would make it much clearer to the reviewers what is happening here and would avoid discussions about the necessity of the new document.
msporny
commented
2 months ago I wonder whether the publication of this FPWD should not be accompanied by PR's that remove the corresponding sections from the JOSE-COSE and the DI documents. This would make it much clearer to the reviewers what is happening here and would avoid discussions about the necessity of the new document.
Strong -1 to that approach UNTIL vc-controller-document reaches Candidate Recommendation. Removing the controller document sections from the JOSE-COSE and DI specs is major surgery. We will need to continue to align everything in vc-controller-document, and we might hit a point at which there will be formal objections to move it to the Candidate Recommendation stage. If that happens, then we'll have to scramble to put the sections back into each document.
We are introducing a critical dependency at quite an unfortunate time (right at the end). We shouldn't tie all of these things together until we're sure they're all going to make it. At present, I give vc-controller-document a 33% chance of failure... while it's not a big chance, it is still a gamble at this point in time. The details will matter, and that's where we might see formal objections.
brentzundel
commented
2 months ago The starting point of this document needs to include all of the Controller Document features from both securing specs in order to comply with the resolution made by the group here: https://www.w3.org/2017/vc/WG/Meetings/Minutes/2023-10-25-vcwg#resolution1
In order to accomplish that, this is the path I see before us:
I believe that doing these things is necessary to meet the WG's consensus decision to create a Controller Document Spec.
Once we have the Controller Document in that state, anyone who would like to see changes in the contents of the document should raise issues and our normal VCWG work mode will be in full effect, i.e., all issues will need to be addressed and PRs for resolving PRs will need our standard review period, etc.
brentzundel
commented
2 months ago @msporny I resolved conflicts in this PR in 1c1440f Please let me know if I screwed things up and I will revert that commit.
brentzundel
commented
2 months ago @selfissued per my comment here, please raise issues for your concerns so they can be properly tracked once we're past FPWD.
This PR should be merged as soon as @msporny confirms that it still contains his changes after my attempt to resolve conflicts.
msporny
commented
2 months ago Merging per Chair request to address WG consensus to get to FPWD in https://github.com/w3c/vc-controller-document/pull/11#issuecomment-2097032690.
This PR readies the FPWD publication of the Controller Documents v1.0 specification (which is effectively a generalized and updated form of the DID Document format). It contains PRs #1, #2, and #3 authored by @selfissued. It does not contain PR #4, which removes all of the authors of the DID Core specification, upon which this document is based. It also contains a number of changes that were needed to fix up all of the broken links and references in the specification.
A static version of the document can be found here:
https://w3c.github.io/vc-controller-document/FPWD/2024-FPWD/