- From: Arnaud Le Hors <lehors@us.ibm.com>
- Date: Wed, 23 Jan 2013 16:38:24 -0800
- To: public-ldp-wg@w3.org
- Message-ID: <OFD7B23F6C.3B619AB5-ON88257AFD.00012105-88257AFD.000384F1@us.ibm.com>
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? 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 00:38:57 UTC