W3C home > Mailing lists > Public > public-ldp-wg@w3.org > January 2013

Re: ISSUE-36: Summary of ways of making containers

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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:11:44 UTC