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

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

From: Alexandre Bertails <bertails@w3.org>
Date: Thu, 24 Jan 2013 09:24:19 -0500
Message-ID: <51014413.5060205@w3.org>
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.


> 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

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 16:17:36 UTC