Re: WAC LDP And the Accept header

On 15 Jan 2014, at 19:45, Henry Story <henry.story@bblfish.net> wrote:

> Hi all,
> 
> I have updated the WAC wiki page wiht an LDP sepecific section.
> 
>  http://www.w3.org/wiki/WebAccessControl#WAC_And_LDP
> 
> One part of it looks at how HTTP verbs tie up with WAC. I did
> not yet look at the Control section. But one thing that one does
> wonder a bit is if these words should not align more closely with the
> HTTP verbs, or how they should tie together.

Here is the relevant section of the wiki page with the table:
WAC relation to HTTP Verbs
In LDP an OPTIONS request MUST return a Allow header stating what HTTP methods can be used on a resource. Those headers can be returned ( whether they MUST be is an open question [1] )
Here is an initial mapping between the HTTP verbs used by LDP and the wac ontology.
HTTP VERBS wac:Read wac:Write wac:Execute wac:Append
GET √ x  ? x
PUT x √  ? x
POST x √  ? √ ?
DELETE x √  ? x
PATCH x √  ? √ with INSERT only
It would be nice if the Allow header could give mostly the right hints to the client about what he is allowed to do without needing to parse the acl links, as parsing the ACL link and following the redirects could require quite a number of hops (and may not be available to the client). This still would leave a non-authenticated user with the task of having to follow those links, if he wants to discover what rights authentication would bring.
Looking at the above table it is clear that wac:Read maps nicely to GET and that wac:Write maps nicely to all the others methods, except READ.
But this still leaves the following two problems:
does wac:Append apply to POST, ie is POST an append operation? (It feels like it.)
a client that knows it has PATCH access might not yet know if can only use INSERT, ie, only update or if it can also DELETE triples from a graph.


Social Web Architect
http://bblfish.net/

Received on Thursday, 16 January 2014 13:13:24 UTC