- From: Alexandre Bertails <bertails@w3.org>
- Date: Thu, 24 Jan 2013 09:24:19 -0500
- To: Arnaud Le Hors <lehors@us.ibm.com>
- CC: public-ldp-wg@w3.org
On 01/23/2013 07:38 PM, Arnaud Le Hors wrote: > If I got this right, the premise for doing anything else other than > using POST the way it's done for other resources is that some don't want > to pay the price of having to parse the content to find out what the > type of the resource to be created is. > > Yet, it also seems to be accepted that in most cases one will parse the > content to validate it anyway, if nothing else. > > Furthermore, it is also accepted that we can't depend on something like > MKCOL and we need a fallback mechanism. > > Given all that, I have to ask: Why don't we just accept that finding out > what type of resource needs to be created is a price some will have to > pay and stick to POST? I'd be fine with that. Alexandre. > > In practice, I think there are two general categories of use cases. 1. > generic/vanilla server that simply stores triples and regurgitates them > without doing anything special with them. 2. application specific server > - this is a bug tracking system for instance - which translates the > triples into an actual application specific object. > > In the latter case, the server for sure will want to parse the content > received to figure out exactly what type of object is to be created and > if the content received has all the bits and pieces required to satisfy > the application needs to create such an object. So, this requirement > adds no extra burden. > > In the former case, there may be a real additional cost but is it > significant enough to justify doing anything different? And there may be > ways to optimize this by deferring that operation to when the server is > required to actually do anything different. > -- > Arnaud Le Hors - Software Standards Architect - IBM Software Group
Received on Thursday, 24 January 2013 14:24:33 UTC