On Thu, Oct 9, 2014 at 9:59 PM, Robert Sanderson <azaroth42@gmail.com>
wrote:
>
> I think that the question that the specification needs to address is the
> precedence of the Slug header and a relative URI in the request body when
> creating a new resource.
>
> If an LDP server receives a POST to a container /objects/ with the header:
> Slug: a
> and the body:
> <b> a ldp:Container.
>
> Should it create:
> 1. /objects/a and the <b> is renamed
> 2. /objects/a and the resource created doesn't have any description about
> a, it returns information about a non-existant <b>
> 3. /objects/b and the slug is ignored
> 4. /objects/ab by following the slug and then appending the name in the
> body ala #me
> 5. Nothing because this is an error
>
LDP spec says
[[4.2.1.5 LDP servers must assign the default base-URI for [RFC3987]
relative-URI resolution to be the HTTP Request-URI when the resource
already exists, and to the URI of the created resource when the request
results in the creation of a new resource.]]
So if we assume the URI of the created resource is ../objects/a it will be
../objects/b. If the representation is persisted as is with the relative
URI <b>, it will be consistently resolved to the same when later GET on
../objects/a.
The only problem I see is if someone resolve the same against ../objects/a/
(for example if the created resource is a container and the minted URI has
an ending slash). In this case it will be resolved <../objects/a/b>.
However, I think one have to be careful about the ending slash of the
minted URI because it could have an effect on the relative URIs in the
body.
Best Regards,
Nandana