- From: Steve Speicher <sspeiche@gmail.com>
- Date: Fri, 28 Mar 2014 13:40:49 -0400
- To: John Arwe <johnarwe@us.ibm.com>
- Cc: "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
- Message-ID: <CAOUJ7JrFmu2TedvGE=vXwC+2CWQPTi8dGojDhximjUz8yjcVAA@mail.gmail.com>
On Fri, Mar 28, 2014 at 9:28 AM, 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 > +1 for #1. - Steve Speicher > 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 17:41:16 UTC