Are URI semantics just necessary or sufficient to determine containment relation?
Nobody has claimed this yet.
- Dominant language
- HTML
- Stars
- 563
- Forks
- 108
- Avg merge
- 4d 13h
- Merged PRs (30d)
- 3
Description
Spec says that:
The slash (/) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [RFC3986]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource.
If it is necessary:
If above statement is expressing a necessary condition, then if two resources are known to be in container-child relation, their uri MUST follow (neccessary) follow above condition.
But vice-versa may not be true. I.e, if uris of two resources share hierarchical relation ship, then they need not be in containment relation, as the condition is not sufficient.
This indeed seems the case, that resource with uri a/abc.acl, need not be child of resource with uri of a/, even though their uris are in hierarchical relation. But it instead may be aux of a/abc.
If it is also sufficient:
Let's assume, there are three resorces:
R1with uri/path/to/r1/,R2with uri/path/to/r1/abc,Rxwith uri/path/to/r1/<slug>.
Then if condition is also sufficient, one can conclude that Rx MUST be child of R1`, for they satisfy suffient condition for containment.
But we see this is not the case. We can see that if <slug> in Rx is abc.acl, then it may be instead acl of R2 rather than child of R1.
Problem
We above saw that, uri-slash-semantics are actually necessary for containment to hold, but not sufficient to unambiguously infer containment between to resources.
But we have been seeing in many places, the slash semantics beeing inconsistently treated as sufficient, and being used to infer containment when that may not be guaranteed.
For example:
If a container resource R1 with uri /path/to/r1/ is known to exist, and resource Rx with uri /path/to/r1/<slug> is is known to not yet exist, and a GET is sent for Rx, then should we consult acl:default of R1's acl for determining status code to 403/404?
My sense says that, as resource Rx known to not exist yet, it is not child of any resource, as semantics are necessary but not sufficient. This is indeed the case if <slug> may be abc.acl, it can be slot for aux of other instead. But many places in the issues, it is taken for granted that R1's acl's acl:default will be applied to determine method access over Rx.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start with the quoted specification text on slash semantics and the linked RFC3986 reference, then trace the containment and ACL-default examples in this issue. Compare the necessary-versus-sufficient interpretations and the /path/to/r1/ examples. Done means the specification has an agreed, unambiguous rule for containment and access decisions.
Written by the indexing model from the issue text.
Assessment
- Domain
- api, documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100