- From: Drummond Reed <drummond.reed@evernym.com>
- Date: Sun, 18 Jul 2021 14:14:13 -0700
- To: Mike Prorock <mprorock@mesur.io>
- Cc: Manu Sporny <msporny@digitalbazaar.com>, W3C DID Working Group <public-did-wg@w3.org>
- Message-ID: <CAAjunnZM_cMmtYSp-tLWmY1C_e5_oSfUm3vPeAnbXkLTxNUcWg@mail.gmail.com>
Evernym is also a +1 to this "allow new features" option for all the reasons Manu states. I personally believe this is going to become the new normal now that the W3C has formally recognized this option. =Drummond On Sun, Jul 18, 2021 at 10:43 AM Mike Prorock <mprorock@mesur.io> wrote: > Good summary, thanks. > > +1 to "allow new features" from mesur.io as well in case I am not able to > be on the call > > Michael Prorock > CTO, Founder > mesur.io > > On Sun, Jul 18, 2021, 13:40 Manu Sporny <msporny@digitalbazaar.com> wrote: > >> 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 21:14:38 UTC