- From: Henry Story <henry.story@bblfish.net>
- Date: Thu, 24 Jan 2013 16:33:16 +0100
- To: Alexandre Bertails <bertails@w3.org>, Arnaud Le Hors <lehors@us.ibm.com>, public-ldp-wg@w3.org
- Message-Id: <B45AF0FC-339E-4633-BA06-111CD7583793@bblfish.net>
On 24 Jan 2013, at 16:01, Henry Story <henry.story@bblfish.net> wrote: > > On 24 Jan 2013, at 15:24, Alexandre Bertails <bertails@w3.org> wrote: > >> 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. > > Just a question: Is it only during the creation time > when the POSTed content contains > > <> a ldp:Container . > > that that action creates a Container? > > Or can one later append that triple to any resource to > turn it into a container? One could make the append rule more subtle for what I have called ldp:Content objects that I have talked about today: A POST of a graph containing the triple: <> a ldp:Container would create a new container resource. That seems quite plausible.... > > >> >> 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 >> >> > > Social Web Architect > http://bblfish.net/ > Social Web Architect http://bblfish.net/
Attachments
- application/pkcs7-signature attachment: smime.p7s
Received on Thursday, 24 January 2013 15:34:04 UTC