Add links to all W3C LWS WG drafts to /TR

[elf-pavlik]

https://w3c.github.io/lws-protocol/

Search terms you've used

LWS

What problem are you trying to solve? Please describe.

Improve communication about existing Solid CG Reports and LWS WG draft TRs

What existing documentation is relevant to your problem, and why is it insufficient?

https://solidproject.org/TR

It doesn't inform readers about work that advanced to W3C REC track in LWS WG

Eventually we should also add something polised from
https://github.com/jeswr/lws-solid-diff

[csarven]

Abstract

Hi! We’re the Solid Community Group (CG) of the W3C. The purpose of this document is to help readers orient themselves with the activities of the Solid CG.

The CG has a charter.

The Solid CG’s technical reports (TR) include specifications, use cases and requirements, best practices and guidelines, primers and notes about the Solid ecosystem.

I'm glad we had this conversation.

[elf-pavlik]

I agree that the text also need to be updated to reflect more recent organization of drafting reports (CG) and TRs (WG), where work happens across Solid CG and LWS WG.

[csarven]

So, first of all, treating LWS as if it were the natural successor to fold into /TR/'s scope doesn't hold up given LWS is largely incompatible with Solid. The charter finalised on the name "LWS" based on W3C community feedback. That was a deliberate signal to set it apart from Solid, which actually undercuts the case for folding it back in here.

And as per AWWW, URI ownership grants solidproject.org exclusive right to decide what /TR/ identifies, and that's what governs here. /TR/ is defined as Solid CG's work, and there is already a social expectation that the Solid CG talks about its own work items. AWWW describes URI persistence as "the desirable property that, once associated with a resource, a URI should continue indefinitely to refer to that resource".

So treating /TR/'s scope as open to broadening is both inappropriate and breaks that property.

[uvdsl]

From the perspective of a Solid CG member, I am concerned that

• this might look like trying to establish a Web standard outside of W3C
• publishing rights between maintainers of solidproject.org and the W3C LWS WG might become an issue
• LWS drafts without adoption/extension/modification in the context of the Solid Protocol do not necessarily help achieve the vision of the Solid Project

From the perspective of an LWS WG member, I am concerned that

• hosting LWS specification drafts at a different venue than obviously controlled by W3C, the WG or the editors (like the current github pages) might reduce credebility
• association of the LWS Protocol with the Solid Project might provide unnecessary heritage baggage to the ultimately resulting W3C REC. People might start and continue to view the LWS Protocol as a re-brand of this rather explorative project, thereby undermining the proper standing that the LWS Protocol (probably) will have

[elf-pavlik]

hosting LWS specification drafts at a different venue than obviously controlled by W3C, the WG or the editors (like the current github pages) might reduce credebility

I'm not talking about hosting just listing to the existing drafts

publishing rights between maintainers of solidproject.org and the W3C LWS WG might become an issue

How does it differ with Solid CG?

[TallTed]

I'm just seeing this issue, circa 2026-08-17 19:30 ET.

First thing I did was shake my head.

In simple terms, W3C LWS WG documents should not be treated as Solid CG/WG/anyG documents.

W3C LWS WG has a specific charter which, while it inherits much from the Solid worldview, and, indeed, if completed as I think we all intend, will be key to making the Solid vision achievable — and failure to complete W3C LWS deliverables will prolong the efforts to bring Solid to life...

The W3C LWS WG is not a part of the Solid Project, and the LWS WG documents do not belong in Solid Project TR.

I'm not talking about hosting just listing [linking] to the existing drafts

That's a horse of a (somewhat) different color...

But I think you mean that you would have some other document in solidproject.org/TR and that document would include links to the W3C LWS WG outputs. Is that right? Not symlinks, such as they might be created, that let people dereference links into solidproject.org/TR that returned the W3C LWS WG outputs as if they were hosted in solidproject.org/TR?

I recommend closing this issue as "not planned", and not wasting too many more of the cycles none us can really spare.

[elf-pavlik]

LWS WG charter lists various inputs from Solid CG
https://www.w3.org/2024/09/linked-web-storage-wg-charter.html#deliverables

If someone considers implementing Solid, especially if they try to determine stability of various specs, having LWS WG work ommited doesn't communicate the state of Solid well. New (beta) CG templates communicate stability of CG drafts much better
https://github.com/w3c/cg-program/tree/main/beta-2026#specifications-for-the-beta

Note

This technology is experimental and will change.

Sometimes in 2027, after LWS WG re-charter, LWS 1.0 specs will start reaching W3C CR. For someone looking for stability this is the best Solid can provide.

[uvdsl]

I agree with @TallTed. WG and CG are separate work environments. The LWS WG does not advance "Solid". The WG is not subscribed to the vision of the Solid Project. Instead, the LWS WG creates a separate W3C REC (and maybe other documents).

The fact that the CG provided input documents to the LWS WG does not mean that the resulting REC directly supersedes the input documents in the CG. The REC is not an iteration on the input document. It is a separate document with different scope and design philosophy.

That REC might be useful to the Solid Protocol or Solid Project in the future (if the CG decides so, potentially with selection/extensions/modifications/amendments). But so are a million other things (as @csarven pointed out already) like LDP or SPARQL or CIDs, which we also do not list under /TR.

As you try to communicate "stability": Linking to a draft of a specification does not help to indicate stability.
If someone wants to implement the Solid Protocol, they should look at the Solid Protocol CG report.
If someone wants to implement LDP, they should look at the W3C LDP REC.
If someone wants to implement LWS, they should look at the W3C LWS drafts / CR / REC (whenever they come out).

The goal and scope of this issue already starts to move as seen be the updated issue title.
I therefore propose to close this issue and to defer further discussion around how the LWS Protocol can be useful for the Solid Protocol when the LWS specifications are in a stable state.

[elf-pavlik]

The goal and scope of this issue already starts to move as seen be the updated issue title.

Many of the drafts listed in /TR are not published in that namespace. Changing title only clarifies the original intent, nothing is changing.

The LWS WG does not advance "Solid". The WG is not subscribed to the vision of the Solid Project.

LWS WG has rep seat at ODI-Solid AC, just as Solid CG or Solid Practicioners. I think there is a misunderstanding that Solid CG is somehow in a center of the Solid Project - it's just one of many cluseters and none of them is in the center. The ODI which stewards the Solid Project is probably the most central and the one who owns the solidproject.org domain and I would say Solid Project brand as well.

[uvdsl]

The ODI which stewards the Solid Project is probably the most central and the one who owns the solidproject.org domain and I would say Solid Project brand as well.

I would like to express my understanding that

• stewarding is not owning
• "ODI-Solid AC" stands for "Advisory Committee to the ODI", which implies that decision of ODI are to be based on the advice from that committee
• who receives a seat at the AC, e.g., an LWS WG chair who might provide valuable input from their standardization experience, is a decision of the ODI. I am not convinced that that would imply that the LWS WG is subscribed to the vision of Solid or advances "Solid"
• nobody said that the Solid CG is the center of the Solid Project in this issue
• /TR lists Solid CG’s technical reports (TR). This is CG space. Not "specifications that might be helpful to achieve the vision of the Solid Project" space.

That is it from my side.

[elf-pavlik]

Possibly the whole /TR page, specific to Solid CG soon can be redirected to https://www.w3.org/groups/cg/solid/publications/ (currently 404)
once ongoing redesign is ready: https://lists.w3.org/Archives/Public/public-council/2026Aug/0007.html

solidproject.org could focus on offering broader overview of which technical documents from W3C, IETF, (EDMA?) are relevant to the broader Solid Project

[csarven]

Thanks Pavlik. This lines up with what was raised earlier here re https://solidproject.org/TR/ being Solid CG-scoped and URI ownership/persistence, the redirect is basically that principle in action.

It also matches what I proposed in w3c-cg/solid#79 : moving CG assets and publications to proper W3C space, with redirects from solidproject.org to W3C space, for example. So this is already covered there.

Given that, shall we close this issue as not planned and continue any further redirect/scope discussion on 79, as well as any new issues?

[elf-pavlik]

I'll create a new issue to track the need for a better overview of technical documents that are fundamental to Solid Project, including LWS WG, Solid CG and possibly other specs from other venues. Then I'll close this issue.