solid
proposal: deleting a container is a noop
The spec already says that creating a container is automatic (mkdir -p).
So if you create and then delete /foo/bar.ttl, it seems asymmetric that you then do have to delete the /foo/ container afterwards if you no longer want to see foo as a member listed in /.
This would also resolve confusion around how exactly container deletes should work (should sub-trees also be deleted, should they fail if the container is non-empty, what should happen if you deleted a resource but not its ACL, how can you know if any ACL docs exists, if they are not listed as members, etc.)
My reading of the spec is that creating a container (via POST) is manual. That creating a container on its own with PUT is not allowed. That a container may be created as a by-product of creating resources in it. So deleting a container is symmetric with creating one with POST and should be manual. There are also use cases in which one wants to delete all the resources in a container but not delete the container.
There are also use cases in which one wants to delete all the resources in a container but not delete the container.
Which use cases are these?
Re-Initializing a folder tree for an app. But because of the way PUT operates, deleting it or not deleting it is pretty much the same so nevermind.
And what about creating/foo/bar/baz.ttl. When we delete we might want to delete baz.ttl And /foo/bar without wanting to delete /foo But if it's symmetric with the create it would be.
Ah, here's a use case: I create /foo/jamal/ to hold messages from Jamal and I create a .acl file to give Jamal write access to that folder. Just because I delete the last message from Jamal doesn't mean I want to delete the folder and its .acl.
a container with a .acl document in there is not an empty container.
I mainly proposed this to track it as an option, I think the current behaviour is fine as it is, and don't think it's worth a spec change.