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

Add heuristic to determine resource type #160

Merged
merged 7 commits into from
Jun 9, 2020
Merged

Add heuristic to determine resource type #160

Changes from 6 commits
Commits
Show all changes
7 commits
Select commit Hold shift + click to select a range
c13dd42
Add heuristic to determine resource type
csarven May 12, 2020
3207529
Add shared slash semantics for heuristics
csarven May 12, 2020
b8bf670
Minor grammar
csarven May 12, 2020
e40d685
Update heuristics to include link relation type
csarven May 12, 2020
aadf3a3
Add class=data to table
csarven May 13, 2020
6ed70e2
Init reframe heuristics
csarven May 15, 2020
c1aac42
Revise resource type heuristics
csarven Jun 9, 2020
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
98 changes: 98 additions & 0 deletions main/resource-access.bs
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -130,6 +130,104 @@ Note:
Servers that wish to disable URI re-use may want to use the `410` status
code.

### Resource type heuristics ### {#resource-type-heuristics}

The semantics of slashes in URI paths are shared ([[#uri-slash-semantics]]).

Servers MUST apply the following heuristics to determine the request's
resource type and to construct the effective request URI for the target
resource of an HTTP `POST`
[[Source](https://github.com/solid/specification/issues/128#issuecomment-573033297)].
Copy link
Member

Choose a reason for hiding this comment

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

Consider explaining under what circumstances the server needs to fall back to this heuristic approach. (i.e. when the client does not specify an interaction model)?


The consistency of a request is determined by checking the optional `Link` and
`Slug` headers against the target URI
[[Source](https://github.com/solid/specification/issues/40#issuecomment-566995240)].

Servers supporting the `Slug` header MUST apply the shared slash semantics on
the `slugtext` on requests that also include the `Link` header with
`rel="type"`.

Issue:
Redefine `slugtext` eg. exclude recursive container creation?
[Related issue](https://github.com/solid/specification/issues/128)

<table class="data" id="heuristics-resource-type">
<caption>Heuristics to determine a resource type</caption>
<thead>
<tr>
<th>`Slug`</th>
<th>`Link`</th>
<th>Result</th>
</tr>
</thead>
<tbody>
<tr>
<td>`foo/`</td>
<td>No `Link` header.</td>
<td>Create a container with `foo/` appended to the request-URI.</td>
</tr>
<tr>
<td><code>foo/</code></td>
<td>`Link` header with `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a container with `foo/` appended to the request-URI.</td>
</tr>
<tr>
<td><code>foo/</code></td>
<td>`Link` header without a `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a resource with `foo` appended to the request-URI, check for
Copy link
Contributor

Choose a reason for hiding this comment

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

This exception I find very weird. I don't think we should derive anything from non-recognized Link headers. I.e., all no and other cases should be identical for me.

Copy link
Member Author

Choose a reason for hiding this comment

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

That's indeed what's intended. What's derived is that it is a non-Container resource. Slug will be ignored in this case. Would rephrasing help?

Copy link
Contributor

Choose a reason for hiding this comment

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

My interpretation of what written seems to be correct (so writing is ok); but I don't understand why from an unknown header can be derived the resource is non-Container. I don't think we should derive that.

Copy link
Member Author

Choose a reason for hiding this comment

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

What's recognised is "ldp:Container or a specialisation" (ldp:BasicContainer - as that's the only one currently required) as the "container type". I used "other than container type" to express their absence. Open to rephrasing.

Copy link
Contributor

Choose a reason for hiding this comment

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

Ah okay, so only Link header values with a type link relation are included then? Or do we really mean all Link header values?

Copy link
Member Author

Choose a reason for hiding this comment

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

Only the existence of Link with rel=type LDPC or LDP-BC is checked.

Note the check in prior row says "Link header with ldp:Container or a specialisation." - We are really talking about rel=type here.

So we can just mention the actual relation.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, I would make it clear that it is a rel=type header value. Then I have no further objections.

We could perhaps call them "indicated types" or so, and then declare above the table how those indicated types are extracted from Link. No strong opinion.

Copy link
Member Author

@csarven csarven May 12, 2020 •
edited
Loading

Choose a reason for hiding this comment

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

I used "or a specialisation" instead of ldp:BasicContainer figuring that if other container types are supported in the future, they will also follow the slash semantics. If server gets Link rel=type LDP-DC, it will create a container resource with trailing slash.

Copy link
Contributor

Choose a reason for hiding this comment

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

All fine with me, my issue/misunderstanding was in the phrasing of "Link header other than container type."

Copy link
Member Author

Choose a reason for hiding this comment

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

How about e40d685 for this draft?

consistency.</td>
</tr>
<tr>
<td>`foo`</td>
<td>No `Link` header.</td>
<td>Create a resource with `foo` appended to the request-URI, check for
consistency.</td>
</tr>
<tr>
<td>`foo`</td>
<td>`Link` header with `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a container with `foo/` appended to the request-URI.</td>
</tr>
<tr>
<td>`foo`</td>
<td>`Link` header without a `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a resource with `foo` appended to the request-URI, check for
consistency.</td>
</tr>
<tr>
<td><em>none</em></td>
<td>No `Link` header.</td>
<td>Create a resource with server determined identifier appended to the
request-URI, check for consistency.</td>
</tr>
<tr>
<td><em>none</em></td>
<td>`Link` header with `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a container with server determined identifier appended to the
request-URI.</td>
</tr>
<tr>
<td><em>none</em></td>
<td>`Link` header without a `rel="type"` targeting a valid LDP container
type.</td>
<td>Create a resource with server determined identifier appended to the
request-URI, check for consistency.</td>
</tr>
</tbody>
<tfoot>
<tr>
<td colspan="3">
</td>
</tr>
</tfoot>
</table>


## Auxiliary Resources ## {#rm}

### Background and Need ### {#ar-need}
Expand Down