Multiple Containment for LWS Containers

[laurensdeb]

This PR continues on the discussions of the proposed mechanics for containers in LWS.

Changes from the initial discussions

Context

It is part of a series of three PRs:

• "Introducing support for Containers in the LWS protocol" - brings basic support for the use of containers, their representations and mechanics at the protocol level.
• "Pagination for LWS Containers" - brings pagination support to the LWS Container representations.
• "Multiple Containment for LWS Containers" - defines how a multiple containment mechanism for LWS Containers could work.

---

Preview | Diff

[elf-pavlik]

I think there needs to be a way to advertise single or multi containment in Storage Description, otherwise how client will know what is supported.

[w3cbot]

This was discussed during the #lws meeting on 23 February 2026.

View the transcript

Pull Request 83 Multiple Containment for LWS Containers (by laurensdeb)

laurens: the wording in this PR may still be too strict
… I tried to contrast both approaches single containment vs. multiple containment
… the working prevents circular references
… this PR introduces text to move a resource to another container
… part of this text could make sense also for single containment (for moving large resources)

<TallTed> Multiple Containment should be similar to UNIX hard links. Single Containment with aliases/shortcuts should be like UNIX soft links. Single Containment without aliases/shortcuts will lead to undesirable data duplication in some deployments.

laurens: I think we should focus on the other PRs first

<Zakim> bendm, you wanted to ask about described server features

bendm: you are describing multiple containment as a features that servers may or may not support
… did we discuss the affordances that the server may have?

laurens: we don't really have anything in terms of classes/profiles of servers in the spec yet
… I think this is the first optional features that we would introduce

<Zakim> acoburn, you wanted to mention server description resources

laurens: if we introduce it, we should introduce conformance classes of sorts at the same time

acoburn: the storage description may contains "services" and "capabilities"
… services will describe endpoint providing the service
… capabilities could be extensions of LWS or could be optional features of LWS
… I think that multiple-containment could be advertised as a capability

<pchampin> +1 to that

acoburn: thanks laurens for walking us through these PRs

---

[TallTed]

As I was feebly trying to express during the call...

In the world of UNIX-like OS, filesystems are built of inodes, which the user rarely if ever is aware of. Users know directories (a/k/a folders, containers, etc.) and documents (a/k/a files, etc.).

Advanced users know of things like softlinks (a/k/a aliases, shortcuts), which are coreferences -- multiple fullpath identifiers that lead to the same underlying document/data, where if you "delete" the "original" identifier, you are deleting the document, and all other identifiers of that document suddenly report 404, because the underlying data is gone.

Expert users know of things like hardlinks, which are coreferences that all of them lead to the same underlying document/data, where you can delete all but any one of the identifiers, and all the data will remain available when referenced by that identifier, but all the other identifiers will 404 -- because the reference to the underlying data is gone.

I think this is what will be necessary to make LWS work as dreamed/conceieved.

[gibsonf1]

As an implementation, TwinPod will not support multiple containment, so hopefully this will be a VERY optional capability that servers can support only if they think it wise to do so.

[elf-pavlik]

Looking at other systems that will be impacted https://raw.githack.com/w3c/lws-protocol/notifications-spec/lws10-notifications/index.html#subscription-scope

At first glance I don't see issues related to subscriptions being applied recursively.

Something that may need to be considered more closely is how it impacts AuthZ. I would imagine with WAC it should work fine, but ACP allows explicit deny, which possibly could lead to contradicting policies if one parrent has allow ond members and another parent has deny on members.