Summary

  • W3C Strategy issue 566 calls the LWS work an existing-group recharter with no substantive changes, sets 15 October 2026 as the expected end of refinement and records a new hope: Candidate Recommendation in Q4 2026 or Q1 2027, then maintenance.
  • The active charter had projected CR in March 2026, Proposed Recommendation in June and Recommendation on 8 September. W3C's publication page still lists the LWS documents as Working Drafts; that is a maturity observation, not a technical-failure verdict.
  • The proposed charter frozen at commit f00f3b8 still contains a Choose one maturity paragraph, five [Q1–4 YYYY] dates, a dummy Web [spec name] deliverable, a FooML/BarML timeline and unresolved operating instructions.
  • The refinement deadline had not passed. The checked file may change, and the public record does not reveal every decision made outside it. The evidence supports a document-readiness question, not a process-breach allegation.
  • Before Advisory Committee review, W3C should publish a commit-bound readiness receipt naming each deliverable's terminal maturity, dated milestone, maintenance owner and the disposition of every remaining template token.

One label covers two different kinds of continuity

W3C Strategy issue 566 opened on 4 August for an existing Linked Web Storage Working Group recharter. It gives 15 October as the expected end of charter refinement. Under “Substantive changes”, it says None.

That statement can be true about technical scope. The mission remains a protocol that separates applications, identity and storage providers so users can choose services without surrendering the whole data relationship. The proposed charter retains five named normative specifications: four authentication suites and Linked Web Storage Protocol 1.0.

But the issue immediately identifies a different discontinuity. The initial charter, it says, was “aggressively optimistic”. The group now hopes to get to Candidate Recommendation in Q4 2026 or Q1 2027 and then switch to maintenance. It adds that this still needs to be clarified in the charter text, which is currently the output of the charter assistant.

The distinction matters. No substantive changes answers whether the intended subject and deliverable family are being recast. It does not answer whether the successor document has finished choosing its dates, maturity endpoint or post-CR authority. Scope continuity is not the same claim as charter readiness.

The active charter gives the comparison a baseline

The active charter runs from 9 September 2024 through 8 September 2026. Its schedule projected the core protocol's first Working Draft in March 2025, Candidate Recommendation on 10 March 2026, Proposed Recommendation on 9 June and Recommendation on the charter's final day. Advancement to Proposed Recommendation was expected to require at least two independent interoperable implementations of every feature, verified through open tests.

The current LWS publications page still places Linked Web Storage Protocol 1.0 and its related authentication documents under Working Drafts. The core protocol surface is likewise a Working Draft; the successor proposal records 28 July 2026 as its latest publication.

Those facts show that the original timetable and current public maturity state are no longer aligned. They do not show why, whether implementation work is healthy, or whether CR will be reached in the new window. Missing an optimistic schedule is not proof that a specification failed. The only safe conclusion is that a successor charter needs a new, explicit maturity account.

The charter-history surface also keeps the two instruments distinct. The active charter is a dated authority document. The proposed charter is a candidate being refined. Neither should be read through the other by implication.

The maturity exit remains literally selectable

The public repository began with an assistant-derived commit on 3 August. A second commit on 5 August removed LDP Next from the coordination section. That small subject-specific edit shows the file was not merely abandoned at generation. It does not tell us which other choices were settled outside the public text.

The evidentiary anchor is the immutable file at the second commit, not the mutable rendered draft. In that file, start and end dates are still bracketed instructions. The 0.1 FTE staff allocation is styled as a TODO. Teleconferences may be “topic-specific calls” or “something else”. The communication clause still tells the editor to pick the mailing list, GitHub issues or both.

The central ambiguity sits in the deliverables introduction. The file says Choose one and then presents two possible meanings for expected completion: projected Recommendation or another stable state; and a separate sentence saying the group intends Candidate Recommendation Snapshots and does not intend to advance its documents to Recommendation.

All five named normative deliverables then carry the same placeholder: [Q1–4 YYYY]. A tentative-deliverables section contains Web [spec name] with a concrete-description placeholder. The timeline asks for FooML and BarML milestones. The success criteria tell an editor to remove the interoperable-implementation clause if the group will not move to Recommendation, while another instruction says to consider adding implementer-interest language if it will not.

No single token proves a hidden policy disagreement. Together they prove that the frozen public file had not yet converted the issue's CR-then-maintenance intention into one complete operating instrument.

An open refinement window is not a breach

The W3C Process gives charter refinement a lifecycle. Before the stated end, the Team must initiate Advisory Committee review, abandon the proposal or extend refinement. Charters identify their mission, scope, deliverables, expected milestones where available, meeting and communication mechanisms and other operating terms. A major or new charter then goes to Advisory Committee review. Adoption is a W3C Decision, followed by a Call for Participation if approved.

At the evidence cutoff, 15 October was still ahead. The proposed text was allowed to be unfinished. The public evidence does not show that the 5 August commit will be the review draft, that an internal decision has not already been taken, or that visible TODO styling always means substantive uncertainty.

That boundary protects both sides of the analysis. It prevents a draft from being mistaken for adopted authority. It also prevents ordinary drafting work from being reported as misconduct.

A charter-readiness receipt for this exact recharter

Before review, the candidate commit should carry a compact public receipt. The first row would pin the immutable file and the 15 October refinement state. The next would give start and end dates, or the public rule that determines them.

The centre of the receipt would be a five-row deliverable table. Each row would name the current Working Draft, its chosen terminal maturity under the successor charter, a target quarter or a named no-estimate reason, and the success criterion that applies. If Candidate Recommendation followed by maintenance is the chosen endpoint, the table should say whether Snapshots continue, what changes maintenance permits and which actor owns later publication decisions.

A document-state register would then dispose of the remaining tokens: the dummy tentative deliverable, generic timeline, FTE styling, meeting alternative and work-channel instruction. Resolved in commit, intentionally retained, not applicable and deferred with owner are all legitimate states. Silence is not.

Finally, a change note should explain that technical scope may be unchanged while schedule, maturity endpoint and operating mechanics differ from the active charter. That prevents no substantive changes from doing work it was never precise enough to do.

The receipt would not force LWS to become a Recommendation. It would not let outside observers choose W3C's process. It would simply make the reviewed proposition reproducible.

Sources