- From: Dan Brickley <danbri@google.com>
- Date: Tue, 27 Apr 2021 13:40:32 +0100
- To: "Eric Prud'hommeaux" <eric@w3.org>
- Cc: Gregg Kellogg <gregg@greggkellogg.net>, Manu Sporny <msporny@digitalbazaar.com>, W3C JSON-LD Working Group <public-json-ld-wg@w3.org>
- Message-ID: <CAK-qy=5Hefo2fWqf5i7nQQOu=PNoAjL9cTUwjSrJozhNVL144w@mail.gmail.com>
Thanks all. I think there's something positive that could be done here, is this something you could raise internally with your W3C team colleagues? On Eric's proposal - would this change the process i.e. https://www.w3.org/2020/Process-20200915/#rec-rescind or just the UI on w3.org? I am assuming the latter. We could say 1.0 is superseded by 1.1, while being more tolerant in the UI of the idea that people might want to refer authoritatively (and without upselling to superseding vresions) to the earlier stable standards they've implemented against. Goonlessly, Dan On Tue, 27 Apr 2021 at 13:04, Eric Prud'hommeaux <eric@w3.org> wrote: > The HL7 FHIR specifications, e.g. > http://hl7.org/fhir/2021May/ > include link to a directory: > <a href="http://hl7.org/fhir/directory.html">Directory of published > versions</a> > > The linked page is pretty populated because it includes all drafts. We > tend to navigate to previous version links when we care about drafts so > we'd have only a couple rows. > > PROPOSAL: ask W3M to include a list of published RECs directly in the > front matter replacing the current message about being a relic of bygone > technology. This comm problem isn't limited to JSON-LD. > > I believe this optimizes both the message that this is a published > standard and that there are other versions when you're ready to switch to > them. > > There are a couple practical variants on this: > > 1. full list of all RECs visible on each REC. Everything behind the > current version would be redundant against the <Previous versions> link. > Maybe the biggest list would be XML which has five editions. > > 2. list of all later RECs visible on each REC. Only XML first edition > would have links to all four future editions. > > Another parameter to play with is rather to apply it retroactively or just > to future docs (and json-ld 1.0, so danbri doesn't send his google goons > after me). > > > > On Mon, Apr 26, 2021 at 04:07:42PM -0700, Gregg Kellogg wrote: > > I’m certainly fine with tweaking the statements on the 1.0 specs, if we > can. I believe the thought was that, as the 1.1 specs include everything > from 1.0, that they were current, but that shouldn’t imply that the 1.0 > specs are inappropriate to cite. > > > > Gregg Kellogg > > > > Sent from my iPad > > > > > On Apr 26, 2021, at 11:58 AM, Manu Sporny <msporny@digitalbazaar.com> > wrote: > > > > > > On 4/26/21 2:40 PM, Dan Brickley wrote: > > >> My main concern here is with the ability to document Schema.org by > saying > > >> "For use in search engines, Schema.org can be written in JSON-LD 1.0" > and > > >> having something reliable to point to. Maybe sometime it'll be > possible to > > >> say that about 1.1 too. Should we be looking at requesting the > superseded > > >> status to be restored, or could the popup warning shown on rescinded > > >> specifications be made less pushy and upselly? > > > > > > For what it's worth, I agree with Dan and share his concerns regarding > > > messaging to his community of interest. > > > > > > Perhaps a sticky footer, placed at the bottom of the page, in > green/orange, > > > that says: "There is a newer version of this specification. For the > latest > > > version please look at: ..."? > > > > > > -- manu > > > > > > -- > > > Manu Sporny - https://www.linkedin.com/in/manusporny/ > > > Founder/CEO - Digital Bazaar, Inc. > > > blog: Veres One Decentralized Identifier Blockchain Launches > > > https://tinyurl.com/veres-one-launches > > > > > > > > > > >
Received on Tuesday, 27 April 2021 12:46:55 UTC