- From: Steve Speicher <sspeiche@gmail.com>
- Date: Tue, 14 Oct 2014 11:51:01 -0400
- To: Andrei Sambra <andrei.sambra@gmail.com>
- Cc: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>, John Arwe <johnarwe@us.ibm.com>
On Tue, Oct 14, 2014 at 11:43 AM, Andrei Sambra <andrei.sambra@gmail.com> wrote: > Hi all, > > On Tue, Oct 14, 2014 at 11:06 AM, Steve Speicher <sspeiche@gmail.com> wrote: >> >> Hi Nandana, >> >> On Mon, Oct 13, 2014 at 9:59 AM, Nandana Mihindukulasooriya >> <nmihindu@fi.upm.es> wrote: >> > Hi John/SteveS, >> > >> > On Fri, Oct 10, 2014 at 5:50 PM, John Arwe <johnarwe@us.ibm.com> wrote: >> >> >> >> Moving this onto the right list for drafting a consensus response. >> >> >> >> > I also have a small comment that I've been meaning to send regarding >> >> > the >> >> > interaction model. >> >> > >> >> > 5.2.3.4 states that "Clients use the same syntax, that is HTTP Link >> >> > headers, to specify the desired interaction model when creating a >> >> > resource as servers use to advertise it on responses." >> >> > >> >> > I noticed that in the primer, the POST request to an LDP-BC does not >> >> > contain a link header expressing the type of the resource to be >> >> > created. >> >> > That also seems to be the behaviour of test suite. However, the POST >> >> > request to an LDP-DC *contains* the Link header Link: >> >> > <http://www.w3.org/ns/ldp#Resource>; rel="type", while *none* of the >> >> > examples in the LDP spec show a Link header being sent with POST >> >> > requests. >> >> >> >> THAT should be fixed, for sure. >> >> The only way a LDP client gets predictable behavior is by specifying >> >> the >> >> interaction model. >> >> That's what the examples should show, period... that which is >> >> interoperable. >> > >> > >> > I'm a bit confused regarding what is the consensus regarding including >> > the >> > interaction model header and what to do in the primer examples on >> > POST/Create. >> > >> > In a previous email SteveS mentioned "I think requiring the header on >> > create >> > was not intended and not desirable. IF the header is present AND the >> > server >> > can honor the request, then the client overrides whatever the server >> > would >> > have done based on the content. So I think that it makes complete sense >> > for >> > LDP servers to determine the interaction model based on the content of >> > the >> > creation request, with the Link header being part of that.". I thought >> > it >> > was more biased towards not including the header in the primer examples. >> >> Just stating my personal preference to "point people in the right >> direction" instead of "entirely open". So I'd suggest we put >> something in BP (maybe primer) that says when client doesn't supply >> Link: rel="type" it is impl-specific, though they could dig into the >> content, find rdf:type to determine IM and send back Link: rel="type" >> indicate what it picked for the newly minted URI. >> >> > But John's reply as well as Issue-91 suggests that we should include the >> > type Link relation header in the POST creation requests. >> > >> > So shall we include the interaction model header in all the POST >> > creation >> > examples? >> >> POST creation of LDPCs, yes. POST creation of LDPRs, no. I'm not >> sure what including type="LDPR" would mean when posting a LDPR to a >> >> LDPC, as it should not affect the already set interaction model of the >> LDPC. Perhaps that is some extension to indicate on a per-request to >> a LDPC but feels a bit like it would violate what we have a MUST >> requirements on honoring client's requested interaction model on >> creation of the container (and would need to be expanded to other >> operations that affect containment and membership, like DELETE). >> > > I thought the rel value would always be "type" (not "LDPR") when posting an > LDPR to an LDPC -- i.e. Link: <http://www.w3.org/ns/ldp#Resource>; > rel="type" . > That was just my confusing shorthand for Link: <http://www.w3.org/ns/ldp#Resource>; rel="type" - Steve > -- Andrei > >> >> - Steve >> >> > >> > Best Regards, >> > Nandana >> > >> > >> > >> > >> >
Received on Tuesday, 14 October 2014 15:51:28 UTC