Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Clarify that slash doesn't entail containement #538

Closed
wants to merge 1 commit into from
Closed

Clarify that slash doesn't entail containement #538

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
6 changes: 6 additions & 0 deletions ED/protocol.html
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -686,6 +686,12 @@ <h3 property="schema:name">URI Slash Semantics</h3>
<p id="uri-slashes-hierarchical-identifier">The slash (<code>/</code>) character in the URI path indicates hierarchical relationship segments, and enables relative referencing [<cite><a class="bibref" href="#bib-rfc3986">RFC3986</a></cite>]. The semantics of the slash character is shared by servers and clients. Paths ending with a slash denote a container resource. [<a href="https://github.com/solid/specification/issues/35#issuecomment-547949014" rel="cito:citesAsSourceDocument">Source</a>]</p>

<p><span about="" id="server-uri-trailing-slash-distinct" rel="spec:requirement" resource="#server-uri-trailing-slash-distinct"><span property="spec:statement">If two URIs differ only in the trailing slash, and the <span rel="spec:requirementSubject" resource="#Server">server</span> has associated a resource with one of them, then the other URI <span rel="spec:requirementLevel" resource="spec:MUSTNOT">MUST NOT</span> correspond to another resource.</span></span> <span about="" id="server-uri-redirect-differing" rel="spec:requirement" resource="#server-uri-redirect-differing"><span property="spec:statement">Instead, the <span rel="spec:requirementSubject" resource="#Server">server</span> <span rel="spec:requirementLevel" resource="spec:MAY">MAY</span> respond to requests for the latter URI with a 301 redirect to the former.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567482817" rel="cito:citesAsSourceDocument">Source</a>]. <span about="" id="server-authorization-redirect" rel="spec:requirement" resource="#server-authorization-redirect"><span property="spec:statement"><span rel="spec:requirementSubject" resource="#Server">Servers</span> <span rel="spec:requirementLevel" resource="spec:MUST">MUST</span> authorize prior to this optional redirect.</span></span> [<a href="https://github.com/solid/specification/issues/107#issuecomment-567454889" rel="cito:citesAsSourceDocument">Source</a>].</p>
<div class="note" id="slash-and-containment" inlist="" rel="schema:hasPart" resource="slash-and-containment">
<h4 property="schema:name"><span>Note</span>: Slash and containement</h4>
<div datatype="rdf:HTML" property="schema:description">
<p>URI Slash Semantic on its own is not sufficient to determine containment. For example <code>/albums/garfield</code> does not entail <code>&lt;/albums/&gt; ldp:contains &lt;/albums/garfield&gt;</code></p>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The current wording ("URI Slash Semantic on its own is not sufficient to determine containment.") is possibly confusing. After all, within the context of Solid, slash semantics ARE sufficient to determine containment (as of the current spec, which reads in the section on Resource Containment: "There is a 1-1 correspondence between containment triples and relative reference within the path name hierarchy.").

I would therefore insert the following, and possibly also move/copy the note to the Resource Containment section (in fact, it would probably be clearer if the Slash Semantics section was part of Resource Containment altogether, as that is where its impact lies.).

Suggested change
<p>URI Slash Semantic on its own is not sufficient to determine containment. For example <code>/albums/garfield</code> does not entail <code>&lt;/albums/&gt; ldp:contains &lt;/albums/garfield&gt;</code></p>
<p>Outside of the context of Solid, URI Slash Semantic on its own is not sufficient to determine containment. For example, without knowing whether the resource server adheres to Solid, <code>/albums/garfield</code> does not entail <code>&lt;/albums/&gt; ldp:contains &lt;/albums/garfield&gt;</code></p>

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm 👎 on the original wording in this PR, but I think with the suggestion, I'm 👍 , as it is indeed a clarification that could be useful to some.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find Wouter's suggestion to be generally a bit more useful here as a note. (I'm pressed on time to look at the exact location where it'd be best to put this in... but can review again after the change goes through, if any).

I'd suggest paraphrasing "outside of the context of Solid" into something more concrete, e.g., whether that's explicitly about the Solid Protocol (including its dependencies) or in particular the Storage space, or something else.

I'd also putting a bit more emphasis / clarification / distinction on the expectations/interpretations (if any) from the identifier vs. what might a representation of it describe it to be.

Pavlik, since you originally proposed, if you're on board with these, and other suggestions, could you like to or have Wouter give it another pass at the note?

</div>
</div>
</div>
</section>

Expand Down