- From: Nandana Mihindukulasooriya <nmihindu@fi.upm.es>
- Date: Fri, 28 Mar 2014 17:48:07 +0100
- To: John Arwe <johnarwe@us.ibm.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAAOEr1k9CVGyvotY_zywiW05YmbiJC=EkBFDDYssmggjnO3UCA@mail.gmail.com>
+1 for the Option 1. Best Regards, Nandana On Fri, Mar 28, 2014 at 2:28 PM, John Arwe <johnarwe@us.ibm.com> wrote: > 5.2.3.4 needs to define the context uri as the to-be-created resource, > since RFC 5988 only defines the default context uri for responses to > retrieval requests. > > We have a choice about how to do that; > 1: simply specify that the *default* context URI is the to-be-created > resource's URI > 2: define a specific syntax (presumably "<>" aka the null relative URI) as > specifying the to-be-created resource's URI > Option 1 is better insofar as clients get the desired behavior by default; > option 2 requires them to explicitly add the request header. I propose > option 1. > > 5988 always allows the sender to override the default context URI by > explicitly including anchor="context URI" on the Link header, so (on the > error paths) there is no difference from the server's point of view. On > the normal path the server has code of similar (minimal) complexity under > either option. > > The same issue exists with PUT; and arguably with OPTIONS and DELETE, > depending upon whether or not one considers those to be "retrieval" > requests. But as the action was limited to put/post, and there's no > LDP-assigned semantics on the others, no reason to flog them. > > 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 >
Received on Friday, 28 March 2014 16:48:51 UTC