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

On 09/24/2013 01:50 PM, John Arwe wrote:
> The 3 editors took a quick pass through the spec, looking at existing 
> conditionals (may, should) to see where they might become MUSTs etc on 
> a vanilla-class server.
> This is the set for which we all independently came to the same 
> conclusion for both profiles.  The existing text and per-profile 
> proposed value is listed below.  As with the "change to informative" 
> proposal, since all 3 editors agreed taking independent passes 
> (indicating that these may be non-controversial) I'm making it a 
> single proposal.  In most cases where the chocolate constraint == 
> today's (which is the vast majority), it's just a matter of keeping 
> chocolate aligned with the existing base of WG decisions.
>

Excellent.   I'm happy with all these choices.   But this reminded me of 
another issue I've been meaning to ask about.   Details below.

> If you object (-1) to any of the listed sections being changed, please 
> provide the specific list in your response and we'll simply treat 
> those separately.
>
> If you do not object (+0 or +1), either save it for a WG decision on 
> one of the next meetings or (if you're sending regrets for that 
> meeting) email to get your vote in early.
>
>
> 4.2.9 LDPR servers SHOULD enable simple creation and modification of 
> LDPRs.
> vanilla: MUST
> chocolate: SHOULD
> This changes clause 1 of  4.2.9 only.
>
> 4.3.3 LDPR servers SHOULD provide a text/turtle representation of the 
> requested LDPR [TURTLE].
> vanilla: MUST
> chocolate: MUST
>
> 4.5.6 LDPR servers MAY choose to allow the creation of new resources 
> using HTTP PUT.
> vanilla: MUST
> chocolate: MAY
>

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?    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.  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 }.    ... and I guess you don't even need 
that flag with Vanilla servers, which always have that flag set?

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.

         -- Sandro

> 4.5.7 LDPR servers SHOULD allow clients to update resources without 
> requiring detailed knowledge of server-specific constraints.   This is 
> a consequence of the requirement to enable simple creation and 
> modification of LPDRs.
> vanilla: MUST
> chocolate: SHOULD
>
> 4.8.2 LDPR servers SHOULD allow clients to update resources without 
> requiring detailed knowledge of server-specific constraints.   This is 
> a consequence of the requirement to enable simple creation and 
> modification of LPDRs.
> vanilla: MUST
> chocolate: SHOULD
>
> 4.8.3 LDPR servers SHOULD NOT allow clients to create new resources 
> using PATCH. POST (to an LDPC) and/or PUT should be used as the 
> standard way to create new LDPRs.
> vanilla: MUST
> chocolate: MAY
> The replacement of Should Not was driven by the consideration: it 
> would look strange to see us Must-ing it in one case (5789 explicitly 
> mentions Create, so Must-ing it aligns with the PUT feedback from 
> TimBL) and then Should Not-ing it in the other.
>
> 4.10.2.1 LDPR servers SHOULD allow clients to retrieve large LDPRs in 
> pages.
> No change ...here for context with the following sentence, below.
>
> 4.10.2.1 In responses to GET requests with an LDPR as the Request-URI, 
> LDPR servers that support paging SHOULD provide an HTTP Link header 
> whose target URI is the first page resource, and whose link relation 
> type is first [RFC5988].
> vanilla: MUST
> chocolate: MUST
>
> 5.8.1 LDPC servers are RECOMMENDED to support HTTP PATCH as the 
> preferred method for updating LDPC non-membership properties.
> vanilla: MUST
> chocolate: SHOULD
>
> Best Regards, John
>
> Voice US 845-435-9470 BluePages 
> <http://w3.ibm.com/jct03019wt/bluepages/simpleSearch.wss?searchBy=Internet+address&location=All+locations&searchFor=johnarwe> 
>
> Tivoli OSLC Lead - Show me the Scenario
>