- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 18 Jul 2021 13:39:36 -0400
- To: W3C DID Working Group <public-did-wg@w3.org>
On 7/18/21 8:53 AM, Mike Prorock wrote: > Manu, there is some good flexibility from item 2: "allow features to be > added to it after Recommendation." Are there any concerns from your end > related to this, process wise, or otherwise, that may cause issues down the > road with adoption of that clause? Yes, that's the gambit (unintended consequences), this is new in W3C Process 2020 (and is thus new to everyone). It's not really that risky of a position to take, IMHO. Part of it comes from an attempt to avoid something like this happening again (which was a rolling decade-long disaster that continues to this day): https://en.wikipedia.org/wiki/HTML5#W3C_and_WHATWG_conflict ... but more importantly, I think we're specifically doing it to help the spec track reality in the market. Case in point is the Verifiable Credentials Data Model specification... while we have a Maintenance group for it, we can only fix bugs, not add new features (we need a recharter for that)... and that's causing the spec to show it's age in places. Nothing really bad, but it would be nice to have the option of adding say "title" and "description" to VCs, for example. :) If we had flipped the "allow new features" bit on the VC spec (we couldn't have done that, btw, Process 2020 wasn't ratified by the time we went to REC)... then we wouldn't be in the position we are in with the VC spec. So, we're learning from our mistakes and trying to take a new option that would allow us to add features that the community deems useful. The downside here is that there may be new REC versions of the specification within a year or so after first REC, so some large enterprises/governments might not like not having the spec stability of 5+ years that they're used to. To be fair, they can always implement against a single REC and choose to not upgrade to the latest (and that's valid). That said, the world has sort of moved on from the age of stable software to an age of Continuous Integration and Continuous Deployment... we expect to get rolling upgrades these days for software. This is the standards version of that. In any case, it's all new to me (and most everyone else in standards)... and the benefits far outweigh the downsides IMHO. I'm a +1 to flip the "allow new features" bit. You can read more about that process here: https://www.w3.org/2020/Process-20200915/#allow-new-features https://www.w3.org/2020/Process-20200915/#revised-rec-features ... and kudos to Brent for catching this; I was clueless that we had to explicitly state this in the spec -- I just thought it automatically became an option if we followed Process 2020. -- manu -- Manu Sporny - https://www.linkedin.com/in/manusporny/ Founder/CEO - Digital Bazaar, Inc. News: Digital Bazaar Announces New Case Studies (2021) https://www.digitalbazaar.com/
Received on Sunday, 18 July 2021 17:39:54 UTC