Re: PUT to create, was Re: Proposal: normative changes for profiles

On 25 Sep 2013, at 14:25, John Arwe <johnarwe@us.ibm.com> wrote:

> > I was trying to explain this to someone recently and it seemed to us
> > there's a big whole in this design.  How is a client supposed to 
> > know where it can PUT things?     
> 
> Valid question.  Applies to PATCH-as-create too, I suspect.  I hedge only because I remember that 5789 does say PATCH can be used to create new resources, but I don't remember if it suggests a PUT-like, POST-like, or no (silent on) interaction model. 
> 
> > And if it does PUT things there, do
> > they end up linked from anywhere?    What seems right to me, taking 
> > a stab in the dark, is that at LDPC can have some associated URL 
> > space, and if you do a PUT-to-create in that space, it's pretty much
> > the same as POSTing to the LDPC.     So the new PUT URL ends up as a
> > resource in the LDPC as well.   

yes, that's an addition reaon for one of the proposals I put forward for an iContainer.
http://www.w3.org/2012/ldp/track/issues/50

This was closed in a hurry in Spain this summer. I don't think it was a very considerate closing

> 
> As long as the URL you selected is not already in use, that's the fuzzy model I've had in my head.  Given that I don't know of anyone on my end planning to implement create-via-PUT, I have not thought it through deeply myself. 
> 
> IMO the important distinction is the "create" semantic, not the HTTP method used.  I would expect the same consequences on membership triples as the result of any create, irrespective of the HTTP method employed on the request. 
> 
> > I imagine an LDPC could advertise 
> > this functionality with a triple or like: { <> ldp:memberCreationURLPrefix 
> > "http://example.org/container75_" }.     
> 
> > Alternatively, we might 
> > just agree the URL prefix is the LDPC URL (plus a slash).   
> > Then we 
> > just need a flag like { <> a ldp:Puttable }.   

I think the simpler solution is the most intuitve one. Just allow us to define a subclass of containers that behave
the way people expect.

> 
> The Allow response headers seem sufficient to convey the semantic I infer from your choice of predicate. 
> I don't know that it's the semantic you want though - saying that PUT is allowed gives a client no guarantees that Create is allowed via PUT.  This is analogous to the issue I raised when we were naming the proposed Accept-Post header. 
> 
> >  ... and I guess you 
> > don't even need that flag with Vanilla servers, which always have 
> > that flag set?
> 
> If we decide (as proposed) that vanilla servers MUST support PUT, then yes knowing that it's a vanilla server is enough *for an LDP-aware client* to know that create-via-PUT is supported by the server.  If your goal is to have a more broadly useful flag (ala the Accept-Post discussion) that any *"new-flag-aware" HTTP client* could use, then you'd still want some additional message content. 
> 
> Betcha can't tell I've been looking at the Conformance section changes over the past 2 days (not committed yet though - tease). 
> 
> > I'm not sure why anyone would want to do this.  Maybe for some apps 
> > the clients have an algorithm for picking the URLs and the server 
> > doesn't know it or can't implement it, itself?   Dunno.
> 
> I'm unclear on what/how much of the preceding you mean by "this".  Your "it seemed to us there's a big whole" statement implied to me that we're discussing something likely to result in/seed a new issue, but your ending calls that into question. 
> 
> I could posit cases where the server might not know (all) the potential URL space(s), but without a concrete use case that would just be random speculation (and the one I have in mind I could probably play the "it's an access control issue" Jedi mind trick with). 
> 
> Best Regards, John
> 
> Voice US 845-435-9470  BluePages 
> Tivoli OSLC Lead - Show me the Scenario 
> 
> 

Social Web Architect
http://bblfish.net/