(un)blessed container use cases and implementation expectations

All --

After today's "overview" concluded, there was brief continuation 
with a few of us lingering (MacTed, ericP, bblfish, deiu, AndyS).

I raised a concern there, that I now bring here -- that we should 
not be creating a spec that breaks (or even just says "you're
not really using Linked Data" about) some number of use cases with 
the justification that we're making some number of other use cases 
easier (or even possible).

We were talking today about "strongly composed" vs "aggregate"
containers.  An easy differentiation between these is that when
you delete a "strongly composed" container, all its contained
objects are also deleted automatically, where deletion of an 
"aggregate" container doesn't impact the contained objects at all.

The filesystem analogy says that when I delete a directory, all 
its contained files and subdirectories should go away.  But why
should we declare that all LDP containers are analogous to 
filesystem directories?

It seems to me that the default is manual deletion of each object,
whether it's in a container or not, whether it *is* a container
or not.  If a container contains objects, those objects must each
be deleted -- or they remain, even if the container around them
goes away (suddenly they go from contained to free-floating).

If I burn a box ("delete" it) that holds a bunch of marbles, the 
marbles still exist (and start rolling around the floor) -- 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