Re: (un)blessed container use cases and implementation expectations

On 05/11/12 19:54, Richard Cyganiak wrote:
> Ted,
>
> On 5 Nov 2012, at 17:44, Ted Thibodeau Jr wrote:
>> But why should we declare that all LDP containers are analogous to
>> filesystem directories?
>
> 1. You don't have to use LDP containers in your implementation. The
> only thing that LDP containers give you is that they can assign new
> URIs by POSTing to the container. If your application doesn't need
> that, then it won't use containers, and all you have is a simple
> stupid graph where none of the container complexities matter.

There was a suggestion in the informal TC today was to use RDF lists to 
create aggregations - i.e. create non-containers with contaiers only as 
strong containers.

But now we have two ways to have grouping of objects.  The client will 
have to know and deal with each differently.  Or more than 2 - this is 
no standardized so if every system does it's own thing, clients have to 
deal with variety.  The point of a platform is lost.

Is a resource-that-is-an aggregation supporting paging?  What if it has 
two list - paging needs to identify what's paged.

http://lists.w3.org/Archives/Public/public-ldp-wg/2012Oct/0223.html

> 2. Servers can refuse requests to delete containers for any reason,
> right? “There's something in the container” seems like a perfectly
> fine reason to me.
>
> The baseline to me is that a server may refuse to delete a non-empty
> container. In that case, clients may try to delete them one by one.
> But if a server allows deleting a non-empty container, and deletes
> all its members along with the container, that should also be
> conforming. The nice thing is that the same clients would still work,
> and no extra machinery is needed in the protocol. It's simply an
> implementation decision on the server side -- is the implementer
> willing to go the extra mile or not?

Does the strong-delete model work for all use cases?

(it does not if an existing resource can be put in a container - it's 
like creating a file, then putting it in a directory AKA linking).

> I'd say that a server that deletes a container but lets its members
> lie around is not conforming. That way, a client would never know if
> the members were deleted or not, and *has* to check them all
> individually.
>
>> If I burn a box ("delete" it) that holds a bunch of marbles, the
>> marbles still exist (and start rolling around the floor)
>
> An odd choice of metaphor! If I throw the box in the trash ("delete"
> it), then the marbles are in the trash too. But it would be quite
> reasonable for the housekeeper to say: “Don't throw away that box! It
> has marbles in it!”
>
> Best, Richard
>
>
>
>> -- and this may be the right way to handle things, as, for
>> instance, in the case of a filesystem with Hard Links -- where
>> there are many pointers to the same "physical" resource, where the
>> resource should not be dropped, even if one of the pointers thereto
>> should.
>>
>> Now, we *could* say that we want to make the simple filesystem
>> case easier, and there are many ways we might do that -- by
>> creating a specific "composed-container"-type; or a "composition"
>> container property (aggregate vs composed or some such); or a
>> property for the contained objects that basically says "delete me
>> when my container is deleted"; or various others.
>>
>> I'm fine with (probably) any of these -- and incline toward having
>> more options than fewer -- but I want to be quite sure that we
>> don't declare that any existing (known or unknown) implementation
>> that otherwise conforms to LDP, is suddenly non-conformant
>> (thereby offending and disenchanting an early implementer) because
>> the deletion of a container there does not automatically delete
>> the resources it contains.
>>
>> My bottom line -- the manual behavior should be the basis of our
>> specification.  Easing/automating some special cases is certainly
>> reasonable -- but these automated/eased cases should not then
>> become our baseline of compliance.
>>
>> Be seeing you,
>>
>> Ted
>>
>>
>>
>> -- A: Yes.
>> http://www.guckes.net/faq/attribution.html | Q: Are you sure? | |
>> A: Because it reverses the logical flow of conversation. | | | Q:
>> Why is top posting frowned upon?
>>
>> Ted Thibodeau, Jr.           //               voice +1-781-273-0900
>> x32 Senior Support & Evangelism  //
>> mailto:tthibodeau@openlinksw.com //
>> http://twitter.com/TallTed OpenLink Software, Inc.      //
>> http://www.openlinksw.com/ 10 Burlington Mall Road, Suite 265,
>> Burlington MA 01803 Weblog   -- http://www.openlinksw.com/blogs/
>> LinkedIn -- http://www.linkedin.com/company/openlink-software/
>> Twitter  -- http://twitter.com/OpenLink Google+  --
>> http://plus.google.com/100570109519069333827/ Facebook --
>> http://www.facebook.com/OpenLinkSoftware Universal Data Access,
>> Integration, and Management Technology Providers
>>
>>
>>
>>
>>
>>
>>
>
>

Received on Monday, 5 November 2012 22:04:09 UTC