Ready a First Public Working Draft for the DID specification

[msporny]

This PR readies a FPWD for the DID specification by

• Changing the render template to FPWD.
• Adding all current issues to an appendix in the spec.
• Updating the Status of the Document language to warn implementers not to implement and point to all issues and PRs in the appendix that may result in changes to the specification.

It does not yet (but will before FPWD):

• Update the shortname of the specification.
• Update to the latest list of issues and PRs.
• Update the links to the latest shortname in Github.
• Create a static copy of the FPWD document.

---

Preview | Diff

[peacekeeper]

Looks good. One bug that needs to be fixed is #82 (comment). I'd link to understand what the ideal Git steps to do that would be. Fix it first in the "master" branch, then rebase and force-push this "fpwd" branch?

[iherman]

The W3C Pubrules' checker results include two errors:

1. This date found on a boilerplate section of the document does not have the expected format (DD Month YYYY, with an optional leading zero in the day): “16-1-00”.

2. The homepage https://www.w3.org/2019/did-wg/ should appear in the “status of this document”

To be honest, I do not see what the first error message refers to; if we do not find it we can refer to the Webmaster. The second error is probably handled by adding the following to the respec header:

wg: "Decentralized Identifier Working Group",
wgURI: "https://www.w3.org/2019/did-wg/"

which would then do (hopefully) the right thing.

[iherman]

The W3C Link checker's results do includes four errors.

• Two out of those are the fact that https://www.w3.org/TR/did-spec does not yet exist, ie, those are transient problems.
• You may want to look at why https://evernym.com/ is forbidden for a robot, but that may be intentional (the site does work from a browser). If it is intentional, the webmaster will accept it, we should just know (and tell him).
• As for the fourth (forbidden access to common.js) it may again be a transient problem with the way the tool tries to access AWS. We just have to be careful to include common.js into the final push to the W3C Web Site (that will be my responsibility) and list that dependency when we get to echidna.

I.e., we are probably fine with that one.

[iherman]

Submitting a FPWD amounts to raising an issue at a specific repository, see:

FPWD request

All the items in that are obvious, and I will take care of those when the time comes, except for one:

# Information about implementations known to the Working Group
[TODO: add any preliminary information that you might have]

This is not a required field, just informational, but if there is a reference to a list of implementations from the CG days, that could be helpful.

[iherman]

The second error is probably handled by adding the following to the respec header:

wg: "Decentralized Identifier Working Group"
wgURI: "https://www.w3.org/2019/did-wg/"

which would then do (hopefully) the right thing.

While making some other admin changes I have added those in #89. And yes, respec does the right thing:-)

[msporny]

You may want to look at why https://evernym.com/ is forbidden for a robot, but that may be intentional (the site does work from a browser). If it is intentional, the webmaster will accept it, we should just know (and tell him).

Fixed in 31d7713. Changed the link to add www, that you can hit directly from a browser

As for the fourth (forbidden access to common.js) it may again be a transient problem with the way the tool tries to access AWS. We just have to be careful to include common.js into the final push to the W3C Web Site (that will be my responsibility) and list that dependency when we get to echidna.
I.e., we are probably fine with that one.

Fixed in 0bc3c7c -- common.js is just extra stuff ReSpec needs to do its work. It won't be in the static version of the doc.

Also, pulled and rebased on top of latest version in master just to this PR is tracking the latest editorial changes.

[msporny]

This is not a required field, just informational, but if there is a reference to a list of implementations from the CG days, that could be helpful.

Fixed in c8d13f9 . Linked to use cases, implementations, and test suite.

[iherman]

This issue was discussed in a meeting.

• RESOLVED: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.

View the transcript

FPWD (Issue #68)
Daniel Burnett: #68
Ivan Herman: See PR #87 for the FPWD text
Manu Sporny: See also Current FPWD proposal
Daniel Burnett: In this issue, we’re discussing publishing an official “working draft” .. We currently have an “editor’s draft”
… Working draft does not imply group consensus.
… Publishing the first working draft (FPWG) is important since it starts some IPR processes
… To do this, we won’t have an official “vote”, but try to get consensus from the group
… The editors put together a document that would become the FPWD (asides from minor editorial fixes)
… We received one comment with concerns about the document, by selfissued (Mike Jones), do you want to speak about it?
Michael Jones: I raised a concern because since our last call I read the charter. The charter says we will create a Use Cases document with req’s for the technical specification.
… It’s important to have the Use Cases first that explain why we’re doing what we doing
… At TPAC I heard a reference about the Use Cases document, but no time has been spent on the WG to go over UC issues.
… UC document should not be an afterthought. It should inform the technical specification.
… Otherwise we may be condoning neglect of use cases.
Daniel Burnett: “Neglect” may be too strong, but you are right that UC are important and that we haven’t spent time on it yet.
… It’s reasonable to expect that we spend more time on UC upfront before focusing only on the main spec
… The group does need to begin to work on it.
… Topic today is, can we agree to publish FPWD of the core spec.
… We should consider FPWD of UC doc as well.
Michael Jones: See issue #8 in the UC repository
Manu Sporny: I agree UC document is important. I think so far the WG had higher priority items to address.
… Some time has been spent on UC. The current version reflects that, see the reference from the SOTD It’s one of the better UC documents out there compared to other groups.
… I don’t think it should be a gating factor. It’s easy to link from core spec to UC document, so readers are aware of it. This is fine for FPWD to point to documents that are in-process.
… I think people won’t get confused if FPWD of core spec points to in-progress UC document.
… Let’s not gate FPWD by this.
Michael Jones: I disagree with manu’s assertion that UC document is relatively mature.
Manu Sporny: I said “mature for a FPWD”
Michael Jones: I’m reading this with fresh eyes.
… There is a lot of tribal knowledge that is assumed. New readers of the UC document may be confused by not knowing certain things.
… Therefore I raised several issues about things that are not clear to new readers.
… Can we get a gentlemen’s agreement to get to FPWD also for the UC document?
Ivan Herman: I’m also a new reader without the tribal knowledge. I still think we should publish FPWD of the core spec, but FPWD of UC should also be prepared soon (e.g. by end of November)
Brent Zundel: +1 to publishing use cases during November
Daniel Burnett: What I’m hearing is Mike would be okay with publishing FPWD of core spec, if the group has a gentlemen’s agreement to publish FPWD within November and work toward that.
Michael Jones: Agreed
Daniel Burnett: Does anyone object to the intent of the group being publishing FPWD of UC document within November, and working toward that goal (working on Github issues, allocating time on WG calls for this)?
Dudley Collinson: +1 and also happy to participate in use case review
Manu Sporny: I’m trying to formulate a single proposal that addresses both FPWD of core spec and selfissued ‘s requests about UC document.
Ivan Herman: I would prefer three separate, crisp proposals, rather than having everything in a single proposal/resolution.
… We can have them now and vote for them, that’s easier from an admin perspective
Ivan Herman: +1
Daniel Burnett: We already agreed to work on UC document, and we already on Echidna.
… So we should only have to vote on publishing the DID core spec as FPWD
Proposed resolution: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November. (Manu Sporny)
Ivan Herman: +1
David Trang: +1
Ted Thibodeau Jr: +1
Brent Zundel: +1
Manu Sporny: +1
Adrian Gropper: +1
Dudley Collinson: +1
Daniel Burnett: +1
Kyle Den Hartog: +1
Yue Jing (景越): +1
Daniel Burnett: Any suggestions to modify the proposal? Not hearing any. Please respond.
Markus Sabadello: +1
Michael Jones: +1 to trigger the IPR process
Daniel Burnett: Seeing no objections. This is resolved.
Resolution #1: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.
Daniel Burnett: Is there anyone who believes that we must do one of the other two proposals today?
Manu Sporny: We’ll merge and create a static copy for FPWD
Ivan Herman: Formally speaking, we have to wait 1 week before a resolution is accepted.
… I’m aiming for publishing this on Thursday 7th of November.
Daniel Burnett: If there are objections, we encourage people to raise them within 48 hours.
Ivan Herman: As soon as I have the static version, I will start the admin process.
Manu Sporny: Will try to create the static copy today.

[msporny]

@iherman per your request, added reference to DID-USE-CASES in b116c21.

[msporny]

RESOLVED: Publish the DID Core specification as a FPWD with a short name of did-core within the month of November.

Multiple positive reviews, suggested changes addressed, WG approval for FPWD publication, merging.