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: Wed, 23 Jan 2013 10:43:07 -0500
Message-ID: <5100050B.9090601@w3.org>
To: Henry Story <henry.story@bblfish.net>
CC: Steve Speicher <sspeiche@gmail.com>, "public-ldp-wg@w3.org" <public-ldp-wg@w3.org>
On 01/23/2013 10:33 AM, Henry Story wrote:
>
> On 23 Jan 2013, at 16:20, Alexandre Bertails <bertails@w3.org> wrote:
>
>> On 01/23/2013 10:00 AM, Steve Speicher wrote:
>>> On Wed, Jan 23, 2013 at 4:41 AM, Henry Story <henry.story@bblfish.net> wrote:
>>>> In summary here are the proposed ways of allowing applications to make
>>>> containers:
>>>>
>>>> 1. Using the MKCOL HTTP Method from WebDAV
>>>> ------------------------------------------
>>>>
>>>>    - Works like GET/PUT/POST/DELETE .
>>>>    - Implemented in 100s of millions of clients on MS-Windows, OSX, Linux, and other Unixes for WebDAV
>>>>    - RFC: http://tools.ietf.org/html/rfc4918#section-9.3
>>>>
>>>
>>> Seeing the value in this.  If we want to tunneling the MKCOL through
>>> POST we could do that as well, something like X-HTTP-Method-Override:
>>> MKCOL.
>>>
>>> Note: we could do something similar for PATCH.
>>
>> Sadly, some http clients in old browsers won't let you add custom
>> headers either. We may have to consider the URL hack as a fall-back
>> (this is a common problem in the web apis world).
>
> I think what you call the URL hack may be what solution 3 - the container
> factory - is about. So in that case the container factory answer, could be
> something suggested in a seperate document as a workaround for dealing
> with problematic old browsers.

Of course you're right! But there are two different things here:
1. specifying the normal scenario with for example MKCOL
2. specifying a degraded mode to handle the case of clients that
cannot comply with the spec

So we need to do both.

> But seriously, any applications  using this api that is going to
> be working in the browser is going to be working in a browser that is
> using javascript, and using it a lot! It is only recently with the huge
> speed improvements in JS brought to modern browsers that such apps are
> even conceivable. So are old browsers really that relevant?

Because we're dealing with some W3C guys here, yes "old" browsers are
relevant :-) On a more serious note, the fact that this is a problem
for many of the web apis out there is a good indicator that we cannot
safely ignore it here.

Alexandre.

>
>>
>>>
>>>> 2. POST + server looks at content of graph
>>>> ------------------------------------------
>>>>
>>>>     if graph posted to ldp:Container </satellite/x4354/> contains the triple
>>>>
>>>>        <> a ldp:Container .
>>>>
>>>>     the server makes a container.
>>>>
>>>
>>> Makes sense.  Of course, client could add some non-member triples as
>>> this point as well.
>>
>> These "non-member triples" could also be part of the request-body of
>> the MKCOL. This is actually much more important than it looks at first
>> sight. For example, Andrei and I have a use-case where we need to add
>> other triples to "configure" the container.
>>
>> I can live with either 1.+fallback or 2., but I have a slight
>> preference for 1.+fallback as it makes the operation very clear, and
>> we can make decisions before looking at the body.
>>
>>>
>>>> 3. Link from LDPC to factory
>>>> ----------------------------
>>>>
>>>>     The container </satellite/y500/> contains a link to a factory <makeAnotherContainer> .
>>>>
>>>>     <> a ldp:Container;
>>>>        ldp:containerFactory <makeAnotherContainer> .
>>>>
>>>> <makeAnotherContainer> would then be something else besides an LDPR or an LDPC.
>>>> It  would need to describe itself as a factory and tell you for which collection it was a
>>>> factory for. One can then POST something into the <makeAnotherContainer> factory in
>>>> order to create a collection inside the original </satellite/y500/> .
>>>>
>>>
>>> I guess I don't fully understand why adding this overhead helps.
>>>
>>> This seems to set us up to need a "Factory" predicate for any kind of
>>> thing that can be created.  Perhaps we could instead say way kind of
>>> thing can be created in this container.
>>>
>>> For example,
>>>
>>> <> a ldp:Container;
>>>         ldp:canCreate ldp:Container, oslc:ChangeRequest .
>>>
>>> Then one could look up these Classes to see what they look like.  This
>>> may be something better for LDP 2.0 (for lack of better name).  I have
>>> a need for something like this anyway, knowing what kinds of things
>>> the container accepts.  Disclaimer, the name ldp:canCreate is nothing
>>> I'm emotionally attached to.
>>>
>>>> 4. Link from LDPC to home document that links to factory
>>>> --------------------------------------------------------
>>>>
>>>>     The container contains a link to the home document
>>>>
>>>>     <> a ldp:Container;
>>>>        ldp:homeDocument <http://nasa.gov/satellite/y500/homeSweetHome/> .
>>>>
>>>>     The home document contains a link to the containerFactory
>>>>
>>>>     <http://nasa.gov/satellite/y500/homeSweetHome/> a ldp:HomeDocument;
>>>>        ldp:containerFactory <makeContainersFor> .
>>>>
>>>>     Sending a POST to the containerFactory can create a container, but requires
>>>> telling the container factory which container one wishes to create the container
>>>> in. The containerFactory needs to describe also which containers it can create
>>>> a factory for.
>>>>
>>>
>>> I'm not sure why the home document is needed or anything special.
>>> Isn't it just a ldp:Container ?  Couldn't another application
>>> somewhere create a ldp:Container which then includes the first ?
>>
>> +1 to your 2 previous comments. I don't see any added value in 3. and
>> 4., it's just more complicated for both the server and the client.
>>
>> Alexandre.
>>
>>>
>>>> Henry
>>>>
>>>> Social Web Architect
>>>> http://bblfish.net/
>>>>
>>>
>>> Thanks for putting this out there, really helps move the discussion
>>> along with such good proposals.
>>>
>>> --
>>> - Steve
>>>
>>>
>>
>
> Social Web Architect
> http://bblfish.net/
>
Received on Wednesday, 23 January 2013 15:43:15 UTC

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